В ресторане гость пишет на сайт, в мессенджер или звонит — а бронь, доставка и учёт в iiko часто живут отдельно. Мы разработали ресторанного ИИ-ассистента для сайта, мессенджеров и телефонной линии. Он принимает бронирования, отвечает по меню, уточняет наличие блюд, оформляет заказы на доставку и передаёт данные в iiko или ресторанную CRM. Клиенту уходит статус заказа, собирается обратная связь, а нестандартные вопросы — администратору.
В чём была дыра
Зал, доставка и кассовый контур требовали одного и того же человека на входе. Администратор параллельно:
- брал бронь по телефону и в чатах;
- отвечал «что есть в меню» и «есть ли блюдо сейчас»;
- принимал доставку;
- руками переносил заказ в iiko или CRM;
- потом ещё отвечал «где мой заказ».
Пока линия занята, бронь теряется, доставка опаздывает с фиксацией, iiko отстаёт от реальности. Нужен был ИИ-администратор, который связывает каналы гостя с бронированием, доставкой и iiko — а не виджет «оставьте заявку».
Три канала — один ассистент
Гость может прийти:
- с сайта;
- из мессенджеров;
- с телефонной линии.
Логика одна. Не три разных сценария «как получится», а единый ресторанный ассистент: принял обращение → понял, бронь это или доставка / вопрос по меню → отработал → записал в iiko или ресторанную CRM.
Сценарий 1. Бронирование
Ассистент принимает бронирование: дата, время, гости, пожелания, которые нужны залу. Типовая бронь не ждёт, пока администратор освободится от другой линии. Данные уходят в рабочий контур ресторана, а не остаются в переписке «на скрине».
Сценарий 2. Меню, наличие и доставка
По меню ассистент отвечает гостю и уточняет наличие блюд — чтобы не обещать то, чего нет. Если нужен заказ на доставку, оформляет его в диалоге и передаёт данные в iiko или ресторанную CRM.
Связка критична именно здесь: заказ, который «договорили в чате», но не попал в iiko, — это срыв кухни и доставки. ИИ-администратор закрывает разрыв между разговором с гостем и учётной системой ресторана.
После заказа: статус, отзыв, эскалация
Система сообщает клиенту статус заказа — гостю не нужно долбить линию «ну как там». Отдельно собирается обратная связь: ресторан видит, чем закончился контакт, а не только факт продажи.
Нестандартные вопросы — администратору. Жалоба, особые условия, кейс вне сценария брони/доставки/меню не должен «закрываться» ассистентом любой ценой. Человек получает обращение, когда автоматике нужен администратор, а не когда снова надо перебить типовой заказ в iiko.
Что разработали
- Ресторанный ИИ-ассистент для сайта, мессенджеров и телефона.
- Приём бронирований в едином контуре каналов.
- Ответы по меню и проверка наличия блюд.
- Оформление заказов на доставку с передачей в iiko или ресторанную CRM.
- Уведомления о статусе заказа клиенту.
- Сбор обратной связи.
- Передача нестандартных вопросов администратору.
Объект автоматизации — связка «гость → бронь/доставка → iiko», а не отдельный бот, который только вежливо отвечает и всё равно оставляет зал без данных.
| Было | Стало |
| Сайт, мессенджеры и телефон разбирал администратор | Один ИИ-ассистент на три канала |
| Бронь и доставка жили отдельно от iiko | Данные уходят в iiko или ресторанную CRM |
| Наличие блюд и меню уточняли вручную | Ассистент отвечает по меню и наличию |
| Статус заказа клиент выспрашивал сам | Система сообщает статус и собирает отзыв |
| Любой вопрос занимал линию | Нестандарт уходит администратору, типовое — ассистенту |
| Было | Стало |
| Общая витрина и ручные фильтры | ИИ-подбор товаров в мобильном приложении |
| Рекомендации без явной связи с задачей | Учитываются история, бюджет, предпочтения и текущая задача |
| Выбор строил сам пользователь | Персональные рекомендации собирает приложение |
| Персонализация была слабой или общей | Выдача приходит в индивидуальную подборку, драйвя дополнительные продажи |
Что вышло в результате
Ресторан получил ИИ-администратора, который связал бронирования, доставку и iiko. Ассистент работает на сайте, в мессенджерах и на телефонной линии: принимает бронь, консультирует по меню, оформляет доставку, пишет данные в iiko или CRM, держит клиента в курсе статуса и собирает обратную связь.
Администратор перестаёт быть узким горлышком на каждом гудке и сообщении. Типовой поток идёт в систему сам, человек включается там, где нужен живой контроль.