Короткий ответ: выберите одно действие, ради которого гость вернётся
Список функций не отвечает на главный вопрос: зачем человек откроет приложение второй раз? Если он регулярно заказывает напрямую, ядром может стать путь от актуального меню до подтверждённой выдачи. Если визит начинается с выбора времени, ядром станет бронь. Если гости уже приходят, но ресторан теряет связь между визитами, можно начать с идентификации и единого бонусного баланса.
Три кандидата на ядро
Заказ
Ценность — быстро повторить покупку. Главный риск — приложение продаёт недоступную позицию.
Бронь
Ценность — получить подтверждённый стол. Главный риск — конфликт с телефоном и журналом хостес.
Лояльность
Ценность — видеть баланс и повод вернуться. Главный риск — расхождение с кассой.
Не пытайтесь сделать три ядра одновременно. Остальные сценарии могут поддерживать первый, но не должны превращать запуск в переделку всех процессов ресторана. Выбор защищают наблюдаемым повторным действием, доступными данными и готовностью сотрудников исполнять новый поток.
App, TMA, сайт или готовый сервис: когда приложение не нужно
Собственное приложение — не обязательная ступень взросления ресторана. Агрегатор полезен, когда нужен внешний спрос. Сайт или PWA удобнее для редкого заказа из поиска и не требует установки. Telegram Mini App подходит, если аудитория уже приходит из Telegram, а сценарий укладывается в ограничения платформы. Виджет бронирования и готовая система лояльности быстрее закрывают стандартную узкую задачу.
Приложение преждевременно, если меню и стоп-лист всё равно обновляют вручную в нескольких местах, сотрудники не могут быстро подтверждать заказ или бронь, источника установок нет, а повторный сценарий не доказан. Новый интерфейс поверх старого ручного процесса увеличит число расхождений. Иногда верное решение — сначала наладить единый каталог и статусы, а канал выбрать позже.
Агрегатор и собственный канал могут сосуществовать. Первый отвечает за знакомство, второй — за удобное повторение уже понятного действия. Сравнение форматов подробнее разобрано в материале о выборе между сайтом, магазином и приложением: он полезен до того, как команда зафиксирует дорогой формат.
Меню, модификаторы, стоп-лист и цена: сначала источник истины
Карточка блюда кажется простым экраном, пока у позиции не появляются размер, добавки, исключения, разные цены по филиалам и временная недоступность. Для каждого поля нужен ответственный источник: где хранится название, кто меняет цену, откуда приходит стоп-лист, какие сочетания модификаторов допустимы и когда обновление считается применённым.
Приложение не должно угадывать наличие. Перед подтверждением backend — серверная часть — повторно проверяет ресторан, время, цену, состав и доступность. Если позиция исчезла, гость получает понятный выбор: убрать её, заменить или отменить оформление. Молчаливое изменение корзины экономит один экран, но разрушает доверие.
Представьте заказ с блюдом и двумя добавками. Повтор запроса из-за плохой связи не должен создать второй заказ, а запоздавший стоп-лист — принять оплату за то, что кухня уже не приготовит. Поэтому у операции есть внутренний идентификатор, версия данных и журнал событий. Это технические детали только на первый взгляд: для ресторана они означают меньше ручных звонков и понятную причину ошибки.
Заказ в зале, навынос и доставка — разные исполнения одного обещания
Путь гостя начинается с меню, но заканчивается не кнопкой «Оплатить». Ресторан должен принять заказ, кухня — подтвердить исполнение, а приложение — показывать только проверенный статус. Для заказа в зале важны стол и обслуживание; для навыноса — точка и окно выдачи; для доставки — адрес, зона, стоимость, курьер и передача ответственности.
Минимальный паспорт заказа хранит внутренний и внешний ID, филиал, канал, позиции и модификаторы, цену и скидки, способ получения, контакт, статус заказа, статус оплаты, временные отметки и причину отмены. Это проектная модель, а не универсальная схема любой POS. Конкретный набор полей проверяют по доступному API и ресторанному процессу.
Бронь: стол, подтверждение, депозит и no-show
Онлайн-календарь не решает бронь, если хостес ведёт отдельный журнал. Сервер должен атомарно подтвердить слот: два гостя не могут получить один ресурс из-за почти одновременного запроса. До разработки определяют, что резервируется — конкретный стол, зона или число мест, — кто может изменить бронь и как учитываются объединённые столы.
Депозит добавляет отдельные состояния: создан, ожидает оплаты, подтверждён, возвращается, удержан по согласованному правилу. Условия отмены и неявки показывают до оплаты, а статус депозита не подменяет статус стола. Если ресторан не умеет достоверно отмечать факт визита, метрика no-show будет спорной независимо от качества интерфейса.
Для стандартной посадки готовая система бронирования может оказаться лучше собственной разработки: у неё уже есть рабочее место хостес и виджет. Приложение оправдано, когда бронь связана с доказанным повторным опытом гостя и ресторан готов поддерживать единый источник доступности.
Оплата, кассовый чек, возврат и статусы
На 30 июля 2026 года Apple и Google отделяют цифровые покупки от физических товаров и услуг. Еда, доставка и ресторанное обслуживание оплачиваются не через Apple In-App Purchase или Google Play Billing, а через собственный эквайринг или платёжного провайдера. Исключение нельзя переносить на платную цифровую функцию или продаваемую виртуальную валюту — такой сценарий проверяют отдельно.
Статус «деньги получены» не означает «кухня приняла заказ». Иначе гость увидит банковское списание при закрытой кухне или недоступной позиции. Модель различает создание заказа, проверку состава, ожидание оплаты, подтверждение платежа, принятие рестораном, приготовление, готовность, передачу, завершение, отмену и возврат.
Кассовый сценарий зависит от обслуживания в заведении, предоплаты, самовывоза, собственной или сторонней доставки. ФНС разделяет эти ситуации; один шаблон чека нельзя механически применить ко всем. Схему формирования, зачёта предоплаты, коррекции и возврата утверждают с оператором ККТ и налоговым специалистом под конкретный процесс. Приложение передаёт кассовому контуру состав, сумму, способ и тип расчёта, но не заменяет такую проверку.
Аккаунт, данные и доступ для проверки
Не закрывайте меню обязательным входом, если оно работает без профиля. Аккаунт оправдан для истории заказов, сохранённых адресов, бонусов и персональных настроек. Если пользователь создаёт профиль, в продуктовый контур входит его удаление: Apple требует доступный путь внутри приложения, Google Play — также внешний веб-путь. При этом часть записей о расчётах может храниться на законном основании; политику хранения и удаления согласуют с юристом и объясняют человеку простым языком.
Политика конфиденциальности должна отражать не только собственный сервер. Проверьте, какие данные получают CRM, аналитика, push-провайдер, карты, эквайринг и доставка. Декларации в магазинах сверяют с реальным поведением сборки и сторонних SDK. Для геолокации оставляют ручной ввод адреса там, где он позволяет выполнить заказ.
Модератору нужен воспроизводимый путь по функциям: рабочая демонстрационная учётная запись или полноценный демонстрационный режим, тестовые инструкции и безопасная оплата без реального визита. Если бронь доступна только в часы работы или меню зависит от филиала, это описывают в заметках к проверке. Такой пакет не гарантирует одобрение, зато снимает блокер «функцию невозможно проверить».
Лояльность и push: повторный визит нельзя включить переключателем
Бонусный баланс считает сервер или профильная CRM, а приложение показывает подтверждённые операции. Отдельные состояния нужны для ожидаемого и подтверждённого начисления, резерва и списания, отмены и истечения. Иначе повторный запрос может дважды списать бонусы, а возврат заказа — оставить незаслуженное начисление.
Заработанные баллы программы лояльности не превращаются автоматически в цифровую покупку магазина приложений. Но продажа пакета виртуальной валюты или платного цифрового уровня — другой сценарий. Его нельзя маскировать под обычную ресторанную лояльность.
Push полезен для подтверждённого изменения: заказ принят, стол подтверждён, возврат завершён. Маркетинговые сообщения требуют отдельного согласия и понятного отказа; системное разрешение телефона не равно согласию на рекламу. Отказ от push не должен блокировать заказ, бронь или бонусный счёт. Повторный визит измеряют поведением, а не числом отправленных уведомлений.
POS, касса, CRM, 1С и доставка: карта владельцев данных
Универсальной связи «приложение подключается ко всему» нет. POS может владеть заказом, CRM — бонусным балансом, учётная система — номенклатурой, а доступность блюда определяет отдельный ресторанный контур. До интеграции для каждого объекта фиксируют источник истины, направление обмена, допустимую задержку, защиту от повтора, поведение при недоступности и ручное восстановление.
Серверная часть координирует каналы гостя и ресторанные системы, хранит внутренний ID и журнал ошибок. Она не гарантирует мгновенный обмен: если внешний сервис отвечает с задержкой, интерфейс должен честно показать ожидание, а оператор — получить задачу. Ручной резервный путь не признак плохой автоматизации, а способ безопасно пережить отказ.
Курьер и оператор: собственная доставка — отдельный продуктовый контур
Если ресторан доставляет сам, одного гостевого приложения недостаточно. Оператор видит неподтверждённые и проблемные заказы, меняет назначение и связывается с гостем. Курьер получает только нужные данные: адрес, контакт, состав передачи и допустимые статусы. Геолокация удобна, но ручной ввод адреса остаётся рабочей альтернативой.
Нужно заранее определить зоны, способ расчёта стоимости, момент назначения курьера, подтверждение передачи и поведение при недоступном адресе. Собственный сложный диспетчер не обязан входить в P0, если доставка не является ядром. Полный blueprint доставки раскрыт в отдельной статье о мобильном приложении для доставки еды; здесь важна граница ответственности ресторана.
Что подтверждает опыт 13FOX — и чего он не подтверждает
У 13FOX нет опубликованного ресторанного кейса. Поэтому мы не приписываем себе интеграции с конкретной ресторанной POS и не обещаем рост повторных заказов. Есть соседний публичный кейс, полезный для сравнения механик записи, но не как доказательство результатов в HoReCa.
В приложении для студии маникюра подтверждены выбор времени, запись, история посещений и механики лояльности. Этот опыт помогает разложить бронь и повторный контакт, но ничего не говорит о столах, кухне, доставке или депозитах ресторана.
Общий переносимый принцип прост: сначала один сценарий, затем источники данных, статусы, ответственные и проверка исключений. В руководстве по заказу MVP можно посмотреть, как превратить гипотезу в ограниченный объём работ; цены и сроки из соседних задач нельзя автоматически переносить на ресторан.
P0, пилот на одной точке и метрики без чужих нормативов
P0 — всё, без чего выбранное обещание небезопасно. Для заказа это актуальное меню, модификаторы, стоп-лист, подтверждение рестораном, оплата, статусы и защита от дубля. Для брони — единая доступность, подтверждение, изменение, отмена и связь с оператором. Для лояльности — идентификация, правила начисления и списания, единый баланс и история.
P1 делает пилот управляемым: уведомления, панель оператора, журнал ошибок, поддержка, события аналитики и правила возврата. P2 расширяет продукт после проверки: дополнительные ресторанные сценарии, сложная персонализация, курьерский контур или автоматизация редких исключений. Эти уровни не задают срок и бюджет.
Пилот ограничивают одной точкой или одним операционным контуром. До запуска фиксируют события и правила исключения тестовых операций. Для заказа смотрят путь до подтверждения, отмены из-за стоп-листа, расхождения цены, ручные исправления, дубли и ошибки возврата. Для брони — подтверждения, конфликты доступности, изменения и неявки, если визит действительно отмечается. Для лояльности — успешность начисления и списания, расхождения баланса и повторное использование.
Универсального «хорошего процента» здесь нет. Ресторан задаёт исходный уровень и допустимый риск сам. Переходить дальше можно, когда статусы совпадают с реальностью, сотрудники понимают процесс, у ошибок есть ответственный, а гость завершает сценарий без обязательного ручного спасения.
Источники и дата проверки
Правила платформ и кассовые разъяснения проверены 30 июля 2026 года. Перед релизом их нужно сверять заново: политики магазинов и требования к конкретной модели расчётов меняются.
- Apple App Review Guidelines: физические товары и услуги, доступ для проверки, аккаунт, данные и push.
- Google Play Payments policy: граница магазинного биллинга и физических услуг.
- Google Play User Data policy: политика конфиденциальности и поведение SDK.
- ФНС: кассовый чек в сфере общественного питания.
FAQ
Что выбрать ядром MVP ресторана: заказ, бронь или лояльность?
Выберите действие, которое гость уже готов повторять и которое ресторан способен исполнять без ручных расхождений. Для одних заведений это прямой заказ, для других — подтверждённая бронь или единый бонусный баланс. Остальные сценарии можно добавить после пилота.
Когда ресторану не нужно собственное мобильное приложение?
Приложение преждевременно, если нет устойчивого повторного сценария, меню и стоп-лист обновляются вручную в нескольких местах, ресторан не может быстро подтверждать заказ или бронь либо задачу уже закрывают сайт, TMA, агрегатор, сервис бронирования или готовая платформа лояльности.
Нужны ли Apple In-App Purchase или Google Play Billing для оплаты еды?
Нет. Оплата еды, доставки и других физических товаров или услуг относится к покупкам вне магазинного биллинга. Ресторан использует собственный эквайринг или платёжного провайдера, но отдельно решает вопросы кассового чека, возврата и синхронизации статусов.
Можно ли одним приложением заменить агрегатор?
Автоматически — нет. Агрегатор может приводить новый спрос, а собственный канал обслуживать доказанный повторный сценарий. Приложению нужны причина для установки, источник аудитории и операционная готовность ресторана.
Что интегрировать с приложением ресторана?
Состав зависит от процессов и используемых систем. Обычно рассматривают POS или кассу, CRM или платформу лояльности, учётный контур, эквайринг, бронирование и доставку. Для меню, цены, стоп-листа, заказа, оплаты, брони и бонусов заранее назначают источник истины.
Какие метрики смотреть в пилоте без отраслевых нормативов?
Смотрите прохождение выбранного сценария и операционные ошибки: подтверждённые заказы или брони, отмены по стоп-листу, расхождения цены и статуса, ручные исправления, дубли, ошибки оплаты и возврата, расхождения бонусного баланса и повторное использование канала.
Разберём один повторный сценарий до оценки разработки
Пришлите список филиалов, текущие каналы заказа, правила брони и лояльности, используемые POS/кассу/CRM, примеры стоп-листа и несколько недавних сбоев. На первой встрече 13FOX определит кандидата на ядро, источники истины, роли и критические исключения. На выходе вы получите карту систем, черновик P0/P1/P2 и список интеграционных рисков. Если задачу лучше закрывает сайт, TMA или готовый сервис, скажем об этом до полноценной разработки.