Заказ по обычной ссылке: если гость не хочет открывать Telegram или MAX

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

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

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

• Для заказа за конкретным столом используйте адрес вида /t/<qrKey>, а не общую ссылку заведения.
• После открытия исправной ссылки гость сразу попадает в нужную точку и получает сохранённый контекст стола.
• Без разрешения веб-заказов посетитель сможет посмотреть меню, но сервер не примет неавторизованный заказ обычного заведения.
• После оформления доступен отдельный публичный адрес /o/<token>: по нему можно вернуться к текущему статусу.
• Браузерный маршрут нужно проверять на реальной ссылке подключённой точки; общее демо /app/ не проверяет конкретный ключ QR-кода.

Браузер и мессенджер решают разные задачи входа

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

Вопрос	Прямая ссылка на стол	Вход через Telegram или MAX
Нужно ли открывать мессенджер	нет	да
Откуда берётся стол	из qrKey в адресе	из стартового параметра
Можно ли открыть меню без регистрации	да	да, внутри мини-приложения
Что нужно для отправки заказа	у точки включены веб-заказы или она работает как демо	проверенные данные мессенджера
Как вернуться к статусу	сохранить /o/<token>	экран мини-приложения и доступные уведомления
Что произойдёт при неверном ключе	приложение покажет ошибку определения стола	стартовый параметр тоже не сможет разрешить стол

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

Карта маршрута: пять экранов и пять точек отказа

Карта ниже помогает проверить не абстрактную «веб-версию», а наблюдаемый путь. Проходите её на телефоне с выключенными Telegram и MAX, чтобы случайно не попасть в привычное мини-приложение.

1. Открытие адреса

Гость сканирует носитель или нажимает ссылку вида /t/<qrKey>. Приложение передаёт ключ серверу. При успехе оно получает заведение, идентификатор и номер стола, а затем сохраняет этот контекст.

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

2. Меню нужного заведения

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

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

3. Корзина

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

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

4. Оформление со столом

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

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

5. Статус по публичному токену

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

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

Общий демо-интерфейс гостя полезен перед этой проверкой только как знакомство с меню, корзиной, оформлением и экраном статуса. Он не подтверждает ваш /t/<qrKey>, привязку стола или разрешение веб-заказов.

Где обычная ссылка действительно заменяет мессенджер

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

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

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

Где браузер не становится полной заменой

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

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

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

Как предложить резервный вход без новой путаницы

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

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

• «Если не хотите открывать мессенджер, вот ссылка на этот же стол»;
• «После отправки сохраните ссылку на статус»;
• «Если страница не определила стол, я приму заказ обычным способом и передам ошибку управляющему».

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

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

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

Так резерв остаётся незаметным в обычной смене, но доступным именно в момент отказа от мессенджера.

Проверка перед размещением ссылки

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

1. Откройте именно /t/<qrKey> подключённого тестового стола.
2. Сверьте название заведения и номер стола до добавления блюда.
3. Добавьте доступную позицию, измените количество и обновите страницу.
4. Дойдите до оформления и убедитесь, что стол не пришлось выбирать заново.
5. Отправьте заказ только в согласованном тестовом контуре.
6. Сохраните /o/<token>, закройте вкладку и откройте адрес снова.
7. Попросите сотрудника назвать, где он увидит заказ и кто отвечает за смену статуса.

Критерий готовности здесь не «ссылка открылась». Готов маршрут, в котором совпали заведение и стол, заказ принят разрешённым способом, а гость может вернуться к статусу.

Проверьте браузерный резерв на одном столе

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

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

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