У большинства компаний Telegram-бот поддержки выглядит одинаково: главное меню из шести кнопок, под каждой — ещё три, в конце — заготовленный текст. Клиент с нестандартным вопросом проходит два уровня меню, не находит нужного и пишет «оператор». Статистика таких ботов обычно честная: до половины диалогов заканчиваются переводом на человека, и операторы отвечают на те же вопросы, что и до запуска бота. Бот есть, нагрузка не упала.
Переход к боту, который понимает свободный текст, — это другая архитектура, другая подготовка контента и другие правила контроля. Разберём, как сделать этот переход поэтапно и не сломать то, что уже работает.
Почему кнопочный сценарий упирается в потолок
Кнопочный бот хорош ровно до тех пор, пока вопросы клиентов укладываются в заранее нарисованное дерево. На практике дерево устаревает через пару месяцев: появляются новые услуги, меняются условия доставки, клиенты формулируют вопрос не так, как предполагал автор сценария.
Типичные симптомы, что потолок достигнут:
- Клиенты игнорируют кнопки и сразу пишут текстом — бот отвечает «не понимаю, выберите пункт меню».
- Один вопрос затрагивает две ветки сразу («хочу вернуть товар и поменять адрес доставки по другому заказу»), и сценарий не предусматривает такой комбинации.
- Дерево меню разрослось настолько, что его боится редактировать даже тот, кто его строил.
- Операторы жалуются, что бот «передаёт» диалог без контекста, и приходится переспрашивать клиента с нуля.
Если узнали хотя бы два пункта — дальше наращивать меню бессмысленно. Каждая новая кнопка добавляет сложности и почти не добавляет пользы.
Что именно меняется при переходе к пониманию запроса
Внутри кнопочного бота логика жёсткая: нажатие — ответ. Внутри бота с ИИ появляются три новых слоя.
Распознавание намерения. Языковая модель (GPT-5, Claude, Gemini или открытая Qwen на своём сервере) читает сообщение и определяет, что клиент хочет: узнать статус заказа, оформить возврат, пожаловаться, уточнить цену. Модель справляется с опечатками, разговорными формулировками и смешанными языками — тем, на чём кнопочный бот ломается.
База знаний. Вместо заготовленных текстов под каждой кнопкой — набор документов компании: условия доставки, регламент возвратов, описание тарифов, инструкции. Модель ищет в них релевантный фрагмент и формулирует ответ на его основе. Подход называется RAG, подробно он разобран в статье про RAG на практике.
Действия. Бот не только отвечает, но и делает: проверяет статус заказа в учётной системе, создаёт обращение в CRM, записывает на время. Для этого ему подключают инструменты — API интернет-магазина, amoCRM или Bitrix24, Google Sheets.
Важно понимать, что кнопки при этом никуда не исчезают. Для частых и однозначных действий («мои заказы», «связаться с менеджером») они остаются удобнее любого текста. Меняется принцип: кнопки — быстрый путь, свободный текст — основной.
Три этапа перехода вместо одного большого запуска
Переписывать бота целиком — рискованно и дорого. Разумнее двигаться ступенями, каждая из которых даёт измеримый результат.
Этап 1. Гибрид: кнопки плюс свободный ввод
Сохраняем текущее меню, но учим бота реагировать на текст. Если клиент пишет вместо нажатия кнопки, модель определяет намерение и либо отвечает сама по базе знаний, либо ведёт в нужную ветку меню. На этом этапе база знаний — это часто просто существующие ответы из кнопок, переформатированные в документы. Срок — одна-две недели, и это уже снимает заметную часть «не понимаю».
Этап 2. Ответы по документам компании
Подключаем реальную документацию: регламенты, прайс-листы, FAQ из внутренней вики. Настраиваем, чтобы бот цитировал источник или хотя бы опирался на него, а не фантазировал. Здесь же появляется первый серьёзный контур контроля качества — об этом ниже.
Этап 3. Действия в системах
Бот получает доступ к данным клиента: заказы, записи, баланс бонусов. Теперь на вопрос «где мой заказ» он отвечает не инструкцией «зайдите в личный кабинет», а конкретным статусом. Это требует интеграции с учётной системой и аккуратной работы с правами доступа — бот должен показывать клиенту только его данные.
Подготовка базы знаний: где обычно теряется качество
Самая частая причина плохих ответов — не модель, а документы. Модель отвечает ровно настолько хорошо, насколько внятно написан источник.
Что стоит сделать до подключения ИИ:
- Собрать реальные вопросы. Выгрузить историю диалогов за два-три месяца и сгруппировать обращения. Обычно 20–30 формулировок закрывают большую часть потока.
- Переписать ответы для чтения машиной. Один вопрос — один документ или раздел. Без «см. выше», без таблиц со сложным объединением ячеек, без устаревших оговорок.
- Убрать противоречия. Если в регламенте возврат 14 дней, а на сайте 30 — бот будет отвечать то одно, то другое. Разночтения нужно устранить до запуска, а не после жалоб.
- Назначить владельца. Кто-то в команде отвечает за актуальность документов. Иначе через полгода бот уверенно рассказывает про акцию, закончившуюся в прошлом квартале.
Где бот не должен отвечать самостоятельно
Понимание запроса не означает право отвечать на любой вопрос. Есть темы, в которых ошибка стоит дороже, чем ожидание ответа оператора.
- Индивидуальные цены и скидки. Бот может назвать цену из прайс-листа, но не должен «договариваться». Любая персональная скидка — только через менеджера.
- Сроки, которые зависят от внешних факторов. «Доставим до пятницы» бот может обещать только если это буквально написано в данных заказа. Иначе — «ориентировочный срок по тарифу — три-пять дней».
- Претензии и конфликты. Разозлённого клиента бот должен быстро передать человеку, а не пытаться «решить вопрос» шаблонным извинением.
- Юридические и медицинские формулировки. Всё, что может быть истолковано как консультация с ответственностью, — только с подтверждения специалиста.
Техническая сторона этих ограничений — отдельная большая тема, мы разбирали её в статье о галлюцинациях ИИ. Коротко: системный промпт с запретами, проверка фактов по данным, а не по памяти модели, и список стоп-тем, на которых бот обязан эскалировать.
Эскалация на человека: как сделать её незаметной для клиента
Хорошая эскалация — та, при которой клиент не чувствует «меня сбросили». Для этого нужны несколько простых правил.
Бот передаёт оператору не «клиент хочет связаться», а краткое резюме: что спрашивал, что бот уже ответил, какие данные проверил. Оператор продолжает диалог в том же чате, а не просит клиента повторить. После решения вопроса диалог возвращается боту, и он продолжает отвечать на следующие вопросы.
Критерии передачи задаются явно: клиент сам попросил человека, модель не уверена в ответе (это измеримо), вопрос попал в стоп-тему, клиент повторил один и тот же вопрос дважды. Последний признак часто недооценивают, а именно он ловит ситуации, когда бот «вроде ответил», но не по делу.
Что ещё важно: оператор должен видеть, где бот ошибся, и иметь кнопку «пометить ответ как неверный». Эти пометки — главный источник улучшений базы знаний. Шире про организацию поддержки с ИИ — в статье об AI-агенте поддержки клиентов.
Пример: сервис доставки воды переводит бота на ИИ
Представим небольшую компанию по доставке воды и кулеров. Бот с меню «Заказать / Перенести доставку / Оплатить / Задать вопрос» существовал два года. Около 40% диалогов заканчивались переводом на диспетчера, чаще всего из-за формулировок вроде «а можно завтра, но не утром, а после трёх, и ещё одну бутылку».
На первом этапе боту добавили понимание текста: модель разбирает сообщение на параметры (дата, время, количество) и подставляет их в уже существующий сценарий заказа. Кнопки остались. На втором — подключили документы: правила залога за тару, зоны доставки, график праздников. На третьем — доступ к базе заказов, чтобы бот сам называл дату ближайшей доставки и остаток по предоплате.
Ограничения оставили жёсткие: бот не обещает конкретный час доставки (это решает логист), не обсуждает компенсации за опоздание и переводит на диспетчера любое сообщение с жалобой. Диспетчер стал заниматься в основном маршрутами, а не ответами на «когда приедете». Ориентир реалистичный: доля диалогов с участием человека снижается в полтора-три раза, если база знаний и ограничения настроены аккуратно.
Что обычно идёт не так
Несколько ошибок, которые мы в AiKrok видим чаще всего при таких переходах.
Отключили кнопки полностью. Часть клиентов не любит писать текстом и хочет нажать «мои заказы». Удалив кнопки, вы ухудшаете опыт ради чистоты концепции.
Запустили без логирования. Если не сохранять диалоги и отметки операторов, через месяц не будет понятно, стал ли бот лучше или хуже. Простая таблица в Metabase или Google Sheets с долей эскалаций и оценками — обязательный минимум.
Не договорились, кто отвечает за документы. Бот начинает ошибаться не из-за кода, а из-за устаревшего регламента, и никто не понимает, к кому идти.
Выбрали модель по бенчмаркам, а не по задаче. Для поддержки с базой знаний важнее стабильность следования инструкциям и стоимость за запрос, чем рекорды в тестах. Часто более дешёвая модель с хорошими документами работает лучше дорогой с плохими.
С чего начать
Переход не требует останавливать текущего бота. Практический порядок такой:
- Выгрузите диалоги за последние два-три месяца и посчитайте, какая доля заканчивается переводом на человека и почему.
- Выберите пять-семь самых частых тем, где бот сейчас не справляется, и подготовьте под них документы.
- Запустите гибридный режим: меню остаётся, свободный текст обрабатывает модель. Две недели — реалистичный срок для первой версии.
- Соберите пометки операторов, доработайте документы, затем подключайте действия в системах.
Базовые принципы построения ботов для поддержки без ИИ описаны в статье о Telegram-ботах для продаж и поддержки — они остаются в силе и после перехода. Если хотите оценить, с какого этапа начать именно вам, можно обсудить задачу на бесплатной консультации.