Ссылка на стол и ссылка на заведение: в чём разница для гостя

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

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

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

• /t/<qrKey> подходит настольной табличке: сервер разрешает ключ в заведение и стол.
• /s/<slug> подходит сайту, витрине и профилю: он открывает меню точки без номера стола.
• В режиме обслуживания за столом общий вход добавляет ручной выбор стола при оформлении.
• Неверный ключ стола даёт ошибку определения; неверный slug возвращает к выбору заведения.
• Тип ссылки выбирают по месту носителя, а не по длине или удобству копирования.

Сравнение по тому, что знает система

Критерий	Ссылка на стол	Ссылка на заведение
Формат	/t/<qrKey>	/s/<slug>
Передаёт точку	да	да
Передаёт стол	да, после разрешения ключа	нет
Первый экран	меню найденной точки	меню найденной точки
Оформление заказа	стол уже определён	гость выбирает стол
Ошибка адреса	сообщение о нераспознанном столе	возврат к выбору точки
Типичный носитель	табличка на столе	сайт, профиль, витрина
Главный риск	ключ закреплён не за тем столом	ссылку ошибочно выдают за столовую

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

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

Когда выбирать ссылку на стол

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

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

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

Когда выбирать ссылку на заведение

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

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

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

Матрица «носитель × контекст × действие»

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

Где увидит гость	Известна ли точка	Известен ли стол	Адрес	Допустимое обещание
стол в зале	да	да	/t/<qrKey>	«Откройте меню этого стола»
вход в кафе	да	нет	/s/<slug>	«Посмотрите меню заведения»
сайт одной точки	да	нет	/s/<slug>	«Откройте меню»
страница сети	не всегда	нет	список точек или выбранный slug	«Выберите заведение»
электронный чек точки	да	нет	/s/<slug>	«Вернитесь к меню»
заказ со статусом	заказ уже создан	стол уже записан	/o/<token>	«Посмотрите статус заказа»

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

Три ошибки при смешении адресов

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

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

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

Как провести приёмку двух ссылок

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

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

Критерий готовности — не одинаковый внешний вид меню. Система должна знать ровно тот контекст, который реально известен в месте перехода.

Кто обслуживает каждый тип адреса

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

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

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

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

Так ошибка обнаруживается при изменении носителя, а не после первого неправильно направленного заказа.

Контекст важнее длины.

Разложите ссылки по известному контексту

Разложите все действующие ссылки по двум колонкам: «стол известен» и «стол неизвестен». Сверьте настольные носители с ключами, а сайт и витрину — с slug. Любой адрес, оказавшийся не в своей колонке, замените сначала на одном тестовом месте и пройдите оформление.

Завершите проверку двумя разными контрольными результатами:

• столовой адрес сам подставил правильный номер;
• общий адрес открыл нужную точку и честно потребовал выбор стола.

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