ИИ для ресторана: бронирование столиков, ответы гостям и передача администратору

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

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

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

Надёжный сценарий разделяет разговор и действие. Сначала ассистент понимает намерение и собирает обязательные параметры. Затем отдельным запросом получает доступные варианты. После выбора гостя отправляет команду создания брони и ждёт успешного подтверждения. Только после этого сообщает номер или детали бронирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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