В прошлом году клиент пришел с понятным ожиданием: за выходные собрать бесплатного бота, подключить Telegram и разгрузить менеджеров. Через 2 недели бот уже отвечал, отправлял прайс и собирал контакты, но команда все равно сидела в чате, правила ответы и вручную переносила лиды в CRM.
Снаружи автоматизация была. По факту появился еще один интерфейс, который нужно обслуживать. Я разберу, где бесплатный бот дает быстрый результат, а где бизнес просто откладывает нормальный процесс.
Бесплатный бот хорош, когда вы еще ничего не знаете о сценарии
Мы берем бесплатные конструкторы не ради экономии на лицензии. Их ценность в скорости: за 2-3 дня можно проверить, повторяются ли вопросы вообще, или люди сразу требуют человека.
У частной клиники мы собрали Telegram-бота за 1 неделю без тяжелых интеграций: только FAQ, цены, перенос записи и заявка на консультацию. За 7 дней бот собрал 40 частых вопросов, и стало видно, что около 60% обращений - это расписание, стоимость и перенос приема. До запуска команда хотела «умного помощника», но данные показали более простой сценарий: сначала нужны кнопки и понятная структура.
У меня здесь ориентир простой: если бот без оператора закрывает меньше 20-30% типовых запросов, сценарий еще сырой. В этот момент не нужен сложный бэкенд. Нужны логи, реальные формулировки клиентов и один рабочий путь до результата.
Бесплатный бот окупается не нулевой ценой, а скоростью проверки гипотезы.
Кнопки экономят время, но не надо ждать от них магии
Конструктор хорошо работает там, где логика линейная: выбрать услугу, оставить телефон, получить ссылку, записаться в слот. Для этого не нужен «искусственный интеллект», и это нормально. Проблема начинается, когда кнопочное меню внутри компании начинают считать полноценной автоматизацией поддержки.
Мы однажды переоценили такой сценарий в проекте для интернет-магазина. На демо все выглядело убедительно: «доставка», «оплата», «статус заказа». В живом потоке клиенты писали свободным текстом - «где мой заказ», «можно сменить адрес», «товар уже у курьера» - и бот возвращал их в коридор из кнопок. Менеджеры забирали обратно до 80% обращений.
Этот запуск у нас не сработал так, как мы планировали. В итоге бот остался фильтром для простых запросов, а обработку вопросов по заказам мы вынесли в отдельный сервис с доступом к данным. После этого доля ручного разбора снизилась, но сам урок оказался полезнее: красивое демо еще ничего не значит.
| Подход | Свободный текст | Интеграции | Контроль логики |
|---|---|---|---|
| Кнопочный бот | слабый | базовые | высокий |
| AI-бот с базой знаний | средний | зависят от тарифа | средний |
| Кастомный бот с CRM и backend | высокий | почти любые | высокий |
Самая дорогая часть «бесплатно» начинается после диалога
Обычно бизнес упирается не в лимит сообщений. Ограничение появляется в тот момент, когда бот живет отдельно от продаж и поддержки: нет webhook, нет передачи диалога человеку, нет нормальной связки с CRM.
У B2B-компании бот собирал лиды с сайта и из Telegram, но на бесплатном плане нельзя было отправлять контакты в amoCRM автоматически. Менеджеры раз в день переносили все руками. Формально проект был запущен, но по метрикам стало хуже: скорость реакции на заявку ушла с 15 минут до нескольких часов.
Бесплатность заканчивается ровно в тот момент, когда человек становится вашим скрытым интеграционным слоем.
Считается это быстро: 30 лидов в неделю × 7 минут ручной обработки = 3,5 часа. За месяц это уже больше цены платного тарифа или базовой доработки.
Чеклист, после которого я бы уже не держался за бесплатный тариф:
- лиды переносят в CRM вручную;
- оператор не видит историю диалога целиком;
- нужен сайт, Telegram и WhatsApp, а бот сидит в одном канале;
- нет аналитики, где люди выходят из сценария;
- ответы выглядят правдоподобно, но не опираются на ваши данные.
Если совпали хотя бы 3 пункта, вы уже платите за «бесплатно» временем команды.
Переносить в кастом обычно надо раньше, чем кажется
Многие ждут, пока бот «станет популярным». Я смотрю на другое: влияет ли он уже на выручку, SLA поддержки, распределение заявок и внутренние статусы. Если да, это уже часть операционного процесса.
У сервисной компании все началось с простого Telegram-бота для приема заявок. Через 2 месяца понадобилось подтягивать карточку клиента, определять регион, назначать ответственного и ставить задачу в CRM. Мы вынесли логику в backend на Node.js 20 + NestJS, подключили webhook и PostgreSQL 16. Время обработки одной заявки сократилось с 15 минут до 2-3 минут.
Telegram Bot API -> webhook -> backend -> CRM/helpdesk -> оператор
-> база знаний / LLM -> ответ клиенту
Когда точно пора уходить из конструктора?
Когда у бота уже 3-4 критичных интеграции, есть права доступа, нужна аналитика по воронке и цена ошибки заметна в деньгах. В этот момент конструктор начинает тормозить быстрее, чем помогает.
Можно ли остаться на no-code дольше?
Можно, если сценарий узкий, ответы проверяемы, а сбой не бьет по продажам и данным клиентов. Для записи, FAQ и простой квалификации этого часто хватает надолго.
Выбирать надо по цене ошибки, а не по слову AI
Если бот отвечает на вопросы про график работы, ошибка дешевая. Если он меняет адрес доставки, обещает срок отгрузки или создает лид в воронке, ошибка уже дорогая. По этой границе и стоит принимать решение о платформе.
Клиент из начала статьи хотел «бота за выходные», чтобы менеджеры выдохнули. По факту это случилось только после того, как мы посчитали минуты ручной работы и убрали их из процесса. У бесплатного бота редко проблема в интеллекте - обычно проблема в том, что за ним все еще сидит человек.
