Что видит гость после скана QR-кода

После скана гость должен увидеть не «технологию QR», а понятное продолжение визита: меню своей точки, контекст стола, блюда, корзину, оформление и затем статус заказа. Любая неоднозначность между этими этапами возвращает человека к устному вопросу сотруднику.

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

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

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

До скана: какое ожидание создаёт табличка

Экранный путь фактически начинается на столе. Текст носителя сообщает, что произойдёт после наведения камеры: только просмотр меню или возможность сделать заказ. Формулировка «QR-код» называет предмет, но не объясняет действие. Формулировка «Откройте меню и закажите со стола» задаёт проверяемое ожидание.

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

Карта сервиса для гостевого пути

Карта сервиса — это таблица, где рядом стоят действие гостя и наблюдаемый ответ системы. Она помогает отделить проблему интерфейса от неверной ссылки или неподготовленной смены.

Этап	Что делает гость	Что должна сделать система	Что проверяет сотрудник
Вход	сканирует код и открывает адрес	разрешает ключ в точку и стол	табличка относится к этому столу
Каталог	смотрит разделы и карточки	загружает меню найденной точки	цены и доступность актуальны
Выбор	добавляет блюда	сохраняет позиции в корзине точки	недоступное нельзя заказать
Проверка	меняет количество, читает итог	пересчитывает состав и сумму	модификаторы понятны
Оформление	подтверждает стол и отправляет	проверяет заказ	канал заказов разрешён
Ожидание	следит за выполнением	показывает текущий статус	смена меняет статус по процессу

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

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

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

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

После исправления повторите тот же маршрут тем же способом, иначе сравнение потеряет смысл.

Два входа после скана и одна общая точка

После скана возможны две точные ветки. Прямая браузерная ссылка /t/<qrKey> сразу открывает гостевое приложение, которое передаёт ключ серверу и получает точку со столом. Адрес /go/<qrKey> сначала проверяет ключ на сервере, а затем перенаправляет в мини-приложение Telegram; вариант /go/<qrKey>?provider=max ведёт в MAX. Платформа передаёт тот же ключ как стартовый параметр.

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

Шаг 1. Приложение определяет стол

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

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

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

Шаг 2. Гость попадает в каталог

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

На этом экране человек решает две задачи: узнаёт блюдо и понимает, можно ли его заказать сейчас. Поэтому название, цена, фотография и доступность важнее рекламного вступления. Позиция с isAvailable: false не должна добавляться в корзину.

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

Шаг 3. Корзина собирает решение, а не просто список

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

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

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

Шаг 4. Форма уточняет недостающие данные

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

Форма также принимает необязательное имя и комментарий. Пустая корзина или отсутствующий стол в режиме обслуживания за столом блокируют отправку. Нажатие «Оформить заказ» создаёт серверный запрос, а не просто показывает локальное подтверждение.

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

Шаг 5. Сервер принимает или отклоняет заказ

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

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

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

Шаг 6. Экран статуса заменяет вопрос «что дальше»

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

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

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

Где путь требует человека

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

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

Протокол наблюдения на одной смене

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

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

Записывайте формулировки без интерпретации. «Гость не понял интерфейс» бесполезно. «Спросил, нужно ли теперь звать официанта» уже подсказывает, какое ожидание не закрыто.

Наблюдение полного пути без подсказок

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

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