Мобильное приложение для ресторана: где теряются заказы
Гость открывает мобильное приложение для ресторана, находит позицию в электронном меню в приложении — а на кухне её нет ещё с открытия: стоп-лист обновили на кассе, но не в приложении. Разговор с официантом ситуацию уже не спасает: часть гостей закрывает приложение и уходит к соседям, часть всё равно заказывает, и позицию снимают вручную при отдаче.
Корень проблемы в том, что меню живёт в двух независимых местах. Кассовая система держит актуальные остатки и стоп-лист, приложение — свою копию, которую обновляют вручную или по расписанию раз в сутки. Между обновлениями приём заказов идёт по устаревшему стоп-листу, и каждый такой заказ возвращается к гостю отказом уже после оплаты.
Брошенная корзина добавляет к этому свою долю. Гость собирает заказ, а на оформлении его встречает обязательная регистрация, повторный ввод адреса или изменившаяся цена — и корзина пустеет. При обрыве связи состояние теряется совсем: приложение не помнит, что уже выбрано, и заказ начинается с нуля.
Считать здесь нужно не установки и не открытия, а долю корзин, дошедших до оплаты, и число отказов по отсутствующим позициям. Дальше разбираем, как это закрывается: единый источник меню вместо двух копий, событийная синхронизация с кассой и корзина, которая переживает перезапуск и потерю сети.
Что даёт мобильное приложение владельцу заведения
Электронное меню и стоп-лист живут в одной панели: администратор меняет цену, состав или снимает позицию — гости видят это через минуту, без перепечатки и разноса правок по залу. Обновление стоп-листа перестаёт быть устной договорённостью смены и становится состоянием системы, поэтому официант не тратит вечер на объяснения «этого уже нет».
Самообслуживание гостей добавляет второй канал приёма заказа: гость открывает меню с телефона и собирает заказ сам. В часы пик это разгружает официантов и зал — часть столов закрывается без участия персонала, а посадка и оборот стола растут без расширения штата и площади.
История заказов и сохранённые предпочтения сокращают путь до повторного заказа до двух касаний. Заведение получает базу, по которой видно, кто возвращается и что берёт, — повторные заказы перестают зависеть от того, помнит ли гость конкретного сотрудника.
Отмены сокращаются на этапе приёма: состав, цена и добавки подтверждены до отправки на кухню, а расхождение «сказали — услышали» исчезает вместе с устным пересказом. Гость видит статус заказа сам и не дёргает персонал лишний раз.
Все эти эффекты измеримы: время обновления меню, доля заказов, оформленных самим гостем, доля повторных визитов, доля отмен — считаются по событиям в приложении, а не на ощущениях. Дальше на этих цифрах строится план развития заведения, а не спор о вкусах.
Собственное приложение, веб-меню и агрегатор: что выбрать
Гость садится за стол, сканирует код и хочет увидеть блюда за считанные секунды — на этом сценарии ломается большинство «универсальных» решений. Быстрее всех отвечает веб-меню по ссылке: открывается в браузере, установки не требует, правится со стороны зала за минуты. Дальше начинаются ограничения: нет push-уведомлений, доступ к функциям устройства урезан, а возвращается гость, только если сохранил ссылку.
Агрегатор доставки приводит поток заказов сразу, но ваше брендированное меню живёт внутри чужого интерфейса. Гость остаётся клиентом платформы: показы, комиссию и отзывы регулирует площадка, а история заказов и контакты остаются у неё. Собственное приложение заведения снимает эти ограничения — уведомления, программа лояльности, повторный заказ в один тап, — но требует установки и регулярных обновлений.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Веб-меню по ссылке | Нужен запуск за считанные дни, QR на столе, меню и предзаказ без установки | Нет уведомлений, урезанный доступ к функциям устройства, гость возвращается только по сохранённой ссылке |
| Агрегатор доставки | Нужен поток заказов сразу, логистику отдаёте площадке | Бренд живёт в чужом интерфейсе, условия задаёт площадка, данные о госте вам недоступны |
| Собственное приложение заведения | Лояльность, повторные визиты, история заказов, управление меню из зала | Нужна установка, свой канал привлечения и постоянная поддержка |
На практике три канала не конкурируют: веб-меню закрывает быстрый вход, приложение — повторные визиты и лояльность, агрегатор — приток новых гостей.
От схемы меню до публикации: этапы работы
Порядок этапов задан не для отчётности: меню меняется каждый сезон, а приложение живёт годами, поэтому ошибка в схеме данных на старте обходится дороже всего. Ниже — этапы разработки приложения от разбора меню до передачи ресторану.
- Разбор меню и сценариев гостя. Собираем категории, стоп-листы, сезонные позиции и путь гостя до отправки заказа: сколько экранов, где чаще уходят, чего не хватает официанту.
- Схема меню и модификаторов. Проектируем структуру данных — блюдо, группа, опция, доплата, доступность по времени и залу. После этого меню наполняет менеджер, без разработчика и без риска сломать экран.
- Связка с кассой и учётной системой. Обмен двусторонний: меню и стоп-листы приходят из учётной системы, заказы уходят обратно. Отдельно задаём поведение, когда касса недоступна: заказ встаёт в очередь и не теряется.
- Сборка приложения. Меню, корзина, оплата, лояльность — одна кодовая база на iOS и Android, чтобы цена и стоп-лист не расходились между платформами. Изображения кэшируются, список открывается даже на слабой сети.
- Тестовый запуск на зале. Две-три смены в обычном режиме: смотрим, где официант дублирует заказ руками, а гость бросает корзину. Правки вносим до публикации, а не после.
- Публикация в магазинах приложений и передача. Карточки, модерация, поэтапный выпуск на часть аудитории, версия для отката. Дальше — доступы, регламент обновления меню и дежурный инженер.
Комплект передачи: доступы, схемы, регламенты
Комплект передачи — это не папка с исходниками, а набор артефактов, с которыми ваша команда работает самостоятельно: без нас, но с полным пониманием, что где лежит и кто за что отвечает. Ниже — то, что мы фиксируем по акту, и по каждому пункту проверяем вместе, что доступ выдан и действительно работает.
- Доступы и роли сотрудников. Кабинеты управления меню, аналитики и уведомлений передаются на ваши учётные записи с правами владельца. Внутри настраиваем роли: управляющий меняет цены и состав разделов, менеджер зала правит стоп-лист и доступность блюд, официант только просматривает и подтверждает заказ.
- Схема связей систем. Один лист: приложение, панель меню, кассовая система, платёжный сервис, сервис уведомлений — кто с кем обменивается данными и что происходит с заказом при отказе одного из звеньев.
- Регламент обновления меню. Кто вносит изменения, в какой момент они появляются у гостя, как обновляется кэш на устройствах, что делать с блюдами, снятыми с продажи, чтобы они не остались в старых сборках.
- Инструкция для персонала зала. Открытие и закрытие смены, показ меню и оплата за столом, действия при потере связи, типовые вопросы гостей — на одну страницу, в помощь новому сотруднику.
- Магазины приложений. Аккаунты разработчика и карточки переведены на вас, ключи подписи и порядок выпуска обновлений задокументированы, выпускать новые версии может любая выбранная вами команда.
- Регламент поддержки и обновлений. Каналы обращений, приоритеты, сроки реакции на отказ оплаты или падение витрины, порядок согласования срочных правок в сезон.
- Схема данных и история изменений. Структура блюд, категорий и модификаторов с примером выгрузки — чтобы отчётность и интеграции можно было расширять без разбора приложения заново.
Итог передачи — вы управляете меню, ценами и ролями сами, а обращаетесь к нам за развитием, а не за каждой правкой позиции. Опишите задачу — вернёмся с планом работ и оценкой состава такого комплекта под ваш ресторан.
Кейс: сеть пиццерий убрала ручное обновление меню
До: правки в четырёх местах и опаздывающий стоп-лист
У сети пиццерий «Три печи» меню жило в четырёх независимых местах: сайт, приложение, агрегаторы доставки и касса в зале. Правку цены или состава вносили вручную в каждом — от 40 минут работы администратора, а в вечерний пик доходило до двух часов. Расхождения всплывали не сразу: гость видел на сайте одну цену, в агрегаторе другую, и это оседало возвратами.
Дороже обходился стоп-лист. Когда на кухне заканчивалась начинка, позицию снимали в приложении, но на остальных каналах она оставалась доступной ещё около часа. Заказ успевал уйти на кухню, оператор звонил гостю с отменой или заменой — отсюда и набегала основная доля отменённых заказов, порядка восьми процентов в пиковые смены.
Что изменили и что получилось
Меню свели к одному источнику: правка в админке расходится по сайту, приложению и агрегаторам в течение минуты, стоп-лист проставляется там же и гасит позицию во всех каналах одновременно. Локальный кэш держит меню на устройстве, поэтому в зале со слабой связью гость видит актуальный состав, а не вчерашний.
Обновление меню теперь занимает 2–3 минуты вместо часа, стоп-лист доезжает до всех точек продаж без ручных действий. Доля отменённых заказов сократилась примерно втрое — до 2–3%, а администраторы перестали дублировать одну правку в четырёх окнах и вернулись к работе в зале.
Что делать, если меню и цены меняются несколько раз в день?
Меню с несколькими правками в день ломает приложение, если оно хранит копию списка позиций у себя. Официант уже знает, что суп закончился, а гость в зале всё ещё видит его доступным и ждёт заказ — на разборе это самая частая причина негатива в отзывах. В таком сценарии каждая правка превращается в выпуск новой сборки, проверку в магазине и сутки ожидания.
Мы не дублируем меню внутри приложения: оно работает от единого источника данных — учётной системы ресторана, будь то iiko или другая касса. Позиции, цены, состав и доступность приходят оттуда, а в приложении остаётся только локальная копия для быстрого старта. Изменение, внесённое технологом, становится видимым гостям без участия разработчика.
Правки не уходят в зал мгновенно — работает отложенная публикация изменений. Новую цену или состав готовят черновиком и назначают время вступления: с открытия, к бизнес-ланчу, после закрытия кухни. Если что-то пошло не так, предыдущее состояние возвращается одной командой, а не откатом всего приложения.
Отдельно стоит проверка стоп-листа: ассортимент сверяется с фактическими остатками, и позиция автоматически переводится в «нет в наличии» — гость видит её недоступной, а не получает отказ после оформления заказа. Обновление без перезапуска означает, что актуальный набор подтягивается при старте, возврате из фона и по служебному сигналу: официанту не нужно просить гостя закрыть и снова открыть программу.
В итоге частые правки меню перестают быть проектной работой и становятся рутиной технолога в учётной системе, а зал и приложение показывают одно и то же. Ниже — как мы разворачиваем такую связку и что проверяем перед запуском.
Офлайн-режим, роли персонала и обновления: технические детали
Перед запуском приложения всплывают одни и те же вопросы: что будет в час пик при пропавшем Wi-Fi, кто из персонала что видит, как проходит оплата. Ниже — пять узлов, которые чаще всего разбираем с заказчиком до старта разработки.
Что произойдёт с заказом, если сеть пропала?
Приложение пишет заказ в локальную очередь и отправляет его, когда связь вернулась. Уникальный ключ операции не даёт создать дубль при повторной отправке, а меню и стоп-лист остаются доступны из локального кэша.
Как разграничить доступ персонала?
Доступ строится на ролях: официант, кухня, бар, менеджер, владелец. Права задаются на уровне операций — отправить заказ, отменить позицию, закрыть смену — и каждое действие попадает в журнал.
Как принимается оплата внутри приложения?
Платёж обрабатывает платёжный провайдер, приложение получает только результат и не хранит данные карты. Оплата возможна на кассе, через терминал или прямо в приложении, чек уходит в фискализацию.
Что можно менять после запуска?
Меню, цены, стоп-листы и акции правятся на сервере без пересборки приложения. Логика обновляется через магазины приложений, поэтому интерфейс обмена версионируется — устаревшая версия продолжает работать у гостя.
Какая аналитика заказов доступна?
Собираем события по заказам: состав, время от открытия меню до отправки, отмены, повторные визиты. Отчёты выгружаются в систему учёта, которая уже есть у ресторана, а не остаются внутри приложения.
Обсудим задачу и вернёмся с планом работ
Чтобы вернуться с планом работ, нам нужен минимум вводных: сколько точек и залов, какая касса и учётная система уже стоит, как сейчас обновляется меню и кто ведёт стоп-листы, есть ли доставка, на каких устройствах работают официанты. Этого хватает, чтобы оценить объём и не гонять вас по десяти уточняющим письмам.
К оценке прикладываем не перечень технологий, а документы, по которым видно, как приложение будет жить в ресторане:
- план работ по приложению: этапы, длительность каждого и что считается завершённым на выходе;
- состав работ и передачи — что именно уходит вам: код, конфигурации сборки, доступы, инструкции для администраторов зала;
- схема связей с кассой и кухней: какие данные и в какую сторону идут, где хранится меню, как ведёт себя приложение при обрыве связи;
- порядок проверки на зале: сценарии на реальном зале в час пик — стоп-лист, смена зала, печать заказа, гость с двумя устройствами;
- порядок запуска: пробный запуск на одной точке, поэтапное включение остальных, критерии перехода и условия отката;
- регламент поддержки: куда уходит обращение, за какое время реагируем, кто на стороне ресторана принимает решение.
Опишите задачу в удобном виде — переписка, созвон с технологом ресторана или доступ к текущему меню. Вернёмся с оценкой, планом работ и составом передачи.
