Kommo + Telegram-бот: кастомный бот в воронке

Кастомный Telegram-бот подключается к Kommo через Telegram Bot API на стороне бота и Chats API на стороне CRM: входящие сообщения попадают в воронку как чаты сделок, а исходящие отправляет ваш сервер. Это снимает ограничения встроенного Salesbot и виджетов магазина - вы пишете любую логику, привязываете chat_id к сделке и управляете движением по этапам напрямую через API. Бот живёт внутри воронки, а не сбоку от неё.

Команда Exceltic.dev регулярно собирает такие связки для клиентов на Kommo, и почти всегда повод одинаковый: компания уже попробовала Salesbot и сценарии в Zapier или Make, упёрлась в потолок и хочет ветвления, внешние вызовы и состояние, которых в no-code просто нет. Мы видим это на проектах с потоком от 300 диалогов в месяц, где каждое лишнее ручное касание менеджера стоит денег.

Типичная картина перед переходом: Salesbot отвечает шаблонами, но не умеет сходить во внешний API за остатком на складе, не помнит контекст прошлого диалога и ломается на любом ветвлении сложнее «да/нет». Логика расползается между виджетом, правилами Digital Pipeline и тремя зап-сценариями, и никто в команде уже не может сказать, где именно бот принимает решение.

Операционная боль здесь не в самом боте, а в разрыве между ним и воронкой. Лид пишет в Telegram, бот отвечает, но сделка либо не создаётся, либо создаётся без привязки к диалогу, и менеджер видит пустую карточку. Квалификация, которую бот уже провёл в переписке, не доезжает до полей сделки, и человек переспрашивает то, что клиент написал пять минут назад. Каждый такой разрыв - это и потерянная конверсия, и раздражённый лид.

Почему встроенного бота и виджета не хватает

Kommo даёт два штатных пути к Telegram, и оба упираются в потолок на реальных сценариях. Понять границы проще, если разложить, что каждый из них умеет.

Salesbot - визуальный конструктор внутри Kommo. Он отлично закрывает линейные сценарии: поприветствовать, задать пару вопросов, поставить задачу, передать менеджеру. Но как только нужна нелинейная логика, состояние между сообщениями или вызов внешнего сервиса, конструктор начинает сопротивляться. Условные переходы есть, но отлаживать дерево из двадцати веток в визуальном редакторе - отдельная работа.

Встроенная интеграция Telegram подключает аккаунт или бота как канал и складывает переписку в карточку. Это messenger-канал, а не платформа автоматизации: сообщения видны, но логику поведения вы всё равно пишете в Salesbot или Digital Pipeline.

No-code-прослойки вроде Zapier и Make снимают часть боли, но добавляют свою. Каждый шаг - это задержка и расход операций, состояние диалога приходится хранить костылями, а отладка идёт по логам чужой платформы. На потоке в тысячи сообщений в месяц цена операций и лаги становятся ощутимыми, а сценарий всё равно остаётся хрупким.

Кастомный бот убирает прослойку целиком. Ваш код получает апдейт напрямую от Telegram, принимает решение с полным доступом к базе, внешним API и истории, и сам же пишет результат в сделку Kommo. Между лидом и воронкой остаётся ровно один компонент, который вы контролируете.

Что реализуется технически

Связка стоит на двух API: Telegram Bot API для общения с мессенджером и Kommo Chats API для записи диалога в воронку. Ниже - ключевые узлы, которые приходится собирать на каждом таком проекте.

Telegram Bot API: получение апдейтов

Бот создаётся через @BotFather, который выдаёт токен. Дальше Telegram доставляет апдейты одним из двух взаимоисключающих способов - long polling или webhook.

Long polling - бот сам в цикле вызывает метод getUpdates, Telegram держит соединение открытым до появления новых сообщений. Не требует SSL и публичного адреса, удобен для разработки. Важное ограничение: два параллельных вызова getUpdates с одним токеном Telegram отклоняет с ошибкой 409 Conflict, поэтому горизонтально такой бот не масштабируется.

Webhook - вы вызываете setWebhook с публичным HTTPS-адресом, и Telegram сам шлёт каждый апдейт POST-запросом на ваш сервер. Нужен валидный SSL-сертификат, порт из списка 443, 80, 88 или 8443. Это рабочий вариант для продакшена: ниже задержка, бот ставится за балансировщик.

Long polling против webhook

Два режима взаимоисключающие. Пока активен webhook, getUpdates возвращает 409, и наоборот. При переключении на polling сначала вызывают deleteWebhook, при обратном переходе - setWebhook. Непринятые апдейты Telegram хранит до 24 часов, дальше теряет, поэтому простой сервера дольше суток означает потерянные сообщения.

Термин: апдейт (update) - объект, который Telegram присылает боту на каждое событие: новое сообщение, нажатие inline-кнопки, изменение в чате. Содержит идентификаторы чата и пользователя, текст и метаданные. Именно из апдейта бот достаёт chat_id для дальнейшей привязки.

Webhook на стороне Kommo и привязка chat_id к сделке

Kommo через Chats API шлёт webhook на каждое сообщение, отправленное из интерфейса CRM в канал. Все такие webhook несут заголовок X-Signature, посчитанный по HMAC-SHA1, - подпись нужно проверять, а бизнес-логику выполнять в фоне, потому что Kommo отправляет webhook ровно один раз и не повторяет при сбое.

Ключ всей конструкции - связка chat_id Telegram со сделкой Kommo. Когда лид пишет впервые, бот создаёт или находит сделку и сохраняет соответствие chat_id -> lead_id в своей базе. Дальше любое сообщение из Telegram бот кладёт в правильную сделку, а любой ответ менеджера из Kommo бот доставляет в нужный чат. Эта таблица соответствий и есть то, чего no-code-прослойки надёжно держать не умеют.

Как это работает пошагово

Чтобы было видно целиком, вот маршрут одного диалога от первого сообщения до записи в воронку.

1. Лид пишет боту в Telegram. Telegram шлёт апдейт на ваш webhook (или бот забирает его через getUpdates).
2. Бот достаёт chat_id и текст, проверяет в своей базе, есть ли уже сделка для этого чата.
3. Если сделки нет - бот через Kommo API создаёт сделку и контакт, проставляет источник и сохраняет связку chat_id -> lead_id.
4. Бот выполняет логику: задаёт квалифицирующие вопросы, ходит во внешние сервисы, ветвится по ответам, пишет результат в поля сделки.
5. По итогам квалификации бот двигает сделку на нужный этап воронки и ставит задачу менеджеру или передаёт диалог человеку.
6. Когда менеджер отвечает из интерфейса Kommo, прилетает webhook Chats API с подписью X-Signature. Бот проверяет подпись, находит chat_id по lead_id и доставляет сообщение в Telegram.

С этого момента диалог идёт в обе стороны через один компонент, а воронка всё время отражает реальное состояние сделки. Как именно раскладываются этапы под такой сценарий, мы разбирали в материале о том, как настроить воронку в Kommo CRM.

Реальный кейс с цифрами

Чтобы показать порядок величин, опишем типовой проект из нашей практики - B2B-сервис на Kommo с входящим потоком из Telegram.

До переезда на кастомного бота компания работала через Salesbot плюс два сценария в Make. Входящих диалогов было около 1400 в месяц, первый ответ менеджера занимал в среднем 18 минут, а до этапа квалификации без потери контекста доходило примерно 55 процентов лидов - остальные отваливались на ручных переспросах или дублях карточек.

После сборки кастомного бота на webhook с привязкой chat_id к сделке поменялось следующее:

• Первый осмысленный ответ - мгновенный, бот сам квалифицирует и заполняет поля сделки до того, как её увидит менеджер.
• Доля лидов, доехавших до квалификации с сохранённым контекстом, выросла с 55 до 89 процентов.
• Расход операций в Make ушёл в ноль - около 14 тысяч операций в месяц больше не оплачиваются.
• Менеджеры перестали дублировать карточки: связка chat_id -> lead_id гарантирует одну сделку на один диалог.

Цифры конкретного проекта зависят от потока и сложности сценария, но направление повторяется: убирается прослойка, исчезают разрывы между чатом и воронкой, снижается доля ручных касаний. Базовый набор возможностей CRM, на которые такой бот опирается, мы свели в обзоре функций Kommo CRM.

Для кого это подходит

Кастомный бот оправдан не всем - решает он конкретный класс задач. Разложим, кому он действительно нужен.

Связка имеет смысл, если у вас поток от нескольких сотен диалогов в месяц, сценарий не укладывается в линейное дерево Salesbot, и боту нужно ходить во внешние системы - проверять остатки, считать цену, дёргать вашу базу или сторонний сервис. Отдельный сигнал - вы уже платите за операции в Zapier или Make и упираетесь в их лимиты или задержки.

Если же сценарий простой - поприветствовать, задать два вопроса, поставить задачу - штатного Salesbot хватит, и городить кастом нет смысла. Граница проходит там, где появляется состояние между сообщениями, ветвление сложнее пары условий или интеграция с системой, которой нет в маркетплейсе.

Отдельно стоит трезво оценить ресурс: кастомный бот - это код, который нужно хостить, мониторить и обновлять под изменения Telegram Bot API и Kommo API. Если в команде нет разработчика и нет подрядчика на поддержку, лучше начать с того, что есть в Kommo из коробки. Что именно входит в платформу, удобно сверить по обзору Kommo CRM, прежде чем решать про кастом.

Часто задаваемые вопросы

Чем кастомный бот отличается от Salesbot в Kommo?

Salesbot - визуальный конструктор внутри Kommo для линейных сценариев: приветствие, пара вопросов, постановка задачи. Кастомный бот - это ваш код на сервере, который общается с Telegram через Bot API и пишет в воронку через Kommo Chats API. Разница в потолке: кастом умеет хранить состояние между сообщениями, ходить во внешние API, делать произвольные ветвления и держать таблицу соответствий чатов и сделок. За это вы платите необходимостью хостить и поддерживать код, тогда как Salesbot работает из коробки без инфраструктуры.

Webhook или long polling - что выбрать для продакшена?

Для продакшена - webhook. Telegram сам шлёт апдейты на ваш HTTPS-адрес, задержка ниже, бот можно ставить за балансировщик. Нужен валидный SSL-сертификат и порт 443, 80, 88 или 8443. Long polling проще для разработки и не требует публичного адреса, но не масштабируется: два параллельных вызова getUpdates с одним токеном Telegram отклоняет с ошибкой 409 Conflict. Режимы взаимоисключающие - перед переключением на polling вызывают deleteWebhook.

Как одна сделка остаётся привязанной к одному диалогу?

За это отвечает таблица соответствий chat_id -> lead_id в базе бота. При первом сообщении лида бот создаёт сделку в Kommo и сохраняет связку идентификатора Telegram-чата с идентификатором сделки. Дальше любое входящее сообщение бот кладёт в ту же сделку, а ответ менеджера из Kommo доставляет в правильный чат. Именно этой устойчивой связки обычно не хватает no-code-прослойкам, из-за чего возникают дубли карточек и потеря контекста.

Безопасно ли принимать webhook от Kommo?

Да, если проверять подпись. Каждый webhook Chats API несёт заголовок X-Signature, посчитанный методом HMAC-SHA1. Ваш сервер должен пересчитать подпись по телу запроса и секрету и сравнить - так вы отсекаете поддельные запросы. Важная деталь: Kommo шлёт webhook ровно один раз и не повторяет его при сбое обработки, поэтому подпись проверяют сразу, а тяжёлую бизнес-логику выносят в фоновую обработку, чтобы быстро вернуть ответ и не потерять событие.

Сколько времени занимает сборка такой связки?

Зависит от сложности сценария. Базовый контур - приём апдейтов, создание сделки, привязка chat_id, двусторонняя доставка сообщений - собирается за несколько дней. Дальше время уходит на саму логику бота: квалификацию, ветвления, интеграции с внешними системами и движение по этапам воронки. Хостинг, мониторинг и обработка краевых случаев (повторные сообщения, простой сервера дольше 24 часов, смена токена) добавляют свою часть. Реалистично закладывать от одной до нескольких недель на боевую версию.

Главный вывод

Кастомный Telegram-бот в воронке Kommo нужен там, где штатный Salesbot и no-code-прослойки упёрлись в потолок: при потоке от сотен диалогов, нелинейной логике и необходимости ходить во внешние системы. Технически это связка Telegram Bot API и Kommo Chats API с устойчивой привязкой chat_id к сделке - она убирает разрывы между чатом и воронкой, дубли карточек и расход операций в сторонних платформах.

Если вы уже на Kommo и упёрлись в ограничения Salesbot, Zapier или Make, в Exceltic.dev можно прийти с конкретным сценарием и разобрать, где проходит граница между штатными средствами и кастомом именно в вашем потоке. Стартовая точка - главная страница, а дальше предметный разговор по вашей воронке.

Документация для технической проверки: Telegram Bot API, Kommo Chats API webhooks и общая документация для разработчиков Kommo.