Передача данных о госте официанту и хостес: 3 шага

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

Что понадобится?

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

Чек-лист перед запуском:

• Единый идентификатор. Номер телефона связывает бронь, заказ в приложении и визит в зале.
• Источник данных. Приложение ресторана, касса и бронирование должны писать в одну карточку. Слабое звено здесь агрегатор: по данным Data Insight (2025), заказы через него принимают 49% заведений, а контакты гостя он обычно не отдаёт. Гость так и остаётся «чужим».
• Доступ для зала. Хостес и официант видят карточку на планшете, в кассовой программе или в мини-приложении для персонала.
• Владелец процесса. Один человек, например маркетолог, отвечает за качество карточек.

Шаг 1. Какие данные собрать в карточку гостя?

Берите только то, что зал успеет использовать за 10 секунд: имя, число визитов, любимые блюда, аллергии и ограничения, предпочтения по месту, статус в программе лояльности. Демография и источники трафика нужны маркетингу, а не залу.

Минимальный набор полей:

Здесь выигрывает собственное приложение: заказы и профиль привязаны к одному гостю, посредника нет. Агрегатор, по оценке Data Insight (сентябрь 2025, с. 27), забирает около 35% с заказа, а данных взамен не даёт. Собственная доставка обходится ресторану примерно в 25–27% от суммы заказа (экспертная оценка), зато база гостей остаётся у вас.

Шаг 2. Как довести данные до хостес и официанта?

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

1. Хостес. При брони или входе по телефону или имени появляется краткая карточка: статус, число визитов, предпочтения по месту, повод.
2. Официант. Перед подходом к столу он видит топ-3 блюда, ограничения и подсказку по допродаже. Например: «Берёт грибной крем-суп, не ест орехи».
3. Кухня. Аллергии автоматически попадают в комментарий к заказу.
4. Предсменка. За 10 минут до открытия администратор зачитывает 3–5 важных гостей на день.

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

Шаг 3. Как вернуть информацию из зала в базу?

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

Что закрепить:

• Быстрые теги в кассе: «любит окно», «с детьми», «без глютена», «важный гость». Два касания вместо текстового поля.
• Ежедневная сверка: маркетолог проверяет новые теги и переносит их в профиль.
• Мотивация: небольшой бонус смене с наибольшим числом корректно заполненных карточек.
• Метрика: доля визитов, где гость идентифицирован. Начните с цели 50% и растите.

Теперь деньги. Допустим, 600 заказов в месяц со средним чеком 1200 ₽ идут через агрегатор с комиссией 30%: это 216 000 ₽ в месяц. Переведите повторных гостей в своё приложение по тарифу Foodonaut 4% от выручки (тариф подтверждён владельцем), и те же заказы обойдутся в 28 800 ₽. Разница в 187 200 ₽ в месяц покрывает и приложение, и обучение персонала. Расчёт условный: подставьте свои цифры.

Частые ошибки

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

• Слишком много полей. Карточку на 30 пунктов не читают. Оставьте 3–5.
• Данные в разных системах. Бронь в одной программе, заказы в другой, лояльность в третьей, а связи между ними нет.
• Нет обучения. Персонал не понимает, зачем всё это. Покажите на примере: узнанный гость оставляет больше.
• Чувствительные данные в открытом доступе. Залу показывайте только нужное, контакты и платёжные данные не выводите.
• Нет обратной связи. Зал заполняет теги, но их никто не читает, и через месяц привычка исчезает.
• Опора на агрегатор. Данных о госте там нет, и лояльность с персонализацией строить не на чем.

Итог

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

Ключевые выводы

• Достаточно 3–5 полей карточки: имя, визиты, топ-3 блюда, ограничения, повод.
• Показывайте данные там, где зал уже работает: бронь и касса, не больше двух касаний.
• Агрегатор берёт около 35% с заказа (оценка Data Insight, 2025) и не даёт полной базы гостей, а собственное приложение стоит 4% от выручки по тарифу Foodonaut.
• Для условных 600 заказов по 1200 ₽ разница между комиссией 30% и 4% составляет 187 200 ₽ в месяц.
• Начальная цель по метрике: 50% визитов с идентифицированным гостем.

Источники

• Комиссия 35% против 4%: во сколько обходится отказ от своего приложения навынос — Teletype
• Кто, как и почему заказывает доставку продуктов питания
• Собственное приложение для рестобара: как срезать комиссию на 31% — Teletype
• Рестораны отказываются от агрегаторов из-за высоких комиссий

Читайте также

• Как вести базу гостей сети ресторанов в одном приложении
• Как перевести гостей из агрегатора в своё приложение
• Как собрать номера телефонов гостей доставки: 6 способов