Как запустить Онлайн-заказы на нескольких столах

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

Размер 3–5 столов можно использовать как стартовую гипотезу, но это не универсальная норма. Маленькой кофейне хватит другого числа, а ресторану с секциями важнее единая наблюдаемая зона, чем круглая цифра.

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

• Выберите соседние столы с одной проблемой и оставьте сопоставимый участок без нового сценария.
• Создайте паспорт каждого пилотного стола: место, обозначение, QR-ключ, носитель, проверка и владелец.
• Проведите парный тест «носитель → стол → заказ → рабочая очередь» до живых гостей.
• Сохраните обычный способ заказа и правила немедленного отката.
• Расширяйте контур только после повторяемых полных заказов без критических разрывов.

Сначала очертите малую зону на плане

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

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

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

Создайте паспорт каждого стола

Паспорт связывает физический стол с цифровым контекстом и владельцем носителя. Минимальная форма:

Поле	Что записать
Внутренний ID и обозначение	значения из учёта заведения, не только надпись на столе
Физическое место	зона и ориентир на плане
QR-ключ (qrKey)	выданный проектом непрозрачный ключ маршрутизации
Носитель	тип держателя и точное место установки
Контрольная ссылка	публичный рабочий URL из реестра носителей, без лишних копий в отчёте
Дата проверки	когда пройден последний контрольный заказ
Ответственный	роль, которая проверяет носитель после перестановки
Резерв	как гость заказывает без телефона

В проекте каждый стол получает отдельный QR-ключ. Это не секрет, а публичный непрозрачный ключ маршрутизации в ссылке на стол: его задача — выбрать нужный контекст, а не авторизовать сотрудника. Клиентская часть сопоставляет ключ с конкретными placeId, tableId и номером стола, а созданный заказ сохраняет tableId внутри заведения. Поэтому один общий код на несколько столов не заменяет проверку каждого места.

Не печатайте условный QR и не копируйте картинку с другого стола. Выпуск ключей относится к рабочему подключению.

Проверьте носитель на физическом месте

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

1. физический стол и его обозначение;
2. ссылка после сканирования;
3. контекст заведения и стола в гостевом пути;
4. созданный контрольный заказ у ответственной роли.

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

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

Подготовьте одну фразу для гостя и один резерв

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

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

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

Назначьте маршрут внутри смены

Малый контур не работает, если заказ виден системе, но не принадлежит роли. До открытия ответьте на четыре вопроса:

• кто первым замечает новый заказ;
• какое действие означает, что заказ принят в работу;
• кому и как передаётся состав;
• кто помогает гостю, если экран отслеживания расходится с фактом.

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

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

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

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

Последовательность допуска:

1. сверить количество носителей и их места с паспортами;
2. открыть по одному проверочному входу с каждого стола без создания лишних гостевых заказов;
3. подтвердить правильные заведение, стол и доступное меню;
4. проверить рабочее устройство и присутствие ответственной роли;
5. проговорить резервный сценарий и стоп-условия;
6. записать время допуска и найденные отклонения.

Если в зоне пять столов, проверяются все пять, а не один «такой же» носитель. Уникальный ключ делает каждый стол отдельным объектом. Не допускайте зону по фотографии табличек из прошлого дня.

После изменения QR-ключа, перестановки носителя или редактирования границы старый допуск аннулируется. Ответственный повторяет проверку затронутых объектов и обновляет паспорт.

Ведите журнал изменений контура

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

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

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

Журнал тестового и гостевого заказа

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

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

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

Измерения первой недели подготовьте отдельно по паспорту семи метрик. Журнал здесь служит трассировкой малого контура, а не аналитическим экраном.

Правила работы во время пилота

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

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

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

Когда немедленно откатывать стол

Отключите конкретный стол от живого пилота и верните обычное обслуживание, если:

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

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

Критерии расширения, повторения и остановки

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

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

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

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

Остановить: повторяется потеря контекста, заказа или ответственности, а безопасный резерв не удерживает сервис.

Для процесса со сроками воспользуйтесь отдельным семидневным планом запуска. Не превращайте критерии этой статьи в ещё одно расписание.

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

Малый контур ценен своей обратимостью

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