В прошлом году к нам пришел владелец сети клиник с запросом на "AI-ассистента" в Telegram. Мы подняли 180 последних диалогов и увидели, что 76% обращений - это запись, перенос визита, цены, адреса и подготовка к приему. Для такой нагрузки LLM не нужен: здесь важнее сценарий, CRM и нормальная передача на человека.
Путаница обычно возникает не в технологиях, а в экономике. Если не разложить это в начале, легко купить дорогого бота, который звучит убедительно, но решает те же задачи хуже и дороже.
Когда сценарный бот выигрывает у AI
Обычный rule-based бот хорошо работает там, где вопросы укладываются в ограниченное число сценариев. На практике это запись, ответы на 10-15 частых вопросов, статус заказа, выбор услуги, сбор контактов, первичная маршрутизация в продажи или поддержку.
Его сильная сторона - контроль. Он не выдумывает, не меняет ответ от диалога к диалогу и не спорит с бизнес-правилами. Для малого и среднего бизнеса это часто полезнее, чем "умный" интерфейс.
У нас был проект для региональной сети клиник: Telegram-бот на BotHelp, связка с amoCRM, ночной сбор лидов, запись и FAQ по услугам. Запустили за 12 дней. Ручная нагрузка на администраторов снизилась на 34%, конверсия в лид выросла на 18%. Бот просто вел человека по короткому маршруту и не терял заявки ночью.
CTO сервисной B2B-компании однажды точно это сформулировал: "Самая частая ошибка - автоматизировать хаос и называть это AI-стратегией".
Где AI начинает окупаться
AI нужен, когда люди пишут свободным текстом, длинно и каждый по-своему. Если у компании 100-200+ типовых вопросов, но они приходят в десятках формулировок, поддержка сценарных веток быстро становится дорогой и начинает отставать от реальности.
Я обычно вижу четыре рабочих сценария:
- первая линия поддержки со свободным текстом от клиента
- поиск по базе знаний и help center
- сложная квалификация лида перед продажей
- внутренний помощник по регламентам, CRM и документам
В таких задачах мы не даем модели отвечать "по памяти". Собираем RAG: OpenAI или Anthropic, поиск через pgvector в PostgreSQL 16, иногда Weaviate, если база знаний большая. Модель сначала находит источник, потом формирует ответ. Иначе цена ошибки быстро съедает весь эффект.
| Параметр | Сценарный бот | AI-бот | Гибрид |
|---|---|---|---|
| Предсказуемость | высокая | средняя | высокая |
| Стоимость запуска | низкая | выше | средняя |
| Гибкость | ограничена ветками | высокая | высокая |
| Риск ошибок | низкий | выше без RAG | средний |
| Требования к данным | минимальные | высокие | средние |
На проектах чаще побеждает гибридная схема. Критичные шаги - тарифы, запись, доставка, возвраты, расчеты - мы держим в сценариях. Свободные вопросы и поиск по длинной документации отдаем модели.
Главная ошибка - не понимать, откуда бот берет правду
Самый дорогой провал, который я видел, был в e-commerce. Магазин хотел AI-бота для поддержки: остатки лежали в одной системе, доставка жила в Excel, возвраты были в PDF, акции менеджеры держали в чате. Мы подключили модель, настроили промпты, дали доступ к части данных - и получили уверенные, но неверные ответы.
Доля передач оператору выросла до 47%. Команда вручную переписывала диалоги, клиенты спорили с поддержкой, потому что "бот же сказал". Проблема была не в модели. Не было единого источника данных и правил, в какой момент бот должен остановиться и позвать человека.
Один раз мы сами недооценили это на старте и слишком рано пошли в настройку модели, вместо того чтобы сначала собрать источники данных в понятную схему. Метрики быстро показали, что без этого качество не удержать.
Как это проверить быстро?
Спросите не "хотим ли мы AI", а "откуда бот берет актуальный ответ". Если на один вопрос у вас три источника - CRM, таблица и менеджер в чате, - бот начнет ошибаться независимо от платформы.
Конструктор, кастом или пилот на 2 недели
Для пилота я почти всегда советую начинать проще. Проверить FAQ, запись, лидогенерацию или ночной сбор заявок можно без большой разработки и без бюджета в сотни тысяч.
Конструктор подходит, если задача стандартная:
- Telegram-бот или виджет на сайт
- квиз, запись, FAQ, сбор контактов
- готовая интеграция с amoCRM, Bitrix24, Make, n8n
Кастом начинается там, где появляются персональные цены, права доступа, история клиента и данные из ERP и CRM в реальном времени. У нас был B2B-сервис, где бот должен был учитывать договорные лимиты по отгрузке. На конструкторе схема выглядела аккуратно, но ломалась на исключениях. Перешли на Node.js 20 + NestJS, PostgreSQL 16 и отдельный слой интеграции - после этого ответы стали предсказуемыми.
Что сделать в ближайшие 3 дня
Я бы шел по короткому маршруту: один канал, один сценарий, один показатель успеха. В первый день выгрузите 100-200 обращений и руками разложите их по темам. Во второй посчитайте, что для вас дороже: ошибка бота или час работы менеджера. В третий соберите пилот на самом частом сценарии. Если после этого AI все еще просится в решение, значит он действительно нужен. Если нет, вы сэкономили не только бюджет, но и месяцы на исправление чужой уверенности.
