Ресторан теряет гостя тише, чем магазин теряет заказ. Никто не пишет гневный отзыв о том, что ему не ответили — человек просто открывает карту, видит ещё три заведения в радиусе пятисот метров и бронирует там. Отель теряет так же: запрос про раннее заселение ушёл в личные сообщения в 22:40, ответ пришёл в 10:15 следующего дня, гость уже забронировал соседний.
Это не разбор конкретного клиента и не отчёт о результатах. Это модельный разбор: как задача устроена в отрасли, что в ней реально автоматизируется, где автоматизация строго запрещена, и как посчитать эффект на своих вводных до того, как тратить бюджет. Все цифры ниже — расчётные, на типовых отраслевых допущениях, которые мы раскрываем явно.
Почему в HoReCa обращения теряются чаще, чем в других нишах
В большинстве бизнесов человек, который отвечает клиенту, сидит и отвечает клиенту. В ресторане и небольшом отеле это не так. Администратор одновременно ведёт зал, рассаживает гостей, принимает наличные, разбирается с курьером и держит в руках телефон. Телефон проигрывает всему остальному — потому что живой гость перед стойкой всегда важнее звонящего.
Отсюда специфика, которой нет в e-commerce.
Пик обращений совпадает с пиком загрузки. В интернет-магазине вопросы приходят более-менее ровно. В ресторане они приходят с 18:30 до 21:00 — ровно тогда, когда администратор физически не может взять трубку. То есть система ломается именно в тот момент, когда приносит деньги.
Решение принимается за минуты. Компания выбирает подрядчика неделями. Гость выбирает, где поужинать, за десять минут, часто уже стоя на улице. Ответ через полчаса приходит в пустоту: решение принято, стол занят у соседей.
Вечер и ночь — это не «нерабочее время», а рабочее. Обычно в отрасли заметная доля обращений приходится на промежуток после закрытия смены администратора: люди планируют завтрашний ужин перед сном, гости отеля пишут про поздний заезд, кто-то ищет площадку для дня рождения в субботу вечером в среду ночью.
Каналов много, и они разные. Телефон, мессенджеры, форма на сайте, комментарии и директ в соцсетях, карточка в картах, агрегаторы бронирования. Администратор физически не может держать в фокусе шесть окон.
доля обращений, отвечаемых по данным, которые у вас уже есть
режим работы ассистента без ночной смены и доплат
время первого ответа вместо минут ожидания в очереди звонка
Из чего состоит поток обращений
Прежде чем что-то автоматизировать, надо разложить поток. Ниже — типовая для отрасли структура: так выглядит распределение в заведении с потоком в несколько сотен обращений в месяц, работающем на бронировании столов и принимающем банкеты. У вас пропорции сдвинутся, и это нормально — цифры нужны как рамка для собственного замера, а не как готовый ответ.
| Тип обращения | Доля потока | Что нужно для ответа | Автоматизируется |
|---|---|---|---|
| Бронирование столика на стандартных условиях | 25–35% | Карта столов, свободные слоты, регламент брони | Полностью |
| Часы работы, адрес, как добраться, парковка | 15–20% | Карточка заведения, регламент | Полностью |
| Вопросы по меню: наличие позиций, цены, стоп-лист | 10–15% | Актуальное меню, стоп-лист из системы | Полностью |
| Статус и изменение существующей брони | 8–12% | Система бронирования по номеру и телефону | Полностью |
| Условия для гостей с детьми, животными, доступная среда | 5–8% | Регламент заведения | Полностью |
| Состав блюд и аллергены | 5–10% | Подтверждённые техкарты | Только по подтверждённым данным, иначе — человеку |
| Банкеты, большие группы, мероприятия | 5–10% | Расчёт, менеджер, договор | Частично: сбор вводных |
| Жалобы на качество, конфликты, возвраты | 3–6% | Решение человека | Нет |
| Нестандартное: съёмки, аренда площадки, партнёрства | 2–4% | Решение человека | Нет |
Первые пять строк — это уже больше половины потока, и все они отвечаются по фактам, которые у вас уже есть: в системе бронирования, в меню, в регламенте заведения. Здесь не нужен «интеллект, который догадается» — нужна система, которая находит факт и аккуратно его излагает.
Дальше начинается зона, где ошибка стоит дороже, чем недовольство.
Границы: что ассистент не делает никогда
Честный список запретов продаёт лучше, чем обещание «закроем 95% обращений». Помимо аллергенов есть ещё три зоны, куда ассистент не заходит.
Не подтверждает бронь сверх регламента. Стандартный стол на два-четыре человека в обычный вечер — да, по свободным слотам. Банкет, группа больше согласованного порога, отдельный зал, особые условия по времени или депозиту, бронь на праздничные даты — только человек. Ассистент здесь работает как приёмщик заявки: собирает дату, время, количество гостей, формат, бюджетную рамку, контакт — и передаёт менеджеру с готовой карточкой.
Не обещает скидок и не торгуется. Никаких «можем сделать десять процентов», «для вас найдём вариант подешевле», «уточню у управляющего, думаю, договоримся». Действующие акции ассистент называет ровно так, как они опубликованы, и всё. Любой запрос на индивидуальные условия — сразу человеку.
Не разбирает жалобы на качество. Если гость пишет, что стейк был сырой, обслуживание хамское, а счёт неверный — это не задача для автоматизации. Ассистент фиксирует обращение, извиняется нейтрально, без признания вины и без обещаний компенсации, и немедленно передаёт управляющему с полной историей диалога. Обещанная ботом компенсация, которую потом не подтвердил менеджер, — это второй конфликт поверх первого.
| Задача | Ассистент | Почему так |
|---|---|---|
| Свободные слоты и бронь стандартного стола | Да | Данные детерминированы, берутся из системы бронирования |
| Часы работы, адрес, парковка, детская комната | Да | Регламент заведения, однозначный ответ |
| Наличие позиции в меню и цена | Да | Меню и стоп-лист из учётной системы |
| Проверка и перенос существующей брони | Да, с подтверждением | Действие в системе — только после явного подтверждения гостя |
| Отмена брони | Да, с подтверждением | Освобождение слота выгодно заведению, но требует идентификации |
| Состав и аллергены | Только по подтверждённым техкартам | При любой неоднозначности — отказ и передача человеку |
| Банкет, большая группа, отдельный зал | Нет, только сбор заявки | Расчёт, депозит, договор — зона менеджера |
| Индивидуальные скидки и условия | Нет | Коммерческое решение за человеком |
| Жалоба на качество, конфликт | Нет | Нужна оценка ситуации и решение о компенсации |
| Спецпитание, детское меню по медицинским показаниям | Нет | Пересекается с зоной аллергенов, риск слишком высок |
Как это устроено внутри
Ассистент для HoReCa — это не дерево кнопок «Забронировать / Меню / Контакты», в котором гость не находит свой случай и всё равно звонит. Это связка из пяти частей.
Поиск по вашим данным. Регламент заведения, часы работы по дням, условия парковки, правила по детям и животным, описание залов, действующие акции, FAQ — всё это индексируется. На вопрос система сначала находит релевантный фрагмент, и только потом формулирует ответ по нему. Не нашла — говорит, что не знает.
Интеграция с системой бронирования. Свободные слоты нельзя «найти в документе» — их надо запросить в реальном времени. Ассистент ходит в вашу систему по API: смотрит карту столов, проверяет доступность на дату и время, создаёт бронь, находит существующую по телефону, переносит и отменяет.
Меню и стоп-лист. Отдельный контур, потому что данные меняются ежедневно. Если позиция ушла в стоп в семь вечера, ассистент не должен рассказывать про неё в семь тридцать. Стоп-лист подтягивается из учётной системы, а не из статичного PDF.
Контур подтверждённых техкарт. Обособленный источник для вопросов про состав, с отдельным флагом «подтверждено» на каждой позиции и датой верификации. Позиция без флага или с устаревшей датой не отвечается вообще.
Эскалация на человека. Ассистент знает свои границы и передаёт диалог с полным контекстом: банкет, жалоба, конфликтный тон, сомнение по составу, любая нестандартная просьба. Гость не пересказывает всё заново — это условие того, что эскалация не воспринимается как отфутболивание.
Гость → Ассистент
├─ База знаний ────────→ часы, адрес, парковка, дети, залы, акции
├─ Система бронирования → слоты, карта столов, статус брони
├─ Меню и стоп-лист ───→ наличие позиций, цены
├─ Техкарты (подтв.) ──→ состав, только при точном совпадении
└─ Не уверен / банкет / жалоба / аллерген под вопросом
→ Менеджер (+ вся история диалога)Что происходит в пик и что происходит ночью
Это два разных режима, и путать их не стоит.
Пик — с восемнадцати до двадцати одного. Администратор в зале, телефон звонит вхолостую. Ассистент здесь берёт на себя два потока: «есть ли стол на сегодня на двоих через час» и «до скольки вы работаете». Первый закрывается обращением в систему бронирования, второй — из регламента. Оба ответа занимают секунды и не отвлекают администратора от зала. Важная деталь: при высокой загрузке ассистент не должен обещать стол «наверняка» — если система показывает последний свободный слот, корректная формулировка предупреждает, что бронь фиксируется по факту подтверждения, и подтверждение приходит отдельным сообщением.
Ночь — с двадцати двух до открытия. Здесь другая логика. Гость не ждёт немедленного результата, он ждёт, что его не проигнорируют. Ассистент отвечает на справочные вопросы полностью, а по всему, что требует человека, честно фиксирует заявку и называет время ответа: «Менеджер по банкетам свяжется с вами завтра после одиннадцати». Это работает лучше, чем автоответчик «мы получили ваше сообщение», потому что гость уходит с ответом на свой основной вопрос — вместимость, диапазон цен, возможность площадки — и с ожиданием звонка, а не в поиск следующего заведения.
Отдельный сценарий для отелей: поздний заезд. Гость пишет в час ночи из аэропорта, что рейс задержали. Ассистент подтверждает регламент позднего заселения, объясняет, как попасть в отель ночью, и уведомляет ночного портье. Это не экономия денег, это отсутствие паники у человека с чемоданом.
Контур банкетов: где ассистент экономит больше всего
Парадокс: самая денежная категория — банкеты и мероприятия — автоматизируется хуже всего, и именно поэтому даёт максимальный эффект от частичной автоматизации.
Как это выглядит без ассистента. Гость пишет «хотим отметить юбилей». Менеджер отвечает через несколько часов. Начинается переписка на семь итераций: сколько человек, какая дата, нужен ли отдельный зал, нужна ли звуковая аппаратура, какой бюджет на гостя, будет ли алкоголь свой. Половина заявок отваливается на середине этой переписки — просто потому что человек за это время нашёл площадку, где ему сразу назвали вилку цен.
Как это выглядит с ассистентом. Он не считает смету и не подтверждает площадку — это по-прежнему работа менеджера. Он делает другое: за одну сессию собирает все вводные, называет опубликованные рамки (вместимость залов, минимальный депозит, диапазон банкетного меню на гостя, есть ли пробковый сбор) и передаёт менеджеру готовую карточку заявки. Менеджер получает не «хотим отметить юбилей», а структурированный запрос: дата, 24 гостя, суббота вечер, нужен отдельный зал, бюджет до определённой суммы на гостя, контакт, комментарии.
Дальше менеджер делает один звонок вместо семи сообщений, и делает его подготовленным. Заявка не остывает, потому что гость уже получил ответ на главный вопрос — «влезаем ли мы к вам по деньгам и по вместимости» — в момент обращения, а не через сутки.
Ключевое ограничение остаётся жёстким: ассистент ни при каких условиях не подтверждает бронь банкета, не фиксирует дату как занятую и не называет итоговую сумму. Он называет диапазоны из опубликованного прайса и передаёт человеку.
Как посчитать экономику до внедрения
Дальше — модельный расчёт. Его смысл не в красивой цифре, а в том, чтобы вы подставили свои вводные и увидели, есть ли вообще смысл. Возьмём условное заведение: 600 обращений в месяц по всем каналам, среднее время обработки обращения администратором — 4 минуты (с учётом того, что он отвлекается от зала и возвращается к нему), фонд оплаты администратора с налогами — 80 000 ₽ при 168 часах в месяц.
Шаг 1. Сколько времени съедает поток. 600 × 4 мин = 2 400 минут = 40 часов в месяц. Это четверть ставки администратора, размазанная тонким слоем по самым напряжённым часам смены.
Шаг 2. Какая часть потока автоматизируема. По таблице выше первые пять категорий дают 55–70%. Берём осторожную нижнюю границу — 55%, это 22 часа.
Шаг 3. Что реально высвобождается. Не всё: часть диалогов ассистент доведёт не до конца, часть эскалирует, по части гость всё равно захочет живого человека. Закладываем 70% от автоматизируемого объёма — около 15 часов в месяц.
Шаг 4. Во что это превращается в деньгах. 15 часов при ставке около 476 ₽/час (80 000 ₽ / 168 ч) — примерно 7 100 ₽ в месяц прямой экономии времени. Само по себе это немного, и было бы нечестно останавливаться здесь: на такой экономии проект не окупается.
Шаг 5. Где на самом деле деньги. В непринятых бронях. Допустим, вечерних и ночных обращений — 20% потока, то есть 120 в месяц. Из них броневых, скажем, половина — 60. Если сейчас теряется треть из них просто из-за молчания до утра, это 20 несостоявшихся визитов. При среднем чеке на стол 4 000 ₽ — 80 000 ₽ упущенной выручки в месяц. Даже если ассистент вернёт половину, это 40 000 ₽ — на порядок больше, чем экономия на времени администратора.
Именно поэтому в HoReCa считать окупаемость только через «сэкономленные часы» неправильно. Основной эффект — не в снижении затрат, а в переставших теряться обращениях. Но и оценить его честно можно только на ваших данных: сколько обращений реально приходит вне смены и какая доля из них про бронь.
Этапы внедрения
- 3–5 дней
Аудит потока и данных
Смотрим реальные обращения за месяц по всем каналам: мессенджеры, форма на сайте, директ, записи звонков если есть. Размечаем структуру. Отдельно проверяем состояние трёх источников: регламент заведения, актуальность меню и стоп-листа, наличие подтверждённых техкарт. Проверяем, есть ли API у системы бронирования. На выходе — честная оценка автоматизируемой доли именно у вас.
- 1–2 недели
MVP на справочных вопросах и брони
Собираем ассистента на самой массовой категории: часы работы, адрес, парковка, дети, свободные слоты и стандартная бронь. Подключаем базу знаний и интеграцию с системой бронирования. Запускаем в одном канале или на части трафика.
- 1 неделя
Меню, техкарты и контур банкетов
Подключаем актуальное меню со стоп-листом. Отдельно и аккуратно — контур состава и аллергенов: только подтверждённые позиции, жёсткие правила отказа, ручная проверка формулировок. Настраиваем сбор банкетных заявок с передачей менеджеру.
- 3–5 дней
Каналы и эскалация
Разводим по каналам: виджет на сайте, Telegram, WhatsApp, мессенджеры соцсетей. Настраиваем маршрутизацию эскалаций: администратор, менеджер по банкетам, управляющий по жалобам. Проверяем, что контекст диалога передаётся целиком.
- 2–3 недели
Калибровка на реальном трафике
Читаем логи ответов вручную, ищем формулировки, где система отвечает уверенно и неточно, добиваем слепые зоны базы. Отдельно и построчно проверяем каждый ответ, касавшийся состава блюд. Передаём код, документацию и инструкции команде.
От старта до работающей системы — примерно полтора месяца. Дольше, чем в e-commerce, и причина одна: контур техкарт нельзя собрать быстро. Их надо выверить, подтвердить и научить систему молчать в сомнительных случаях, а это ручная работа, которую нельзя ускорить.
Метрики: на что смотреть после запуска
Одна цифра ничего не показывает. Смотреть надо на связку, где показатели проверяют друг друга.
| Метрика | Что показывает | Тревожный сигнал |
|---|---|---|
| Доля обращений, закрытых без человека | Реальную разгрузку администратора | Растёт вместе с повторными обращениями |
| Повторные обращения по той же теме | Качество ответа | Гость переспрашивает — ответ был бесполезен |
| Доля обращений вне смены, получивших ответ | Закрытие главной дыры | Ниже 90% — часть каналов не подключена |
| Конверсия обращения в бронь | Коммерческий эффект | Падает при росте автоматизации — ассистент отвечает сухо |
| Доля отказов по составу и аллергенам | Работу защитного контура | Ноль — контур настроен слишком мягко |
| Доля эскалаций на человека | Понимание границ | Ниже 10% — ассистент берётся не за своё |
| Доля банкетных заявок с полными вводными | Качество приёма заявок | Менеджер всё равно переспрашивает базовое |
| Доля ответов «не знаю» | Слепые зоны базы знаний | Растёт — регламент устарел |
| Оценка ответа гостем | Восприятие | Резкое падение после обновления меню |
Две метрики в этой таблице контринтуитивны, и на них стоит остановиться.
Доля отказов по аллергенам не должна быть нулевой. Если за месяц ассистент ни разу не отказался отвечать про состав, это не значит, что база идеальна. Это почти наверняка значит, что порог срабатывания настроен слишком мягко и система отвечает там, где должна была передать человеку. Здоровое поведение — отказ в заметной доле таких вопросов, особенно по сезонным и банкетным позициям.
Слишком низкая эскалация — плохой знак. Интуиция говорит, что чем меньше передач человеку, тем эффективнее система. На деле ниже десяти процентов почти всегда означает, что ассистент залезает в зону, которая ему не принадлежит: обещает условия, подтверждает то, что подтверждать не должен, отвечает на жалобу вместо управляющего. Здоровый коридор для HoReCa — 15–25%, и он выше, чем в e-commerce, именно из-за банкетов и аллергенов.
Риски и как они снимаются
«Ассистент выдумает состав блюда». Главный риск отрасли, и снимается он не уговорами модели, а архитектурой: отдельный источник подтверждённых техкарт, обязательное точное совпадение позиции, жёсткое правило отказа при любом сомнении, полное логирование каждого такого ответа для ручной проверки. Плюс явное правило: позиции без подтверждённой карты не отвечаются вообще, независимо от того, насколько вопрос кажется безобидным.
«Он подтвердит бронь, которую мы не можем принять». Решается тем, что подтверждение брони — это операция в вашей системе с проверкой доступности в реальном времени, а не текст в сообщении. Всё, что выходит за регламент — количество гостей, отдельный зал, праздничные даты, депозит, — уходит человеку по правилам, а не по усмотрению модели.
«Меню меняется каждый день, ассистент отстанет». Поэтому меню и стоп-лист берутся из учётной системы, а не из загруженного файла. Если интеграции нет — это первое, что вскрывает аудит, и часто именно здесь проект начинается с наведения порядка в данных, а не с ИИ.
«Гости не любят ботов». Не любят не ботов, а тупики, из которых нельзя дозваться человека. Переход на администратора должен быть доступен в один шаг и в любой момент. В HoReCa это особенно чувствительно: гостеприимство — часть продукта, и ассистент, который отфутболивает, вредит бренду сильнее, чем неотвеченный звонок.
«Мы попадём в зависимость от подрядчика». Код, документация и права передаются вам. Обновлять базу знаний, регламенты и техкарты ваша команда сможет сама — и должна, потому что подтверждать актуальность состава может только тот, кто отвечает за кухню.
Частые вопросы
Заменит ли ассистент администратора? Нет. Он снимает поток одинаковых вопросов и закрывает вечерне-ночную дыру, а администратор возвращается к тому, за что ему платят, — к залу и гостям. В отрасли с хронической нехваткой линейного персонала это чаще выглядит как отказ от найма дополнительного человека на телефон, а не как сокращение.
Что если у нас нет техкарт в электронном виде? Тогда контур состава и аллергенов не включается — и это правильное решение, а не поражение. Ассистент в такой конфигурации на любой вопрос про состав отвечает передачей менеджеру. Всё остальное — бронь, часы, парковка, меню — работает. Контур аллергенов подключается позже, когда карты оцифрованы и подтверждены.
У нас маленькое заведение, есть ли смысл? Считать надо не по обороту, а по доле теряемых обращений. Если у вас 200 обращений в месяц, но треть приходит вечером и остаётся без ответа, эффект в процентах от выручки может быть выше, чем у сетевого ресторана с диспетчерской. Если же у вас нет брони как таковой и весь поток — «до скольки работаете», ассистент окупится справочной функцией и мгновенным ответом в картах, но масштаб эффекта будет скромнее. Аудит на первом этапе как раз отвечает на этот вопрос цифрой.
Как быть с телефонными звонками? Голосовой контур — отдельная задача и отдельный уровень сложности. Разумный порядок: сначала текстовые каналы, где ошибка дешевле и проверяемее, потом, если поток оправдывает, голос. Часто оказывается, что после запуска текстовых каналов часть звонящих просто переходит в мессенджер, потому что там отвечают мгновенно.
Что с несколькими заведениями сети? База знаний разделяется по точкам: часы, адрес, парковка, вместимость и меню у каждой свои, общий слой — регламенты сети и тональность. Ассистент сначала определяет, о какой точке речь, и только потом отвечает. Это добавляет работы на этапе сборки, но не меняет архитектуру.
Сколько это стоит в эксплуатации? Помимо разработки — вызовы модели и хранилище. При потоке в несколько сотен обращений в месяц это заметно дешевле любой части ставки. Точную цифру считаем на аудите, когда понятны объём и средняя длина диалога.
Сколько такая система живёт без переделки? Ядро — годами, архитектура «поиск по своим данным плюс генерация» устойчива. Меняются содержимое базы, меню и техкарты — это ваша ежедневная работа, — и по мере выхода новых моделей слой генерации. Именно поэтому мы передаём код и документацию.
Что понадобится от вас
Чтобы аудит был расчётом, а не гаданием:
- выгрузка обращений за последний месяц по всем каналам, можно обезличенную;
- действующий регламент заведения: часы, парковка, правила по детям и животным, вместимость и описание залов, условия банкетов и депозитов;
- актуальное меню и понимание, откуда берётся стоп-лист;
- техкарты по позициям — с честной отметкой, какие из них подтверждены и кем;
- доступ к API системы бронирования или описание, что в ней есть;
- один человек со стороны заведения, который знает, как правильно отвечать в спорных случаях, и один человек с кухни, который отвечает за состав.
Последний пункт не формальность. Контур аллергенов нельзя собрать без того, кто подписывается под актуальностью карт. Если такого человека нет, контур не включается — и мы говорим об этом на старте, а не после запуска.
Этого набора достаточно, чтобы через несколько дней у вас была не презентация, а цифра: какая доля вашего потока автоматизируется, сколько обращений сейчас теряется вне смены и что это значит в деньгах.