Онлайн-заказы ресторана: меню, кухня и слоты приёма

Гость оплатил ужин на сайте, но администратор ещё не увидел заявку, а кухня уже закрыла горячий цех. Онлайн-заказы ресторана в такой ситуации нельзя считать принятыми только потому, что сработала кнопка оплаты. Перед запуском прямого канала нужно согласовать три вещи: какое меню действительно доступно, кто подтверждает приготовление и сколько заказов заведение может выполнить в выбранное время.

Начинайте с правил обещания гостю, а не с выбора между сайтом и приложением. Ниже — план для владельца ресторана и операционного руководителя: как подготовить меню, приём и временные слоты, проверить сбои и определить границы первого запуска. Это не инструкция по маршрутизации курьеров и не обзор всех систем управления заказами.

Сначала согласуйте момент принятия заказа

Разделите получение заявки, подтверждение оплаты и согласие кухни на выполнение. Для каждого события нужны ответственный, запись в системе и понятное сообщение гостю. Фраза «заказ принят» должна означать, что заведение проверило состав, время и возможность приготовления, а не только сохранило корзину.

Согласуйте, подтверждает ли администратор каждый заказ или система делает это автоматически при определённых условиях. В первом случае нужны дежурства и контроль пропущенных заявок. Во втором — проверка доступности блюд, мощности кухни и действующего расписания перед подтверждением. Автоматизация без этих ограничений лишь быстрее раздаёт невыполнимые обещания.

Определите владельца каждого решения

Меню и цены может вести учётная система, стоп-лист — ответственный сотрудник смены, доступные слоты — модуль заказов. Это возможное распределение, а не универсальная архитектура. Запишите, где именно меняют данные, как они попадают на сайт и кто вправе приостановить приём. Иначе у сайта и кухни будут две разные версии правды.

Превратите меню в правила продажи

Фотография и название блюда не описывают его доступность. Для каждой позиции определите вариант, порцию, цену, разрешённые дополнения, часы продажи и точку приготовления. Сотрудник кухни должен получить однозначный состав: «без лука» не должно потеряться в общем комментарии к адресу.

Синхронизация меню ресторана требует отдельных правил для изменения цены и временного отсутствия. Уточните, передаёт ли учёт готовые порции, ингредиенты или только ручной стоп-лист. Остаток продукта сам по себе не доказывает, что блюдо можно продать: могут быть недоступны нужный сотрудник, оборудование или упаковка.

Повторно проверяйте корзину перед подтверждением

Пока гость заполняет контакты, блюдо может исчезнуть из продажи. Проверьте доступность и итоговую сумму на сервере перед созданием подтверждённого заказа. Если состав изменился, объясните причину и предложите пересмотреть корзину. Не заменяйте позицию другой без согласия гостя.

Для наборов и модификаторов проверяйте сочетания, а не только базовое блюдо. Недоступный соус может блокировать определённый набор, но не всё меню. Информацию о составе и аллергенах должен согласовать ответственный заведения; свободный комментарий гостя нельзя превращать в автоматическую гарантию безопасного приготовления.

Слоты должны отражать работу кухни

Временной слот — доступное окно получения заказа, а не декоративный список часов. Его границы зависят от подготовки, загрузки цехов, упаковки и способа получения. Самовывоз и доставка могут использовать одну кухню, поэтому их не стоит считать двумя независимыми неограниченными очередями.

Слоты самовывоза сначала можно ограничивать понятным правилом вместимости, согласованным руководителем смены. Для сложного меню одна заявка не равна другой: большой набор и напиток нагружают кухню по-разному. Не начинайте со сложного прогнозирования, если ещё нет проверенных данных о приготовлении.

Отделите статус кухни от статуса оплаты

В гостевом интерфейсе могут быть простые состояния: «ожидает подтверждения», «готовится», «готов к выдаче», «выдан» и «отменён». Внутри системы дополнительно нужны причина остановки и ответственный. Оплаченный заказ может ещё ждать кухню, а подтверждённый к приготовлению — предусматривать оплату при получении, если этот способ разрешён.

Официальная документация Square отдельно описывает начальное состояние выполнения PROPOSED и ограничения отображения заказов в своих продуктах. Это полезный пример того, почему созданная запись не равна видимому заданию для персонала. Однако правила Square не являются стандартом для всех кассовых систем и не доказывают доступность конкретного решения в вашей стране.

Перед выбором интеграции попросите проверить в тестовой среде вашу кассовую систему, или POS, и кухонный экран, или KDS. Видна ли неоплаченная заявка? Передаются ли модификаторы? Возвращается ли отказ кухни на сайт? Поддерживаются ли изменения после принятия? Наличие API — программного интерфейса обмена — не отвечает на эти вопросы.

Отмена должна завершать и финансовое действие

Определите порядок оплаты, списания или резервирования средств в соответствии с возможностями выбранного платёжного сервиса. Если кухня отказала после платежа, нужны сообщение гостю, ответственный за возврат и контроль его результата. Не называйте возврат завершённым только потому, что отправили запрос.

Повторное сообщение платёжного сервиса не должно запускать второе приготовление. Документация Stripe об обработке webhook-событий прямо рассматривает дубликаты и порядок поступления. Проектируйте защиту от повторного действия и сверку состояний для своего провайдера, не предполагая, что все сообщения приходят один раз и вовремя.

Условный пример: последняя порция и занятое окно

Представим ресторан с одним пунктом самовывоза. Это учебный сценарий, а не кейс GL.ua. На сайте осталась одна доступная порция лазаньи, а для ближайшего окна руководитель смены разрешил принять ещё один заказ. Двое гостей одновременно открыли корзины с этим блюдом.

При подтверждении первая корзина занимает порцию и место в окне как одну согласованную операцию. Второй гость получает сообщение, что условия изменились: блюдо уже нельзя заказать, а доступное время нужно выбрать заново. Одного отключения кнопки после обновления страницы недостаточно — решение должно проверяться в системе, принимающей заказы.

Далее администратор принимает первую заявку, но ответ на сайт теряется. Повторный запрос с тем же идентификатором должен вернуть существующий результат, а не создать ещё один кухонный чек. Если гость бросил оплату, временный резерв освобождается по согласованному правилу. Конкретный срок резерва определяют при проектировании, а не берут из произвольного шаблона.

Пройдите проверку до открытия канала гостям

Для пилота выберите одну точку, ограниченное меню и согласованный способ получения. Это уменьшает число зависимостей, но не отменяет проверку отказов. Администратор и представитель кухни должны пройти сценарии вместе, а не получить только видео успешной покупки.

1. Измените цену и стоп-лист, пока корзина открыта. Сверьте итоговый состав и объяснение гостю до платежа или подтверждения.
2. Отправьте одновременные заявки на последнюю порцию и последнее место в слоте. Убедитесь, что система не подтвердила обе.
3. Отключите приёмное устройство или обмен с POS. Проверьте сигнал ответственному, сообщение гостю и возможность приостановить канал.
4. Повторите платёжное сообщение и запрос создания заказа. На кухне должно остаться одно задание без повторного списания из-за собственной логики сайта.
5. Отмените заявку до принятия и после начала приготовления. Сверьте разрешённые действия, возврат и журнал решений, не предполагая одинаковых правил для обоих моментов.
6. Пройдите предзаказ, закрытие смены и изменение доступного времени с телефона. Проверьте все сообщения и фактическое появление задания на кухне.

Тексты ожидания и ошибок стоит согласовать ещё в спецификации состояний интерфейса. Протокол приёмки должен содержать не «всё работает», а ожидаемый и фактический результат каждого теста, ответственного и решение по найденному расхождению.

Что ограничивает запуск, сроки и бюджет

Основные риски здесь операционные: устаревший стоп-лист, незамеченная заявка, переоценённая вместимость слота и нечёткий порядок отмены. Добавьте технические зависимости: недоступность POS, задержку сообщений и разные идентификаторы блюд. Для каждого риска нужны способ обнаружения и разрешённое действие смены. Ручной резервный процесс должен быть описан, а не держаться на памяти администратора.

Сроки зависят от готовности меню, доступов к тестовому учёту, поддерживаемых операций интеграции и времени персонала на проверку. Планируйте отдельные результаты: согласованный процесс, прототип, тестовый обмен, проверку исключений, обучение и ограниченный запуск. Если документации POS недостаточно, сначала нужна техническая проба, а не календарное обещание на весь проект.

В стоимость входят анализ и подготовка данных, интерфейс меню и корзины, правила слотов, обмен с кассой и кухней, платёжный сценарий, уведомления, тестирование и обучение. Отдельно учтите хостинг, тарифы сервисов, мониторинг, обновления и поддержку. Фискальные и правовые требования проверяют для конкретной модели работы с соответствующими специалистами; подключённый платёжный модуль сам по себе их не закрывает.

Доставку добавляйте только после определения ответственности за готовность и выдачу. Планирование перевозки относится к другому контуру; его границы объясняет материал об интеграции сайта с TMS. Для первого самовывоза отдельная транспортная система может быть лишней.

Начните с выполнимого обещания гостю

Прямой канал готов к пилоту, когда меню соответствует реальной доступности, кухня видит и принимает задания, а слот не продаёт больше мощности, чем согласовало заведение. Если этого нет, новый дизайн или приложение не устранят разрыв. Сначала проверьте один полный маршрут и право смены остановить приём, затем расширяйте меню и аудиторию.

Для подготовки такого канала обратитесь к GL.ua (Глянец) по вопросу разработки онлайн-магазина с интеграциями. Передайте пример меню, описание приёма, данные о кассовой системе и сценарии отказов: это основа проверки осуществимости и оценки, а не повод сразу заказывать все возможные функции.