Мобильное приложение для доставки. Легко?!

Принято считать, что разработать мобильное приложение для доставки еды сейчас довольно просто: меню, корзина, онлайн оплата и можно запускать! Подумав, можно еще добавить личный кабинет гостя, небольшую систему лояльности – скидки на заказ или накопление баллов, админку для рассылки push-сообщений и,... вишенка на торте – интеграция с одной из ресторанных систем. Два-три месяца упорной работы, достаточно подъемная сумма для заказчика и мы запустились. Ура! Таких историй очень много, исполнители с гордостью рассказывают о таких "историях успеха" в блогах и соцсетях.

Судьба большинства таких проектов, увы, печальная. Приложения, как правило, забрасывают, их уже никто не обновляет, а владелец ресторана приходит к неутешительному выводу: мобильное приложение для доставки не работает, деньги потрачены зря!

Попробуем разобраться в причинах подобных неудач.

Первая причина неуспеха – это завышенные ожидания заказчика, которые исполнитель страстно поддерживает. Владельцы ресторанов часто путают мобильное приложение и маркетинговый отдел. Привлечение новых клиентов, знакомство людей с неизвестным брендом – это задачи последнего. Цель разработки мобильного приложения - создать функциональный и удобный инструмент с красивым дизайном, поддерживающим лояльность и способным обеспечить рост числа новых заказов.

Мы рекомендуем рассматривать хорошее приложение как важную составляющую современной доставки, но этого не всегда хватает. А важная она потому, что даже если у вас будет высокоэффективный маркетинг, то без привлекательного, работающего без сбоев инструмента, посетители не будут конвертироваться в лояльных гостей и новые заказы.

Вторая причина это недооценка сложности проекта и стоимости поддержки. С этой проблемой за 8 лет работы на рынке мы сталкивались неоднократно и очень часто в этом заблуждении есть вина самих исполнителей. Они, в погоне за прибылью, максимально упрощают и "удешевляют" приложение. Звучит парадоксально, но если вдуматься, становится понятно, что продать заказчику проект за 2 миллиона рублей намного сложнее, чем за 250 тысяч. А зарплаты разработчиков все также высоки. Выход - исключить все, кроме самого необходимого, а лучше и часть необходимого тоже.

Разработка MVP, хоть как-то автоматизирующего основной бизнес-процесс, хороша для стартапов, ищущих свою бизнес-модель. Но доставка еды – это хорошо изученный, высококонкурентный рынок. Выживают только проработанные продукты с отточенным дизайном, обеспечивающие отличный пользовательский опыт и не создающие проблем ресторану при обработке заказов. Каждая "отложенная" и плохо реализованная функция - это потеря конкурентных преимуществ, гостей и денег.

Важный момент, который часто упускают из вида - это поддержка и развитие продукта после внедрения. Выходят новые версии смартфонов, операционных систем. Быстро становятся стандартными функции, которых раньше не было. Например, Apple Pay, Google Pay, Samsung Pay. И пользователи уже с трудом мирятся с их отсутствием. Все это требует существенных ресурсов и, самое главное, большой вовлеченности сотрудников в тренды доставки еды и ресторанного рынка.

Экономия на старте играет против самих разработчиков: заплатив за разработку 250 000 рублей, тратить на годовую поддержку сумму, эквивалентную стоимости всего проекта, заказчик как правило не готов. Но за 20 тыс. рублей в месяц держать команду на проекте и реализовывать новые функции уже исполнитель как правило не готов.

Крупные игроки, способные инвестировать большие средства в разработку мобильного приложения понимают необходимость разработки собственных уникальных решений. Им стоит уделить пристальное внимание разработке детального технического задания. Что необходимо включить в ТЗ?

Очень важно спланировать поддержку и дальнейшее развитие приложений. Спросите, есть ли в команде заказчика специалисты, которые будут отвечать за мониторинг трендов ресторанного рынка и анализ ключевых метрик продукта, проверять гипотезы. Именно на основе этих данных нужно ставить задачи на доработку подрядчикам. В очень редких случаях эту функцию можно делегировать исполнителю - чаще всего, в компаниях, занимающихся заказной разработкой, нет специалистов-продуктологов, да еще и специализирующихся именно на ресторанной отрасли.

Если у заказчика нет возможности инвестировать крупную сумму в разработку собственного продукта или нет необходимости в разработке уникальной функциональности, стоит обратить внимание на готовые решения.

Выбор продукта и партнера, это тоже непростая и ответственная задача. На рынке есть серьезные компании, много лет работающие в этой сфере и дорожащие своей репутацией. У них, как правило, качественные продукты для автоматизации доставки, сформированы команды разработчиков и продуктологов, отлажены процессы развития и поддержки продукта.

Однако очень часто мы видим амбициозные, но мало жизнеспособные продукты, которые существуют на рынке год-два, после чего закрываются. Для заказчиков это чревато сложностями и недовольством гостей, т.к. замена продукта чревата множеством проблем: от изменения привычного интерфейса до риска полной потери базы гостей и их истории заказов.

В первую очередь, нужно сформировать правильное ожидание от мобильного приложения. Нужно понять, что приложение - это не волшебная палочка, генерирующая заказы, а лишь один из инструментов для достижения цели.

Во-вторых, необходимо осознавать что мобильная разработка дело сложное и довольно дорогое. Ресторанный бизнес очень конкурентный, доставка развивается семимильными шагами и продукт требует постоянных изменений и доработок.

Если вы готовы инвестировать значительные средства в уникальную функциональность и собственную команду развития продукта, то присмотритесь к заказной разработке.

В противном случае - выбирайте готовый продукт, который давно на рынке и стабильно развивается.