Где хранятся цены и доступность?
Если каталог уже ведётся в кассовой системе, сначала проверяем обмен данными. Ручное дублирование меню в приложении создаёт риск расхождения цен и стоп-листа.
BORNLI / о разработке по делу
Приложение для доставки еды: от меню до принятого заказа.
Разбираем состав первой версии, зависимости от кассы и доставки и показываем, как проверить путь заказа на интерактивном прототипе.
Приложение для доставки еды
Заказ должен дойти от меню до кухни.
Покупатель выбирает блюда, видит итоговую стоимость, указывает адрес и получает понятный статус заказа. Для ресторана за этими экранами стоят актуальное меню, зоны доставки, способы оплаты и передача заказа команде. Если один из этих шагов остаётся ручным, состав приложения и смета будут другими.
Начинаем с карты действующего процесса: откуда берутся блюда и остатки, куда приходит заказ, кто меняет статус и как решаются отмены. Затем выбираем, что нужно в первой версии для одной точки или сети.
Модельный сценарий
Один заказ, три стороны.
Это собирательный пример для обсуждения продукта, а не описание клиента BORNLI, запущенного сервиса или результатов проекта.
01 / ГостьВыбирает
Блюда, способ получения и время
02 / РесторанПринимает
Проверенный заказ и передаёт его на кухню
03 / ДоставкаОбновляет
Статус, который видит гость
Модельный сценарий. Реальные роли и последовательность уточняются для каждого бизнеса.
Кто получает и подтверждает заказ?
Нужен понятный маршрут для нового заказа, изменения состава, отмены и возврата. Экран «заказ принят» должен показывать фактический статус.
Когда списываются деньги?
Онлайн-оплата, оплата при получении и бонусы меняют логику оформления. Провайдера платежей и правила возврата выбираем по вашему процессу.
Как рассчитывается доставка?
Зоны, минимальная сумма, стоимость и ожидаемое время должны совпадать с правилами ресторана. Для сети потребуется выбор точки и распределение заказов.
Посмотреть до разработки
Проверьте путь заказа в прототипе AVIOKI.
В открытом интерактивном прототипе AVIOKI можно пройти меню и поиск, карточку блюда, корзину, оформление, экран принятого заказа и отслеживание. Там есть тестовые цены и тестовые заказы. Прототип показывает интерфейс и переходы; реальная оплата и доставка в нём не работают.
Открыть интерактивный прототип AVIOKI ↗
AVIOKI — демонстрационный прототип, не опубликованное приложение доставки.
Состав первой версии
Сначала рабочий заказ, затем удержание.
Обсудить для запуска
- Каталог, карточка блюда и доступность позиций.
- Корзина, адрес или самовывоз, расчёт доставки.
- Передача заказа ресторану и реальные статусы.
- Оплата, подтверждение и обработка ошибки.
- Кабинет или интеграция для сотрудников.
Добавлять по задаче
- Бонусная программа и персональные предложения.
- Повтор заказа и сохранённые предпочтения.
- Несколько брендов, точек и отдельных меню.
- Собственные курьеры, диспетчеризация и маршруты.
- Глубокая аналитика и интеграции с CRM.
Функция из второго списка может быть обязательной именно для вашего бизнеса. Границу первой версии определяем после разбора процесса.
Если задача пока звучит как «приложение для доставки», полезно сначала выбрать один проверяемый путь. Разбор MVP поможет отличить рабочую первую версию от кликабельного прототипа.
Приёмка интеграций
Проверьте один заказ во всех системах.
Ниже — модельный план приёмки рабочей версии приложения доставки. Это предлагаемые проверки для будущего проекта, не описание возможностей прототипа AVIOKI или результатов BORNLI. Сценарии и ожидаемое поведение согласовывают до разработки.
- Блюдо исчезло из меню, пока гость собирал корзину. Перед подтверждением заказа приложение заново проверяет доступность и цену. Изменение видно гостю; замена блюда или новая сумма требуют его подтверждения.
- Гость дважды нажал «Заказать» или повторил действие после обрыва связи. В системе ресторана появляется один заказ. В приложении и у сотрудника совпадают его номер, состав и итоговая сумма.
- Платёж подтверждён, но ответ не дошёл до приложения. После восстановления связи приложение уточняет статус уже начатой оплаты. Гость видит, что происходит; повторная попытка не должна приводить к повторному списанию за тот же заказ.
- Система ресторана временно недоступна. Приложение не сообщает «заказ принят рестораном» без подтверждения. До запуска выбирают поведение: ожидание, уведомление сотруднику или остановка оформления. Проверяют и восстановление связи — потерянных и повторных заказов быть не должно.
- Заказ отменён после оплаты. Отмена заказа и возврат денег отображаются отдельными состояниями. Сотрудник видит, кто запустил возврат и чем он завершился; гость получает соответствующий фактическому состоянию статус.
Для каждой проверки в тестовой среде фиксируют номер заказа, исходные данные, ожидаемый и фактический результат в приложении, системе ресторана и платёжном кабинете. Назначают ответственного за разбор расхождений. Такой список помогает заранее определить, что именно команда должна показать при сдаче интеграции.
Стоимость и срок
Цена зависит от того, что уже работает за приложением.
Разработка мобильного приложения в BORNLI начинается от 300 000 ₽. Это нижняя граница для оценки, а не фиксированная цена сервиса доставки. Сумму меняют количество точек, интеграция с кассой, платежи, кабинеты сотрудников и логика курьеров.
Для типового согласованного объёма ориентир — 30 дней. Срок сервиса с несколькими системами и ролями определяем после проверки данных и интеграций. Подробнее о составе сметы.
После обсуждения задачи и получения материалов BORNLI готовит бесплатный кликабельный прототип за 24 часа, до договора. На нём можно согласовать основной путь заказа прежде, чем оценивать рабочую систему.
Перед оценкой
Пять ответов помогут быстро собрать прототип.
- Формат. Одна точка, сеть или несколько брендов?
- Меню. Где сейчас живут цены и стоп-лист?
- Заказ. Куда он приходит и кто меняет статус?
- Оплата. Какие способы нужны, кто делает возвраты?
- Доставка. Свои курьеры, агрегатор или только самовывоз?
Если ответы пока не оформлены в ТЗ, можно разобрать их вместе на первой встрече.
От идеи к конкретике
Покажем, как может работать ваш продукт.
Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.
Обсудить прототип ↗