Готовое приложение стоит рассматривать, когда его возможности подходят вашим процессам и позволяют запуститься без существенных переделок. Разработка на заказ имеет смысл, когда ограничения готовой платформы мешают обслуживать заказы, развивать продажи или управлять бизнесом. Проверять это лучше на реальных сценариях ресторана, до подписания договора.
Выбирая приложение для доставки еды, легко потратить несколько встреч на дизайн и так и не выяснить главное: сможет ли система правильно принять заказ, передать его на нужную кухню и дать гостю повод вернуться.
Я Роман Кузнецов, представляю команду Mobecan. Мы разрабатываем мобильные приложения, в том числе для доставки еды. Ниже — мой подход к выбору: с какими вопросами идти к поставщику готового решения и в какой момент обсуждать собственную разработку.
Когда ресторану подходит готовое приложение для доставки еды
Представим ресторан, которому нужны меню, оплата, доставка и самовывоз. Условия заказа простые, программа лояльности укладывается в возможности платформы, а интеграция с учетной системой уже поддерживает необходимые операции. В таком случае я бы начал с проверки готового решения.
У него может быть подписка, плата за подключение или другой способ оплаты. Важнее выяснить, что именно вы получаете: приложение под вашим брендом, доступные настройки, поддержку и возможность забрать свои данные при переходе на другую систему.
Готовая платформа особенно уместна, если вы еще проверяете спрос на собственный канал заказов. До сложной разработки полезно понять, откуда придут пользователи, почему они установят приложение и чем повторный заказ будет удобнее привычного способа.
Собственное приложение не создает аудиторию автоматически. Если привлечение гостей и повторные продажи пока не продуманы, дорогая разработка не решит эту задачу сама по себе.
Когда нужна разработка приложения на заказ
Причиной для собственной разработки должно быть конкретное ограничение, которое дорого обходится бизнесу. Например:
- Заказ нужно распределять между кухнями по правилам, которые готовая система не поддерживает.
- Меню, цены и доступность блюд зависят от точки, адреса, времени или формата получения заказа.
- У сети уже есть программа лояльности, которую нужно сохранить вместе с историей клиентов и балансами.
- Нужен особый сценарий покупки: совместный заказ, подписка на питание, корпоративное питание или предзаказ к определенному времени.
- Команда регулярно меняет путь оформления заказа, а ограничения платформы не позволяют проверить нужные гипотезы.
Ни один пункт не означает, что обязательно нужно писать все с нуля. Иногда достаточно существующей платформы с доработками. Иногда разумно сохранить учетную систему, а клиентское приложение и обмен данными разработать отдельно.
Я бы попросил обе стороны — поставщика платформы и разработчика — показать, как они решат одну и ту же задачу. Тогда сравнивать можно будет состав работ и результат.
Готовое приложение и своя разработка: что сравнивать
| Критерий | Готовая платформа | Разработка на заказ |
|---|---|---|
| Запуск | Может быть быстрее, если достаточно настройки и поддерживаемых интеграций | Срок зависит от проектирования, разработки, проверок и публикации |
| Сценарии заказа | В пределах настроек платформы и доступных доработок | Можно спроектировать под процессы бизнеса; каждое усложнение влияет на объем работ |
| Интеграции | Нужно проверить конкретные операции, а не только название учетной системы | Можно разработать необходимый обмен, если внешняя система предоставляет нужный доступ |
| Расходы | Подключение, подписка, дополнительные модули, доработки и другие платежи по условиям поставщика | Создание продукта, инфраструктура, поддержка и дальнейшее развитие |
| Изменения | Зависят от возможностей и приоритетов поставщика | Зависят от бюджета, команды и качества существующего кода |
| Переход к другой команде | Важны условия экспорта данных и доступ к интеграциям | Важны передача кода, документации, доступов и возможность независимой поддержки |
Название подхода не гарантирует ни низкую стоимость, ни независимость. Эти свойства нужно проверять в конкретном предложении.
Как проверить готовое приложение: пять сценариев заказа
Вместо просмотра красивого каталога предложите поставщику пройти заказ от начала до конца. Ниже — примеры проверок; выберите те, которые встречаются у вас.
- Блюдо закончилось после добавления в корзину. Когда гость узнает об этом и сможет ли продолжить заказ без звонка оператора?
- Адрес находится на границе зон доставки. Какая кухня получит заказ, какой будет стоимость доставки и что произойдет при смене адреса?
- Оплата прошла, но учетная система временно недоступна. Где будет виден заказ, кто получит уведомление и как исключить потерю или дублирование?
- Гость хочет использовать бонусы и промокод. Какие правила сработают и одинаково ли их понимают приложение и учетная система?
- Нужно отменить оплаченный заказ. Как сотрудник выполнит действие, какие статусы увидят остальные системы и что узнает клиент?
Ответ «у нас есть интеграция» еще не описывает поведение системы в этих ситуациях. Попросите показать результат или зафиксировать, какая доработка потребуется. Это поможет обнаружить расходы, которых нет в первоначальной цене.
Что показывает наш проект «Вкус и Лосось»
В Mobecan мы разработали приложение для доставки и самовывоза «Вкус и Лосось». В публичном кейсе описаны меню, оформление заказа, вход через Telegram или СМС, уведомления о статусах, бонусная программа и возможность поделиться собранной корзиной. Посмотреть приложение и разбор проекта.
Экраны из публичного кейса Mobecan. Показаны интерфейсы проекта; цены и акции на экранах относятся к моменту подготовки кейса.
Сохранить работающую программу лояльности
В нашем кейсе на Workspace есть важная деталь: программа «Вкускоины» уже работала до создания нового приложения. Задача состояла в том, чтобы встроить ее в новый пользовательский путь: показать баланс, объяснить начисление и дать возможность использовать бонусы при заказе.
Для выбора платформы это хороший пример конкретного требования. Недостаточно увидеть в списке функций пункт «бонусная программа». Нужно проверить, сможет ли приложение работать с вашими действующими правилами. Наличие бонусов в готовом продукте еще не означает совместимость с вашей системой лояльности.
Сначала договориться о пути заказа
Команда Mobecan вместе с командой клиента исследовала аудиторию и проработала сценарии от первого экрана до оформления заказа. В кейсе опубликована схема, связывающая меню, доставку и самовывоз, профиль, корзину и оплату.
Такую схему я бы использовал и для проверки готового решения: пройти каждый необходимый переход и отметить, где достаточно настройки, а где понадобится доработка. Это делает сравнение предложений предметным еще до обсуждения дизайна.
Какие результаты опубликованы в кейсе
По данным кейса, за первые два месяца после релиза количество добавлений в корзину выросло с 1 805 до 3 717, а число активных аккаунтов — с 2 352 до 8 303. Источник этих показателей — публикация Mobecan на Workspace, раздел «Результат».
Это показатели конкретного проекта. Добавления в корзину не равны оплаченным заказам, а по приведенным данным нельзя отделить влияние интерфейса от привлечения аудитории и других изменений. Для своего приложения стоит заранее определить, какие показатели вы будете сравнивать и за какой период.
Как сравнить стоимость приложения для доставки еды
Сравнивать цену разработки с месячной подпиской неудобно: это расходы за разные периоды и разный состав работ. Я бы запросил у обеих сторон расчет на одинаковый срок, например на два года, с одними и теми же требованиями.
В расчет стоит включить:
- подключение или разработку первой версии;
- перенос меню, клиентов и других необходимых данных;
- интеграции и доработки;
- регулярные платежи за платформу либо инфраструктуру и поддержку;
- используемые внешние сервисы: сообщения, карты и другие платные компоненты;
- запланированные изменения после запуска;
- расходы на привлечение пользователей приложения.
Для процентных платежей попросите расчет при вашем объеме заказов. Отдельно отметьте расходы, которые сохранятся при обоих вариантах: например, эквайринг не обязательно исчезнет после перехода на собственное приложение.
Окупаемость лучше оценивать по дополнительному доходу после переменных расходов и реальной экономии. Заказ, который просто переместился с вашего сайта в приложение, нельзя целиком считать новым доходом. А предполагаемый рост повторных покупок сначала остается гипотезой, которую нужно проверить.
Универсальной цены без описания задачи здесь нет. Меню и самовывоз для одной точки и приложение сети со сложными правилами лояльности требуют разного объема работ.
Что включить в первую версию
Я бы начал с надежного пути от выбора блюда до получения заказа: актуальное меню, корзина, адрес или точка самовывоза, оплата, передача заказа сотрудникам и понятный статус для гостя. Состав первой версии зависит от вашего процесса: например, предзаказ может быть обязательным для одной службы доставки и ненужным для другой.
Каждую дополнительную функцию полезно связать с наблюдаемой проблемой. Если гости бросают корзину на выборе адреса, сначала стоит разобраться с этим этапом. Если оператор вручную переносит заказы, приоритетом может стать интеграция.
После запуска смотрите на завершенные и выполненные заказы, ошибки оформления, повторные покупки и объем ручной работы сотрудников. Количество установок помогает оценить привлечение, но не заменяет эти показатели.
Частые вопросы перед заказом приложения
Можно ли сначала запустить готовое приложение, а потом перейти на свое?
Да, если заранее проверить возможность переноса нужных данных и договориться о порядке перехода. Выясните, в каком формате выгружаются клиенты, заказы и бонусные балансы, кому доступны аккаунты публикации и что придется создавать заново. Возможность такого перехода зависит от конкретного поставщика.
Нужна ли ресторану разработка приложения, если уже есть сайт?
Не всегда. Сначала определите, какую задачу приложение решит лучше: повторный заказ, использование программы лояльности, получение статусов или другой важный сценарий. Если проблема заключается в неудобном оформлении заказа на сайте, полезнее может оказаться его доработка.
Как понять, что готовая платформа не подходит?
Составьте обязательные сценарии и проверьте каждый на демонстрации. Если важный сценарий недоступен, выясните цену и возможность доработки. Решение стоит принимать с учетом этих ограничений, полной стоимости и влияния на работу ресторана.
Обсудим, какой вариант подходит вашей доставке
Если вы выбираете приложение для ресторана или сети, можно начать с короткого описания задачи. Полное техническое задание для первого обращения не обязательно.
Напишите, сколько у вас точек, где сейчас принимаются заказы, какую учетную систему используете и что мешает работать. Добавьте необходимые функции и желаемый срок запуска. Если уже есть предложение готовой платформы, укажите, какие ее ограничения вызывают вопросы.
Обсудим, где можно использовать готовые возможности, какие доработки понадобятся и имеет ли смысл оценивать собственное приложение.
Обсудить приложение с Mobecan — опишите задачу в форме обращения на странице. В сообщении можно указать: «Выбираем между готовым приложением для доставки еды и своей разработкой».