- «Нам нужен AI-бот для поддержки. В Telegram, быстро и недорого».
Через 30-40 минут такого разговора обычно выясняется, что нужен не «умный бот», а автоматизация нескольких повторяющихся действий: статус заказа, возврат, смена адреса, запись, первичный отбор лида. Я вижу это почти в каждом втором проекте.
Ошибка простая: команда выбирает канал и модель, хотя сначала надо посчитать процесс. Если этого не сделать, через 3 месяца бот либо пересылает проблему оператору, либо начинает стоить дороже ручной работы.
Сначала считаем не бота, а повторяющуюся рутину
Когда бизнес говорит «нам нужен чат-бот», я задаю один и тот же вопрос: какие обращения повторяются каждый день. Если таких тем меньше пяти и они редкие, бот часто вообще не нужен. Проще привести в порядок базу ответов и работу менеджеров.
У сервисной компании под NDA хотели «умного бота на сайте», который будет отвечать почти как человек. Мы подняли историю обращений за месяц и нашли 12 типовых тем, которые съедали время команды в пиковые часы. Вместо LLM сделали сценарный flow с кнопками и связкой с amoCRM. Нагрузка на менеджеров снизилась на 40% уже через 2 недели после запуска.
Если 70-80% запросов типовые, сценарный бот почти всегда полезнее. Бизнесу нужен понятный путь клиента: проверить заказ, оформить возврат, передать сложный кейс человеку и не потерять историю.
Большинство команд недооценивают не цену запуска бота, а цену третьего изменения после запуска.
Конструктор работает быстро, пока сценарии помещаются в таблицу
Конструктор я бы брал для проверки гипотезы. FAQ, запись, лид-форма, квиз, простой Telegram-бот - все это можно поднять за 1-7 дней без своей команды разработки.
В прошлом году мы так запускали MVP для онлайн-школы. Бота на конструкторе собрали за 3 дня, получили первые заявки уже на первой неделе и не потратили 300-500 тыс. ₽ на код до проверки спроса. Для старта это было правильное решение.
Потолок приходит быстро. Сегментация по продуктам, оплата, роли, история диалогов, Bitrix24, ERP, нестандартная аналитика - и начинаются плагины, ручные обходы и ограничения платформы. На практике бесплатный бот остается бесплатным до первой реальной интеграции.
Частая ошибка - брать конструктор, потому что «пока просто».
Правильнее сразу выписать 20 последних обращений и отметить, где нужны данные из CRM, кто принимает решение и что будет, если бот ошибется.
| Подход | Запуск | Где хорош | Где начинает мешать |
|---|---|---|---|
| Конструктор | 1-7 дней | FAQ, лиды, запись | роли, сложная логика, безопасность |
| Платформа | 2-6 недель | CRM, API, несколько каналов | ограничения своей логики |
| Кастом | 1,5-3 месяца | критичные процессы, SLA, AI по базе знаний | дороже старт |
Платформа полезна, когда бот должен жить не один
Если процесс уже понятен, я чаще советую платформу или low-code. Здесь бизнесу нужен не бот сам по себе, а связка с CRM, helpdesk, системой заказов, сайтом и оператором. Особенно важна передача диалога оператору - момент, когда бот переключает клиента без потери контекста.
Для e-commerce-клиента с потоком около 18 тыс. заказов в месяц мы делали бота для статусов и возвратов. Диалоговый слой работал через платформу, интеграции шли в CRM и внутреннюю систему заказов по API. Через 6 недель доля обращений, закрытых без оператора, выросла до 58%, а среднее время первого ответа упало с 9 минут до 40 секунд.
Здесь есть неприятный момент. n8n и Make отлично помогают на старте, когда надо быстро связать формы, мессенджеры и уведомления. Но как только появляются права доступа, ветвления, журнал действий и требования к отказоустойчивости, эти цепочки начинают требовать инженерного внимания почти как код.
Кастом окупается там, где ошибка стоит дорого
Заказная разработка выглядит тяжелой только на входе. Если бот встроен в поддержку, продажи или внутренние операции, цена ошибки через несколько месяцев становится выше цены запуска.
Один раз мы сами затянули с этим решением у B2B-сервиса. Сначала пошли в no-code, потому что хотели быстрее запуститься. Через пару месяцев уперлись в роли доступа, SLA, историю обращений и внутреннюю базу знаний. Перенос на кастом занял 8 недель, и по деньгам проект переплатил около 700 тыс. ₽ на переделке и ручной поддержке.
Для таких задач мы обычно собираем простую, но управляемую схему:
Telegram Bot API / web-виджет
-> backend на Laravel 11 или Node.js 20 + NestJS
-> PostgreSQL 16
-> Redis для очередей и кеша
-> LLM API + поиск по внутренней базе знаний
Это нужно не ради красоты архитектуры. Такой стек дает контроль над логикой, качеством ответов и изменениями через полгода, когда ботом уже пользуются все отделы.
Выбор обычно решается пятью вопросами
Я смотрю на пять вещей: срок запуска, число сценариев, интеграции, требования к аналитике и цену сбоя через 6-12 месяцев. После этого решение обычно становится спокойным и понятным.
- Нужен быстрый тест канала - берите конструктор.
- Процесс уже работает и нужны CRM, API, несколько каналов - идите в платформу.
- Бот влияет на выручку, SLA или внутренние операции - лучше сразу считать кастом.
- Если у процесса больше 3 ручных шагов, автоматизацию уже стоит считать отдельно.
- Если исключений много уже на этапе обсуждения, конструктор надо проверять на ограничениях до запуска.
В ближайшие 6-12 месяцев выиграют не самые разговорчивые боты, а те, кто умеет отвечать по своей базе знаний, помнить контекст между каналами и передавать диалог человеку без потери истории. У хорошего бота главный интеллект - в архитектуре решений, и клиент это быстро замечает.
