Мобильное приложение для доставки еды
Агрегаторы берут 25-35% с каждого заказа и владеют вашим клиентом. Своё приложение доставки возвращает маржу: заказ за минуту, оплата СБП, точные зоны на карте, статусы в push и повторный заказ в одно касание. Плюс приложение курьера, если доставляете сами.
Что должно быть в приложении доставки
- Меню из кассы. Категории, блюда, фото, модификаторы и размеры, стоп-лист в реальном времени из iiko или r_keeper. Меню правится на кассе, а не в приложении.
- Адрес и зоны доставки. Определение адреса по геолокации, зоны на карте с разной стоимостью и минимальным чеком, время доставки по загрузке кухни, самовывоз с выбором точки.
- Корзина и оплата. Промокоды, бонусы, приборы и комментарии, оплата СБП, картой, наличными курьеру, чек по 54-ФЗ. Повторить прошлый заказ одной кнопкой.
- Статусы и трекинг. Принят, готовится, передан курьеру, доставлен. Push на каждом шаге, курьер на карте, если доставляете сами.
- Лояльность и push. Бонусы, акции по времени суток, персональные предложения по истории заказов, напоминания в обед и вечер пятницы.
- Приложение курьера. Заказы по очереди, маршрут в навигатор, статусы, фотоподтверждение, приём наличных. Отдельный интерфейс на той же кодовой базе.
- Панель оператора. Заказы в реальном времени, назначение курьеров, стоп-лист, промокоды и push-кампании.
- Интеграции. iiko, r_keeper или Presto для меню и заказов, эквайринг и СБП, Яндекс Карты или 2ГИС, СМС-шлюз, CRM или Mindbox для лояльности.
Своя доставка или через агрегатор: когда приложение окупается
Приложение имеет смысл, когда у вас уже есть поток повторных заказов: сеть кафе, суши, пицца, пекарня, даркстор. При комиссии агрегатора 30% и обороте доставки 3 млн ₽ в месяц вы отдаёте около 900 тысяч ежемесячно. Перевод трети заказов в своё приложение окупает разработку за год, дальше это чистая маржа и база клиентов, которая принадлежит вам.
Для одиночного ресторана с редкими заказами приложение рано: начните с доставки через сайт и агрегаторы, копите базу. Мы честно скажем это на первом созвоне, потому что приложение без заказов не нужно ни вам, ни нам.
Особенности, которые видно только в бою
Скорость в час пик
Пятничный вечер даёт пиковую нагрузку на API и кассу. Проектируем очередь заказов и кэш меню так, чтобы приложение не «висело», когда кухня загружена.
Стоп-лист в реальном времени
Блюдо закончилось, а гость его заказал: худший сценарий. Синхронизация стоп-листа с кассой раз в минуту и проверка при оформлении.
Зоны и время
Зоны меняются от загрузки и погоды. Оператор меняет зоны и время в панели, приложение показывает актуальное без обновления.
Наличные и сдача
Курьер видит сумму и сдачу, оператор видит расхождения. Мелочь, из-за которой теряют деньги и курьеров.
Этапы запуска доставки
Первый этап: приложение клиента с меню, адресами, оплатой и статусами поверх вашей кассовой системы, публикация в трёх сторах. Это 3-4 месяца. Второй этап: приложение курьера, панель оператора с назначением, лояльность и триггерные push. Если курьерская доставка уже автоматизирована в кассовой системе, второй этап короче.
Ориентир: доставка с курьером по строкам
Flutter, 20-40 экранов: меню, карты и зоны, оплата картой и СБП, push по статусам и акциям, интерфейс курьера, серверная часть, обмен с кассовой системой, панель оператора.
Кассовая система посчитана как ERP-обмен на 50 часов. iiko и r_keeper имеют открытые API, для Presto и самописных касс объём уточняем.
Пересобрать в калькулятореЗаполнить брифЧастые вопросы
Заберём заказы у агрегаторов?
Расскажите, что должно уметь приложение и на каком этапе проект. Ответим в рабочее время, смету по брифу считаем за 2 дня.
- Смета по строкам, а не «от и до»
- Договор с этапами и приёмкой по спринтам
- Стек фиксируем на первом спринте: Flutter или нативно