Два приложения доставки могут выглядеть для клиента почти одинаково: меню, корзина, оплата, статус заказа. А по объёму работы они различаются сильно — потому что за одним стоит только приём заказа, а за другим ещё кухня, учётная система, курьеры, зоны доставки и возвраты.
Это главное, что стоит понять до разговора о бюджете: цена приложения для доставки зависит не от числа экранов, а от того, сколько ролей и систем стоит за ними. Экраны клиента — видимая часть. Остальное не видно, но именно оно решает, во что обойдётся проект.
Ниже — как создать приложение для доставки еды или ресторана по шагам: кто в нём участвует, какие функции нужны в первой версии, с чем его придётся связать, какие ситуации продумать заранее и от чего зависит цена.
Сначала: зачем вам своё приложение
Вопрос не риторический — от ответа зависит, нужно ли приложение вообще.
Если нужны новые клиенты. Само по себе приложение — не канал первичного привлечения: чтобы его установить, человек должен уже знать заведение. Новых гостей приводят реклама, карты, агрегаторы доставки, и приложение их не заменяет.
Если нужны повторные заказы от своей базы — здесь приложение уже даёт понятную пользу. Человек, который заказывает у вас регулярно, получает короткий путь: открыл, повторил заказ, оплатил — и уведомление о статусе без звонка.
Если заказы приходят по телефону и в мессенджерах и теряются — начните с другого.
Если задача — просто перестать принимать заказы по телефону, дешевле начать с сайта с онлайн-заказом. Он решает ту же задачу и его не нужно скачивать. Приложение имеет смысл, когда люди заказывают у вас часто, а не раз в полгода.
Дальше — для тех, у кого приложение действительно оправдано: есть повторные заказы или уже понятна задача постоянного взаимодействия с клиентом.
Кто работает в приложении для доставки, кроме клиента
Общая логика ролей — кто работает с данными на другой стороне и почему это второй источник бюджета после сценариев — разобрана в статье про мобильное приложение для бизнеса. Здесь — как она выглядит именно в доставке.
Клиент. Выбирает блюда, указывает адрес, платит, следит за заказом, повторяет его. Это мобильное приложение для доставки еды в привычном смысле — то, что видно в сторах.
Кухня и оператор. Принимают заказ, подтверждают, отмечают «готовится» и «готов», ставят блюдо в стоп-лист, когда оно закончилось. Если в заведении уже стоит учётная система с кухонным экраном или печатью заказов, новый интерфейс для кухни может не понадобиться: заказ из приложения должен просто попасть туда же, куда попадает заказ с кассы.
Курьер. Видит назначенные заказы, адрес, состав, способ оплаты, отмечает «забрал» и «доставил». Здесь три пути, и они очень разные по деньгам:
- внешняя курьерская служба — приложение передаёт ей заказ, у курьера свой интерфейс от службы;
- свои курьеры без отдельного интерфейса — заказы приходят им сообщением или через бота, статусы отмечает оператор;
- свой интерфейс для курьеров — отдельное приложение, модуль внутри общей системы или веб-версия для телефона.
Третий вариант — это уже отдельный пользовательский интерфейс со своими ролями, состояниями и логикой; по объёму он может быть сопоставим с отдельным приложением. Его стоит заказывать, когда курьеров достаточно много, чтобы ручное назначение и звонки «где заказ» стали проблемой.
Управляющий. Меняет меню, цены, фото, зоны доставки, запускает акции, смотрит заказы. Если меню уже ведётся в учётной системе, приложение может брать его оттуда — и отдельная админ-панель нужна меньше. Если не ведётся, панель управления придётся строить.
Сводно:
| Роль | Что делает | Где может работать |
|---|---|---|
| Клиент | выбирает, платит, следит за заказом | мобильное приложение |
| Кухня и оператор | принимает, готовит, меняет статус | учётная система ресторана или панель заказов |
| Курьер | получает заказ, отмечает доставку | внешняя служба, сообщения или бот, свой интерфейс |
| Управляющий | меню, цены, зоны, акции | учётная система или админ-панель |
Главное, что видно из таблицы: не каждой роли нужно отдельное приложение. Прежде чем обсуждать дизайн экранов, напишите напротив каждой роли, где этот человек работает сейчас и где будет работать после запуска. Это лист, по которому считается бюджет.
Функции: что нужно в первой версии, а что может подождать
Список возможностей приложения доставки легко довести до тридцати пунктов. Полезнее разделить его на две части.
Без этого заказ не состоится:
- меню с категориями и карточками блюд — фото, состав, вес, цена;
- корзина и оформление заказа;
- адрес, проверка зоны доставки и минимальной суммы;
- оплата — онлайн или при получении;
- статус заказа: принят, готовится, в пути, доставлен.
История заказов и повтор в одно касание стоят на границе. Для доставки с повторными заказами я бы включал их уже в первую версию: именно здесь появляется преимущество приложения перед обычной формой заказа на сайте. Если первая версия нужна только чтобы проверить, будут ли вообще заказывать через приложение, их можно отложить.
Может подождать до второй версии:
- программа лояльности, бонусы, промокоды;
- отзывы и оценки блюд;
- отслеживание курьера на карте в реальном времени;
- чат с оператором или курьером;
- персональные подборки и рекомендации.
Вторая часть не хуже первой — просто каждая её строка проверяется на живых заказах. Программу лояльности разумно проектировать, когда понятно, как часто люди заказывают; отслеживание на карте — когда понятно, сколько вопросов «где мой заказ» приходит на самом деле.
Для ресторана список немного другой. Мобильное приложение для ресторана может включать не только доставку, но и самовывоз, предзаказ к определённому времени, бронирование стола. Каждый из этих сценариев — отдельная ветка со своими правилами: заказ к 19:30 должен уйти на кухню не сразу, а за нужное время; бронь — проверять свободные столы. Берите в первую версию тот сценарий, через который у вас сейчас больше всего обращений, а не все сразу.
Статусы заказа и исключения — то, о чём не думают на старте
Самая недооценённая часть приложения доставки — не экраны, а жизненный цикл заказа. Его удобно расписать таблицей ещё до оценки:
| Статус | Кто меняет | Что видит клиент |
|---|---|---|
| Принят | система, после оплаты или подтверждения | «Заказ принят» |
| Готовится | кухня или оператор | «Готовим» |
| Передан курьеру | кухня, оператор или курьер | «Курьер забрал заказ» |
| Доставлен | курьер или оператор | «Доставлен», предложение повторить |
| Отменён | клиент или оператор | причина и возврат денег |
Простой путь описывается одной строкой таблицы. Объём работы уходит на исключения — ситуации, когда заказ идёт не по плану. По каждой нужно заранее решить, кто её обрабатывает и что видит клиент:
| Ситуация | Что решить заранее |
|---|---|
| Блюдо закончилось после оплаты | предложить замену или вернуть часть суммы |
| Курьер задерживается | кто меняет время доставки и как об этом узнаёт клиент |
| Клиент хочет отменить заказ | до какого статуса отмена возможна и что с деньгами |
| Курьер не может дозвониться | сколько ждать и что делать с заказом |
| Оплата не прошла | создаётся ли заказ и что видит клиент |
Если это не решено до разработки, решать придётся во время неё — и это одна из причин, по которой сроки расходятся с ожиданием. Для оценки не нужен готовый документ: достаточно, чтобы вы могли ответить на вопрос «а что происходит, если…» по каждой строке.
С чем приложение придётся связать
Интеграции не видно на экранах, но объём работы зависит от них напрямую. Вот связки, о которых стоит подумать в любом проекте общепита.
Учётная система ресторана. Если меню, цены и стоп-лист живут в учётной системе — iiko, r_keeper или другой, — приложение должно брать их оттуда и отдавать туда заказы. Иначе меню придётся вести в двух местах, и однажды клиент закажет то, чего уже нет. Сложность зависит от того, какой способ обмена система даёт: готовый API — одна история, выгрузка файлов — другая.
Онлайн-оплата и чеки. Приём оплаты подключается через платёжный сервис. Вместе с ним нужно решить вопрос кассовых чеков: на расчёты онлайн распространяются требования закона о контрольно-кассовой технике (54-ФЗ). Как именно чек формируется и уходит покупателю, зависит от вашей схемы расчётов, платёжного сервиса и онлайн-кассы — и это решается до запуска, а не после первой претензии.
Адреса и зоны доставки. Клиент вводит адрес — приложение должно понять, попадает ли он в зону, сколько стоит доставка и какая минимальная сумма заказа. Для этого нужны сервис адресов и карт и описанные вами зоны. Платные тарифы картографических сервисов — отдельная строка расходов, не разработки.
Push-уведомления. Статус заказа — самый оправданный повод для уведомления, его ждут. Как отделить такие сообщения от рекламных, чтобы человек не отключил всё сразу, — в разборе про push-уведомления.
Курьерская служба или CRM. Если доставку выполняет внешняя служба или заказы нужно видеть в CRM, это ещё одна связка со своим способом обмена.
Сколько стоит приложение для доставки еды
Полноценное мобильное приложение для iOS и Android начинается от 950 000 ₽. В эту оценку входят разбор сценариев, дизайн, разработка клиентского приложения с заказами и личным кабинетом, тестирование, подготовка к публикации в сторах и интеграция с действующей серверной частью или CRM — если она уже есть.
Важно: 950 000 ₽ — не цена всей цифровой системы доставки при любом исходном состоянии. Это нижняя граница для клиентского мобильного приложения, которое опирается на уже существующую серверную часть. Отдельно оцениваются создание серверной части и админ-панели с нуля, сложные интеграции и дополнительные роли со своими экранами. Поэтому сумма прямо зависит от ответов из разделов выше:
- меню и заказы уже живут в учётной системе с API — приложение опирается на неё, и бюджет ближе к нижней границе;
- такой системы нет — нужна своя серверная часть и панель управления;
- курьеры работают через внешнюю службу или по сообщениям — клиентская часть остаётся основной;
- нужен свой интерфейс для курьеров — это вторая роль со своими экранами и своим объёмом.
Сроки по приложениям я заранее не называю: они зависят от ролей и интеграций сильнее, чем от тарифа. Точный срок — после разбора задачи.
Можно ли начать дешевле. Первая версия начинается от 250 000 ₽ — но это ориентир для одного ключевого сценария. Несколько ролей, платежи, карты и интеграции в эту сумму не входят и оцениваются отдельно, как и публикация в сторах. Для доставки это значит: самая недорогая проверка — заказ из меню без сложных интеграций, который передаётся оператору: без карты зон и без связки с учётной системой. Если бизнес допускает оплату при получении, на первом этапе можно обойтись и без онлайн-эквайринга. Каждая из этих связок добавляет к сумме, и полноценная доставка за нижнюю границу MVP не помещается. Зато такая проверка отвечает на главный вопрос — будут ли ваши клиенты заказывать через приложение — до того, как вы вложите основную сумму.
Как это выглядело на реальном проекте
Одно из моих приложений — как раз приложение доставки еды: меню, карточки блюд, состав и оформление заказа. Задача была перенести заказы в удобное мобильное приложение, и в приложении собран именно главный путь клиента — от выбора блюда до оформления заказа.
Клиент, Денис Герасимов, оставил отзыв, и в нём есть фраза: «Проект завершён значительно быстрее, чем я ожидал, — мы оперативно вышли на рынок». Для первой версии это хороший критерий: не максимальное число функций, а то, как быстро основной сценарий начинает работать на реальных заказах. Всё, что сверх главного пути, можно добавить, когда заказы уже идут и видно, чего не хватает.
Шесть вопросов, после которых приложение уже можно оценивать
Чтобы оценка была предметной, а не «от и до», достаточно ответить на шесть вопросов:
- Где сейчас живут меню и заказы — в учётной системе (какой), в таблице, нигде.
- Кто доставляет — свои курьеры, внешняя служба, агрегатор, только самовывоз.
- Как платят — онлайн, при получении, оба способа.
- Как устроены зоны доставки и от чего зависит её стоимость.
- Какой сценарий главный — доставка, самовывоз, предзаказ, бронь.
- Что обязательно в первой версии, а что можно отложить.
С этими ответами можно сказать, какой формат вам подходит — полноценное приложение, первая версия или сайт с онлайн-заказом, — какие роли и связки в него войдут и из чего сложится сумма. Иногда честный ответ — что приложение вам пока не нужно, и это тоже результат разбора.