У сервиса доставки, с которым мы работали, жалоба звучала знакомо: мало заявок, реклама дорожает, менеджеры не успевают. Когда мы посмотрели переписку, картина оказалась другой - люди уже приходили, но застревали между «сейчас уточню» и «менеджер вам ответит». Деньги терялись не в рекламе, а в паузе после первого сообщения.
Поэтому чат-бот в Telegram нередко окупается быстрее, чем еще 100 000 ₽ в трафик. Он не создает спрос, а убирает лишние шаги между интересом, заказом и оплатой. Если на входе хаос, верх воронки тут не поможет.
Бот нужен там, где заказ можно собрать по шагам
Самая полезная роль бота - быстро собрать обязательные данные: что нужно, куда везти, когда, как связаться, чем оплатить. Когда эта информация сразу попадает в систему, менеджер не тратит полдня на одинаковые уточнения и не переносит заказ в CRM вручную.
У локальной доставки мы перевели ручную переписку в сценарий «категория - адрес - интервал - оплата по ссылке». Время оформления сократилось с 8-12 минут до 2-3 минут, а до 70% диалогов стали проходить без участия менеджера.
До: сообщения терялись в личке, менеджер по кругу уточнял адрес и состав, заказ вручную переносили в CRM.
После: бот собирал обязательные поля, создавал заявку и подключал человека только в исключениях.
Если продажа сложная, бот должен не закрывать всю сделку, а отфильтровать обращение и подготовить разговор. Мы так работаем в услугах с нестандартным расчетом: бот собирает вводные, а менеджер подключается уже с контекстом, а не с вопросом «что вас интересует?».
Большинству компаний хватает короткого MVP
Когда бизнес спрашивает, как создать бота в Телеграме, в голове обычно уже полный набор: каталог, AI, бонусы, рекомендации, ответы на все вопросы. На практике первый релиз почти всегда выигрывает от простоты. Чем короче путь, тем выше конверсия.
Для MVP чаще всего хватает пяти сценариев:
- оформить заказ
- рассчитать стоимость
- записаться
- оплатить
- получить статус
У сервиса печати сначала было большое меню с ветками и возвратами назад. Мы оставили 4 кнопки - «Выбрать тираж», «Загрузить макет», «Рассчитать стоимость», «Оплатить». Доля пользователей, дошедших до заявки, выросла на 22%.
Нужен ли AI, чтобы бот продавал?
Обычно нет. Для малого бизнеса сценарный бот с кнопками и передачей данных в CRM почти всегда полезнее, чем «умный» помощник, которого потом еще долго учить на реальных диалогах.
Сначала карта заказа, потом код
Перед разработкой мы рисуем путь заказа на одной странице: первое сообщение, выбор услуги, обязательные поля, момент оплаты, подключение менеджера, запись в CRM. Если схема не помещается на лист, почти наверняка в боте пытаются автоматизировать лишнее.
У сети кулинарий изначально хотели полный каталог внутри Telegram. По данным повторных покупок, люди чаще всего брали одно и то же, поэтому в первый релиз вошли повторный заказ и 10 популярных позиций. Это сократило запуск на 3 недели.
| Вариант | Когда подходит | Что на выходе |
|---|---|---|
| Конструктор | Проверить гипотезу за 1-2 недели | Быстрый MVP без сложной логики |
| Кастом | Нужны CRM, оплата, статусы | Свои правила и интеграции |
| Polling | Тест или внутренний бот | Проще старт, хуже для production |
| Webhook | Продажи и оплаты | Стабильнее под нагрузкой |
Для продающих ботов мы почти всегда выбираем webhook. Когда нужно без задержек создать сделку, отправить ссылку на оплату и вернуть статус, так в работе меньше сюрпризов.
Интеграции решают больше, чем интерфейс
Если после диалога менеджер все равно копирует заказ, отдельно проверяет оплату и вручную отправляет статус, бот слабо влияет на выручку. По сути, это просто еще один канал переписки.
У одного сервиса доставки связка была без экзотики: Telegram Bot API, Node.js 20 + NestJS, PostgreSQL 16, amoCRM, CloudPayments и webhook. После запуска число ошибок в заказах снизилось примерно на 30%, потому что данные перестали жить одновременно в чате и таблице.
Telegram message
-> bot backend
-> validation
-> CRM
-> payment link
-> status update
Если бот не меняет путь денег внутри компании, это просто красиво оформленная переписка.
Бот плохо окупается в трех случаях:
- входящих обращений мало
- каждая сделка сильно кастомная
- внутри компании нет стабильного процесса, который можно перевести в сценарий
Что обычно ломает запуск
Самый показательный провал у нас был с образовательным проектом. Клиент хотел универсального консультанта: подбор курса, ответы на десятки вопросов, тарифы, рассрочку, акции, напоминания. В итоге пользователи путались, менеджеры подключались почти в каждом диалоге, а бюджет вышел выше плана примерно на 180 000 ₽.
Мы ошиблись в одном: попытались упаковать в бота слишком много логики для первого релиза. Потом переделали проще - заявка, оплата, запись на вводный урок. После этого сценарий заработал, потому что бот перестал изображать консультанта и занялся тем, что умеет лучше всего: быстро доводить человека до следующего понятного шага.
После запуска я бы смотрел всего на четыре метрики:
- сколько диалогов дошло до заявки без менеджера
- где люди бросают сценарий
- сколько времени проходит до оплаты
- сколько заказов вернулось на ручную доработку
За ближайшие 3 дня можно сделать больше, чем за месяц обсуждений: в первый день поднять 30-50 диалогов, во второй нарисовать путь заказа на одном листе, в третий решить, нужен ли вам конструктор или кастом. Если после этого не видно одного конкретного шага, который бот должен сократить, запускать его рано. По нашему опыту, самые дорогие потери в Telegram выглядят как обычная пауза между двумя сообщениями.
В ближайшие годы такие боты будут становиться не сложнее, а точнее: меньше лишних веток, больше интеграций, короче путь до оплаты. Рынок, похоже, уже движется именно туда.
