Заказ со стола без отдельного приложения: как работает Умное кафе

В «Умном кафе» гость может заказать со стола без установки отдельного приложения заведения. Он открывает ссылку в браузере либо мини-приложении Telegram или MAX, выбирает блюда, подтверждает стол и отправляет заказ. Сервер проверяет данные, создаёт заказ, а рабочий интерфейс смены показывает его сотруднику.

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

Если читать 30 секунд

• Ссылка стола разрешается в заведение и tableId; при прямом входе в точку стол выбирают при оформлении.
• Корзина хранится для конкретного заведения, а сервер повторно проверяет позиции и стоимость.
• Заказ без авторизации через мессенджер принимается только там, где разрешены веб-заказы, либо в отдельном демо-сценарии.
• После создания гость видит экран статуса, а сотрудник — карточку заказа со столом, составом, комментарием и действиями статуса.
• Публичное демо показывает только гостевую дорожку; реальные уведомления персоналу и служебный приём в нём не проверяются.

Две дорожки одного заказа

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

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

Граница проходит после серверного создания. До неё интерфейс собирает намерение гостя. После неё заказ становится операционной задачей заведения.

Только гостевую колонку схемы можно репетировать в публичном демо: там доступны меню, корзина, оформление и экран статуса. Получение реальной сменой, служебные роли и изменение статуса эта проверка не подтверждает.

Шаг 1. Вход сохраняет место заказа

Настольная ссылка /t/<qrKey> передаёт ключ, который сервер разрешает в конкретные точку и стол. Приложение сохраняет placeId, tableId, номер и название заведения. В мини-приложении тот же ключ может прийти как стартовый параметр.

Если человек открывает общий адрес /s/<slug> или выбирает точку в браузере, tableId заранее отсутствует. В столовом режиме форма предложит выбрать стол из списка. Это допустимо вне зала, но на настольной табличке создаёт лишний риск.

Полный проход по экранам описан в карте гостя после QR-скана. Для этой статьи важно правило: служебная сторона должна получить тот же стол, который видел гость.

Шаг 2. Меню и корзина формируют проверяемый состав

Каталог загружается для найденного заведения. Гость выбирает доступные позиции и модификаторы, а корзина показывает отдельные строки, количество и итог. При перезагрузке выбор сохраняется локально для этой точки.

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

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

Шаг 3. Оформление дополняет контекст

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

Приложение блокирует отправку при пустой корзине или отсутствии стола. Затем формирует запрос с placeId, tableId, позициями, количеством и выбранными добавками. Доставка использует другой набор данных и не относится к сценарию этой статьи.

На этом этапе полезно проверить не только успешную кнопку. Вернитесь в корзину, измените состав и снова откройте форму. Стол и позиции должны остаться согласованными.

Шаг 4. Сервер решает, можно ли создать заказ

Запрос из мини-приложения может содержать проверенные данные Telegram или MAX. В обычном браузере этих данных нет. Тогда сервер отдельно проверяет демо-режим либо настройку webOrdersEnabled у заведения. Если оба условия не выполнены, он отвечает, что требуется авторизация.

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

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

Шаг 5. Смена принимает операционную задачу

В рабочем интерфейсе карточка заказа показывает номер, время, стол, сумму, имя при наличии, состав, комментарий и состояние оплаты. Доступные действия зависят от текущего статуса. Сотрудник открывает детали и переводит заказ по процессу заведения.

Это не фоновая магия. Если никто не следит за рабочим контуром, заказ останется новым, а экран гостя не продвинется. До запуска назначьте роль, которая отвечает за приём на каждой смене, и резерв на случай недоступного устройства.

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

Шаг 6. Гость наблюдает статус

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

Для сценария в браузере сервер возвращает публичную ссылку /o/<token>. Её можно сохранить и открыть без загрузки меню. Публичный ответ скрывает личные поля и предназначен для просмотра, а не для изменения заказа.

Если сотрудник сообщил готовность устно, но не обновил статус, цифровой путь расходится с реальностью. Это операционная ошибка, а не дефект QR-кода. На пилоте сверяйте физическое действие и статус по одному контрольному заказу.

Что происходит при сбое

Процесс должен сохранять обслуживание, даже если цифровая дорожка остановилась. Для основных отказов заранее назначьте действие.

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

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

Приёмочный сценарий пары «гость / смена»

Проводите проверку в согласованной тестовой точке, не создавая шум на рабочей кухне.

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

Готовность подтверждает совпадение двух дорожек, а не отдельный красивый экран.

Критерии приёмки по слоям

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

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

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

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

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

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

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

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

Сведите две дорожки на одном контрольном заказе

Нарисуйте две колонки «гость» и «смена» для своей точки. Впишите устройства, ответственных и резерв на каждом переходе. Затем проведите один контрольный заказ вне пика и один согласованный проход в рабочее время. Исправляйте первую точку расхождения, не расширяя пилот.

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