В интернете полно идей для быстрорастущего B2B-бизнеса. Однако, эти идеи часто освещают маркетинговые решения, которые уже используются на рынке B2B. Команда Exceed Team составила для вас список уникальных идей для приложений B2B.
1. Полная подотчетность и предусмотрительность
Чем детальнее статистические отчеты B2B-продавца, тем увереннее он себя чувствует в приложении. Предоставьте B2B продавцам полную отчетность, интегрировав в свое приложение искусственный интеллект для сбора персонализированных данных.
Помимо статистических данных вы можете подумать о методах интеграции в приложение следующих востребованных инструментов B2B рынка:
- Интеграция с бухгалтерскими и логистическими программами
- Интеграция системы «склад”. Система отражает не только оставшиеся запасы, но и то, какие товары популярны у клиентов
- Обеспечение прозрачности операций с денежными средствами и документооборотом
2. Электронный документооборот
Поиск идей для стартапа в секторе генеративного ИИ (Generative AI)
- Электронные счет-фактуры
- Электронные контракты на поставку
- Электронные чеки
- Автоматически формирующиеся бухгалтерские проводки
- Логистические отчеты
- Статистика изменения доходов и других показателей за месяц/полугодие/год (популярным становиться показ статистики в текущее время
Вы можете создавать шаблоны или интегрировать возможности Google Sheets для их поддержания и правильного заполнения. Это сэкономит время для B2B-продавца и повысит привлекательность вашего приложения.
3. Легкость повторного заказа товара
Встретив удовлетворяющего все потребности поставщика, клиенту B2B захочется работать с ним вновь. Процесс повтора заказа может быть ещё легче при помощи следующего инструментария:
- Функция увеличения количества товара в корзине потребителя
- Функция добавления продавца или товар в раздел “избранное”
- Функция уведомления об изменениях цены и количества товара; когда товар снова доступен для покупки; изменения описания в профиле партнера и т.д.
- Система сохранения банковских данных для оплаты товара поставщика. Это позволит быстрее наладить покупки и не вписывать одни и те же данные каждый раз
4. Мини-офис внутри приложения
За B2B-клиентами часто стоит команда людей. Если дать возможность аккаунту B2B создавать в своем профиле дополнительные аккаунты и внутренний чат, это позволит его команде проводить полноценный анализ рынка. Таким предложением, площадка обеспечивает мини-офис.
Если эта идея вам кажется привлекательной, то стоит подумать о безопасности. Например, можно сделать так, чтобы главный аккаунт мог ограничить некоторые действия других аккаунтов созданных на его основе. Это позволит не бояться за утечку информации и сохранить иерархию компании, даже внутри приложения B2B.
5. Бизнес-план
Бизнесу важно развитие. Предприниматели беспокоятся о будущем. Чтобы снизить это беспокойство, вы можете интегрировать в приложение программу, которая автоматически составляет бизнес-план. Загрузив отчет из приложения в специальную систему, B2B-продавец сможет детально разобраться в тенденциях развития своего бизнеса и найти идеи для повышения его эффективности.
Pet-проекты. Как программисту придумать хобби-проект? Начинающему и не только
6. Безопасность
Чтобы продавцы B2B не боялись пользоваться электронным документооборотом, системой составления бизнес-плана и другими функциями, которые требуют использования корпоративных данных, они должны быть уверены в безопасности приложения.
Для этой цели могут подойти стандартные методы защиты информации. Однако, с развитием технологий, можно попробовать современные варианты защиты личного кабинета B2B продавца.
- Уровни доступа к информации внутри аккаунта
- Биометрия лица
- Электронная подпись
- Голосовое подтверждение
7. Больше возможностей для демонстрации продукта
Для B2B-продавцов важно презентовать свой продукт наилучшим образом. В дополнение к фотографиям, видео и обзорам, демонстрирующим дизайн и качество продукта, вы можете интегрировать в приложение B2B технологию дополненной реальности (AR) и 3D-технологии.
8. Сотрудничество продавцов B2B
Все чаще можно заметить тенденцию, что потребитель хочет купить товар сразу со всеми дополнительными аксессуарами. Два продавца, которые производят разные продукты, обычно используемые друг с другом (например, телефон и чехол, принтер и бумага и т. д.), могут объединить такие продукты в один набор. Эта функция может повысить эффективность продаж и уже используется в торговой системе B2C.
9. Дополнительные функции для профиля продавца
Дизайн профиля продавца, который виден потенциальным покупателям, призывает их к покупкам. Современные сайты и приложения используют такие инструменты для оформления главных страниц:
- Видео
- Анимации
Эти инструменты помогут бренду B2B-продавца выделиться на фоне конкурентов. Приложение, которое предоставит такие возможности, станет для B2B продавцов более эффективным, запоминающимся и удобным.
10. Образование
Многие клиенты B2B могут бояться перенести свой бизнес в приложение потому что они не понимают как оно работает. Функция обучения поможет решить эту проблему. Такой метод работы с приложением на данный момент используется социальными сетями. Это повышает доверие новых пользователей и они быстрее начинают использовать приложение по назначению.
Стоит подумать и о клиентах, которые уже есть на сайте. Им можно предложить информационные рассылки о трендах, посещение онлайн-вебинаров и многие другие образовательные программы.
Команда Exceed Team в данной статье не затрагивала существующие маркетинговые и технические идеи, которые уже используют большинство приложений B2B. Перечисленные идеи могут потребовать нового технического решения. Для того чтобы их реализовать потребуется работа команды разработчиков. Если у вас возникли вопросы по ходу чтения статьи — ждем ваши комментарии!
Источник: vc.ru
10 идей, о которых стоит знать всем программистам
Я пишу на Python и на Go, а в последние годы занимаюсь крупномасштабными приложениями. Речь идёт о том, что каждый день мне и моей команде приходится поддерживать системы, ответственные за обеспечение работы примерно двух миллионов пользователей. Это — непростая задача. Здесь я хочу поделиться несколькими ценными идеями, которые встретились мне за годы работы.
1. Не надо решать вопросы безопасности в последнюю очередь
Системы безопасности приложений крайне не рекомендуется реализовывать в последнюю очередь, или сводить всё к такой мысли: «Сделаем безопасность как-нибудь потом». Для того чтобы создать безопасное приложение, вопросы безопасности должны быть на повестке дня с самого первого дня работы над проектом. Если оставлять разработку системы безопасности на последний дедлайн, то это, на самом деле, лишь увеличит сроки разработки, так как придётся возвращаться к уже написанному коду и рефакторить его для приведения в соответствие с нуждами безопасности. Или всё может сложиться ещё хуже: из-за нехватки времени на «затыкание» всех «дыр» всё закончится тем, что в продакшн попадёт код, в котором будут уязвимости. А это, как несложно убедиться, проанализировав опыт разных компаний, вроде Yahoo, может закончиться очень плохо.
2. Все приложения разные, у них разные нужды, поэтому выбирать технологии для разработки нужно, исходя из особенностей проектов. Не стоит ориентироваться на популярность технологий или поддаваться давлению руководства
Пожалуй, об этом можно и не говорить, но я всё же скажу о том, что все приложения отличаются друг от друга. Нет некоего свода непреложных правил, применимого ко всем проектам (включая и это правило).
Когда вы начинаете работу над новым проектом, выбор технологий и платформ, на которых будет основано приложение, должен определяться лишь особенностями самого приложения и его архитектуры. Если принимать решение о том, использовать ли gRPC или Kubernetes, до того, как будет задан вопрос: «А что нужно приложению?», — это означает — ставить препятствия на собственном пути ещё до начала работы над кодом. Именно так разные компании и попадают в абсурдные ситуации. Например, в ситуации вроде той, когда Canonical предлагает Kubernetes для IoT-устройств. Позволю себе процитировать тут фразу Джеффа Голдблюма из фильма «Парк Юрского периода»: «Да, но ваши учёные столь увлеклись, добиваясь этого, что даже не задумались: «Стоит ли?»».
3. Микросервисы нужны далеко не всем
Микросервисы крайне привлекательны. Мне это понятно. Идея, в соответствии с которой можно независимо масштабировать разные части приложения, восхитительна. Она способна оправдать дополнительные объёмы работ, которые необходимы некоему проекту. Но давайте будем честны с собой: вам, возможно, микросервисы не нужны.
Предположим, идею применения микросервисов пытаются поддержать следующими соображениями: «Хочу отделить код возможности X от кода возможности Y», «Хочется, чтобы плохой код из одних частей приложения не проникал бы в другие его части», «Нужно минимизировать последствия возможного взлома приложения». Но всё это нельзя назвать причинами, руководствуясь которыми необходимо переходить на микросервисы. Это, соответственно, симптомы применения плохих подходов к разработке (не лезь в чужие дела, меняй только то, что необходимо), низких стандартов код-ревью (некачественному коду нечего делать в ветке master) и недостатков в сфере безопасности.
Нужно ли вам независимо масштабировать различные части приложения? Есть ли у вас сейчас проблемы с быстродействием каких-то компонентов проекта, вроде механизмов для входа в систему? Если так — то, вероятно, стоит исследовать возможность выделения тех компонентов, которые нуждаются в масштабировании, в отдельные сервисы.
Может, в вашем проекте используется архитектура, основанная на виртуальных серверах, и вам хочется снизить расходы? В таком случае микросервисы вам не нужны. Вы, используя их, в лучшем случае, останетесь на том же уровне расходов. А в худшем случае вам придётся использовать дополнительные серверы. Предположим, у вас имеется монолит с пятью сервисами,.
Вы разбили его на микросервисы. Теперь у вас имеется пять приложений. А это значит, что возможны два варианта развития событий. Первый — это если вам придётся запускать каждое из них на отдельном сервере, что увеличивает количество ваших серверов. Второй вариант — это если вы будете всё это запускать на существующей инфраструктуре, больше тратясь на поддержку и администрирование проекта.
4. Стандартизированное окружение разработки — это хорошо
Если вы руководите командой разработчиков, то одно из самых полезных решений, которое вы можете принять, это решение о применении единого окружения разработки. Причём, я тут не имею в виду необходимость строить нечто вроде контейнеризованного виртуального окружения. Вы вполне можете сделать и это, если хотите, но даже применение простого правила, вроде использования одной и той же версии языка, может творить чудеса. Например, серьёзно потрепать себе нервы можно, попытавшись отладить ошибку в Go 1.12, в то время как ваш коллега, обратившийся к вам за помощью, пишет код на Go 1.11. Координация обновлений может быть достаточно сложной задачей, но если подойти к организации этого процесса правильно, всё будет делаться легко и приятно.
5. Реализация подсистемы, отвечающей за настройки приложения, может оказаться более сложной, чем кажется на первый взгляд. Поэтому такие вещи нужно как следует планировать
В отличие от того, что можно прочитать на некоторых популярных сайтах, создать подсистему, отвечающую за настройки приложения, немного сложнее, чем «положить всё в переменные окружения». Я полагаю, что нужно предусматривать не менее четырёх способов конфигурирования приложений: значения по умолчанию, задаваемые в коде, локальный конфигурационный файл, флаги командной строки, переменные окружения, удалённый источник настроек (вроде HashiCorp Consul).
Удалённый источник настроек я назвал бы необязательным. Но другие четыре механизма просто необходимы. Если в процессе разработки, только для того, чтобы запустить приложение, нужно записать в переменные окружения 27 значений, то это, если мягко выразиться, не так уж и удобно. Кроме того, может быть вам нужен более высокий уровень автоматизации и Makefile?
Если предусмотреть настройку приложения через локальный файл, вроде application.yaml , это может значительно облегчить описание конфигурации, применяемой, по умолчанию, при разработке. Кроме того, если в коде есть значения, используемые по умолчанию, это означает, что задавать эти значения нужно только тогда, когда нужно что-то, отличающееся от стандартных настроек. Флаги командной строки весьма полезны в ситуациях, когда приложения запускают с помощью разных средств автоматизации, вроде systemd . Это облегчает анализ конфигурации при трассировке процессов. Конечно, переменные окружения крайне полезны при запуске приложений в контейнерах, но есть некоторые задачи, для решения которых они не подходят. Например, переменные окружения не стоит использовать для хранения паролей.
В переменные окружения категорически не рекомендуется записывать что-то секретное: пароли, токены аутентификации, сертификаты, в общем — всё, что вы не хотели бы сделать достоянием широкой общественности. Проблема тут в том, что значения переменных окружения может прочитать практически любой процесс, работающий на компьютере. Для хранения секретных данных нужно использовать какое-то специализированное решение. Лично я для этих целей выбрал HashiCorp Vault, но я не призываю пользоваться именно этим сервисом. Выбирайте то, что лучше всего подходит для вашего проекта.
6. Зависимости стоит использовать тогда, когда они нужны
Полагаю, все помнят о left-pad-апокалипсисе? Как 11-строчный пакет, который убрали из репозитория, поломал, в сущности, весь интернет? Этот инцидент приводит к одной простой мысли: «Не стоит, без реальной необходимости, подключать к проекту дополнительные зависимости». Зависимости стоит использовать только тогда, когда в них есть обоснованная необходимость.
Какие зависимости по-настоящему нужны в проектах? Например — это может быть пакет, представляющий собой SDK для платформы, с которой вы работаете (SDK AWS, например). Это может быть некая хорошая абстракция над неудобными стандартными библиотеками (именно поэтому программисты пользуются Python-библиотекой Requests вместо urllib ). Это может быть какой-то широко используемый фреймворк — вроде HTTP-сервера Echo, написанного на Go, или WSGI-сервера Flask, написанного на Python. Некие библиотеки, реализующие удобные методы, которых нет в языке, вроде библиотеки Lodash для JavaScript-проектов, тоже относятся к «обоснованным» зависимостям.
Внешние зависимости должны упрощать разработку и не должны заставлять программиста самого писать какой-то вспомогательный код. Именно в упрощении разработки и заключается сильная сторона менеджеров пакетов. Но, как и в случае с left-pad, пользуясь менеджером пакетов легко попасть в ловушку, когда к любой задаче применяется такой подход: «Для этого есть библиотека, значит я ей воспользуюсь». С каждой импортированной в проект зависимостью растёт риск того, что проект может стать нестабильным, небезопасным, или попросту необслуживаемым.
Этот риск увеличивает и каждый пакет, используемый новой зависимостью. Такие пакеты называются транзитивными зависимостями. Если вы импортируете в проект всего одну зависимость, которая, в свою очередь, импортирует пять пакетов, то ваш проект тоже становится зависимым от этих пакетов, а значит — все проблемы этих пакетов становятся и его проблемами.
И по моему мнению, и по мнению других программистов, прямые зависимости проектов не должны иметь транзитивных зависимостей. Но это не всегда возможно. Хотя, если речь идёт об очень больших пакетах, то они должны иметь как можно меньше зависимостей. А если пользователям таких пакетов нужен какой-то дополнительный функционал, у них должна быть возможность самостоятельно подключать такой функционал.
Я, принимая решения об импорте зависимостей в свои проекты, следую простому правилу: если я могу что-то написать за 10-15 минут, то я так и делаю. В противном случае я, если есть такая возможность, импортирую в проект некую библиотеку. Это правило может уберечь вас от импорта в приложение всякого хлама, но оно, в то же время, достаточно гибкое, и не принуждает программиста к тому, чтобы он каждый раз, когда ему нужно организовать работу API, писал бы собственный HTTP-сервер.
7. Не нужно писать абстракции до тех пор, пока в этом не возникнет реальная необходимость
Современному программисту очень легко попасть в ловушку абстрагирования всего и вся. Мысли о том, что нечто может понадобиться использовать повторно, способны завести разработчика в тёмные и страшные дебри ООП. И мне удалось понять причину этого. Принципы DRY (Don’t Repeat Yourself, не повторяйтесь) глубоко укоренились в нашем сознании. И не без причины.
Но есть граница, пересекая которую, мы тратим на абстрагирование сущностей слишком много времени, а на написание кода — слишком мало. Поэтому вот вам совет: «Просто пишите код!». Если вы столкнулись с необходимостью реализовать функцию, похожую на что-то такое, что вы уже написали, тогда вы можете вернуться к старому коду и заняться созданием абстракции.
Но, опять же, тут надо знать меру. Я применяю здесь такое правило: если речь идёт о маленькой функции в три строчки, то, вероятно, её можно просто написать, пусть и повторившись. Но если в функции содержится всего три строки кода, то, вероятно, я задамся вопросом о том, что, возможно, этот код и не стоит оформлять в виде функции.
8. Иногда свой проект стоит «сжигать» и «возрождать из пепла»
Это — самая страшная идея из тех, которыми я тут делюсь. Эта идея заставляет менеджеров нервничать. Она портит настроение владельцам продукта. Она злит программистов. Но «возрождение из пепла» — это совершенно необходимо.
Время от времени начинать всё сначала — это хорошо. Это позволяет выбросить из кода всякий мусор. Это даёт возможность реализовать новые идеи, не переписывая половину существующей кодовой базы. Это принуждает всех, кто работает над проектом, переоценить его.
Представьте, что ваш проект — это огромный лес. Каждая строка кода — могучая сосна. По мере того, как лес стареет, он зарастает подлеском, его засыпает сосновыми иголками, шишками, сухими ветками… Это — ваши проблемы, ваш технический долг. Всё это имеет свойство накапливаться. Этот процесс, сам по себе, никогда не останавливается.
Остановить его могут лишь некие радикальные изменения. В лесу изменения приносят пожары. Огонь очищает лес от всего ненужного. Сильные деревья остаются, а всякая мелочь сгорает. Хотя пожар может показаться катастрофой, которая уничтожит лес, тут есть один секрет: лес ждёт пожара. Ждёт терпеливо, годами.
Лес надеется на то, что огонь очистит его и станет причиной изменений. Дело в том, что пока пламя бушует под кронами сосен, в их шишках созревают семена, из которых вырастут новые мощные деревья. В то время как огонь сжигает лесную подстилку, он освобождает место для нежных молодых деревьев, которые займут своё место рядом с выжившими ветеранами леса, опалёнными огнём. Именно такими должны быть и приложения: их надёжные, хорошо написанные части переживут «пожар», а место того, что будет «сожжено», займут новые идеи и новый код. И проект, как Феникс, возродится из пепла.
9. Ваша компания — это не Google
Нет, если вы работаете в Google, то я ничего против не имею. Но если это так, то скажите, а зачем вы вообще это читаете? Собственно говоря, моя идея заключается в том, что ваша компания — это, скорее всего, не Google, Microsoft, Amazon, Twitter или Facebook. Вам не нужно думать о том, как управлять 150000 контейнеров на 10000 «железных» серверов, расположенных в 17 дата-центрах, разбросанных по всему миру.
Проблемы, которые перед вами встают, обычно не затрагивают каждого жителя Земли. Кстати, а зачем я об этом всём говорю? А затем, что размеры вашей организации должны определять масштабность используемых вами платформ. Например, вы пользуетесь несколькими сотнями контейнеров. Вам и правда не обойтись без Kubernetes?
И обязательно ли вам запускать эти контейнеры на собственных серверах? Может, вы просто, поступая так, хотите казаться солиднее? Для решения подобных мелко- и среднемасштабных задач отлично подходит что-то наподобие HashiCorp Nomad. Подобные платформы легко настраивать. Их не нужно поддерживать, а если они и нуждаются в поддержке, то особых усилий на это не требуется.
Они хорошо документированы. На них очень легко переносить приложения, так как они рассчитаны на работу с контейнерами, с системными процессами и с JVM-приложениями. А если вам никак не обойтись без Kubernetes, то почему бы не пользоваться этой платформой, прибегнув к чему-то вроде Rancher? Это позволит снять с себя задачи по настройке всяческих мелких деталей.
Нагрузка, связанная с использованием сложных систем, вроде Kubernetes, слишком велика для некоей отдельной команды разработчиков, скажем, для команды стартапа. Эти системы, кстати, разработаны крупными компаниями, вроде Google, и предназначены для таких же компаний.
Я бы даже сказал так: стартапам стоит любой ценой избегать Kubernetes — за исключением тех случаев, когда их продукт неразрывно связан с данной платформой. Пожалуй, тут есть одно исключение: облачные предложения от Google, Amazon и Microsoft. Ничего плохого я о них сказать не могу, так как эти компании снимают с пользователей нагрузку по управлению сложными системами. Но я очень вас прошу: никогда не пользуйтесь Kubernetes на IoT-устройствах.
10. Не стоит формировать свои взгляды на разработку ПО, полностью полагаясь на идеи случайных людей из интернета
Вам нужно составить собственное мнение о том, какие из освещённых здесь идей применимы к вашему приложению и к вашему стилю разработки. И учитывайте, что то, о чём я тут рассказывал, далеко не истина в последней инстанции. Ведь я — всего лишь незнакомец, текст которого вы нашли в интернете.
Что вы добавили бы к тем идеям, о которых мы только что говорили?
Источник: habr.com
10 ИДЕЙ ДЛЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ
Генерирование идей для продукта не одно и то же, что и обычное придумывание идей. Да, можно использовать метод мозгового штурма, но принесёт ли он результат, которого вы ожидаете?
Чтобы придумать идею для приложения, которым люди будут пользоваться каждый день, нужно применять не только креативный, но и продуктовый подход. Продуктовый подход в разработке — это создание приложений и веб-сервисов, которые ориентированы на потребности целевой аудитории.
Сегодня мы дадим вам целых 10 идей для хорошего мобильного приложения и приведем примеры, как их использовать. Погнали!
Идея 1. Создать приложение-личный кабинет
Зачем это делать. Приложения-личные кабинеты нужны и операторам связи, и банкам, и девеловерам, и госкорпорациям, потому что делают бизнес доступным и осязаемым для клиента.
Успешный пример. Приложение «Мой Триколор» — личный кабинет, в котором клиенты «Триколор ТВ» могут управлять услугами, подписками, совершать покупки и полностью контролировать все взаимодействия с оператором. Разработчик сообщает, что с помощью этого приложения бизнес заработал больше денег на продаже дополнительных услуг.
Идея 2. Использовать технологию дополненной реальности (AR)
Зачем это делать. С помощью этой технологии можно сделать получение услуги или товара удобней для пользователей: помочь увидеть, как «сидит» одежда, подходит ли новая мебель к интерьеру, провести экскурсию по городу и даже научить танцевать. Чем качественней реализована технология, тем выше спрос на приложение.
Успешный пример. Приложение-игра Life Code для Дарвинского музея эволюции. В первую неделю после публикации приложение скачало более 20 000 человек.
Идея 3. Создать приложение с программой лояльности
Зачем это делать. Программа лояльности в мобильном телефоне сделает продукт или услугу, которую предлагает ваш бизнес, более выгодной для целевой аудитории. С её помощью вы можете привлечь больше клиентов и увеличить средний чек.
Успешный пример. Приложение «ИЛЬ ДЕ БОТЭ». В 2021 году мы получили за него серебро в категории «Красота и здоровье». Дисконтная карточка в нём — часть профиля пользователя. Это значит, что покупатели не забудут про неё и точно приобретут товары со скидкой.
А если есть скидка, то можно купить ещё одну помаду.
Идея 4. Использовать технологии интернета вещей (IoT)
Зачем это делать. Технологии IoT позволяют разработать умные девайсы, которыми можно управлять через приложение. Чем удобнее и понятнее приложение, тем охотнее люди используют девайсы. Про один из возможных способов использования IoT мы писали в статье «Любовь на удалёнке: как сохранить отношения на расстоянии с помощью технологий».
Успешный пример. Приложение Askona Sleep. MVP-версия приложения для управления умными девайсами для сна Askona — своеобразный «пульт» ко всем устройствам производителя, которые помогают людям высыпаться.
Идея 5. Сделать промо-приложение
Зачем это делать. Такие приложения не продают товары или услуги напрямую, но подогревают интерес к бренду и повышают лояльность клиентов.
Успешный пример. Приложение «Тролли. Караоке» от «Пятёрочки». За две недели после публикации количество загрузок из сторов превысило 2,5 миллиона, два из которых пришлись на пользователей Android.
Идея 6. Добавить игровые элементы в полезные приложения
Зачем это делать. Геймификация — это способ сделать использование обыденных услуг интересней за счёт игровых механик. На геймификации можно выстроить всё приложение или же добавить в него несколько обособленных ф.нкций.
Успешный пример. Приложение «Фишки ОТП». Разработчики нашли баланс между игровыми механиками и пользой и сделали нетипичное для банковской среды приложение. Ежедневно его используют 12 тысяч человек.
Идея 7. Разработать свой суперапп
Зачем это делать. Благодаря супераппам вы можете собрать десятки услуг в одном приложении, подключив к своему сервису партнёрские компании. Супераппы довольно молодой формат приложений, поэтому у вас ещё есть шанс занять своё местечко в одной из ниш.
Успешный пример. Суперапп для контроля здоровья Protek. Приложение совмещает в себе функциональность календаря, полезных советов, предоставляет доступ к чату с врачом и показывает состояние здоровья организма пользователя на 3D-модели человека.
Идея 8. Создать приложение для доставки
Зачем это делать. Еда нужна всем, а выходить из дома можно только пока. Когда нам запретят и это, приложения для доставки будут очень кстати. Во-первых, они спасут людей от голода, во-вторых, помогут бизнесу остаться на плаву даже в самый безвыходный локдаун.
Успешный пример. Приложение «Перекрёсток Впрок» совмещает в себе продуктовый ecom и доставку. Средняя оценка в сторах — 4,7, второе место в топе App Store в категории «Еда и напитки», больше двух миллионов скачиваний.
Идея 9. Сделать корпоративное приложение для сотрудников
Зачем это делать. Пользователями приложения могут быть не только люди, которые находятся «по ту сторону» вашего бизнеса, на стороне клиента, но и люди, которые обеспечивают его слаженную работу — ваши сотрудники. Приложение может помочь в составлении расписания, графика отпусков, в обучении и коммуникации. Это может быть социальная сеть, таск-трекер или приложение для управления проектами — зависит от ваших потребностей.
Успешный пример. Приложение «Перчатка» от «Перекрёстка» — корпоративный инструмент для коммуникации и обучения. В первый месяц после запуска показатель DAU (ежедневно активные пользователи) составил более 20%, а охват аудитории — более 1/3 компании.
Идея 10. Использовать технологию искусственного интеллекта
Зачем это делать. Искусственный интеллект можно использовать для любых целей: он отлично справляется с поиском сорняков, предсказывает время приготовления блюд, составляет персональные подборки товаров для пользователей. На базе ИИ создаются чат-боты, голосовые помощники и поисковые системы.
Успешный пример. Редактор диалоговых симуляций Dialo учит переговорам. Сейчас к сервису подключены известные партнёры, такие как X5 Retail Group, Leroy Merlin, Raiffeisenbank, Сургутнефтегаз, Ростелеком, Yota
Материал подготовила педагог по направлению «Мобильная разработка» Оглобля Ангелина Андреевна.
Источник: itcube.su