Зачем связывать Telegram-бота с CRM?

Чтобы заявка не жила в переписке. Бот собирает данные и сразу создаёт сделку в CRM с источником, товаром и контактом — менеджер видит её в общей воронке вместе с заявками с сайта и из рекламы. Без интеграции бот превращается в ещё один канал, который приходится вручную переписывать в систему, и часть обращений теряется.

Что нужно от бизнеса, чтобы сделать интеграцию?

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

Можно ли связать бота с 1С или другой учётной системой?

Да, если у системы есть API или хотя бы регулярная выгрузка. Остатки, цены и статусы заказов обычно тянутся из учётной системы, а заявки и переписка живут в CRM. Если API нет, работает обмен файлами по расписанию — медленнее, но для каталога с ежедневным обновлением цен этого достаточно.

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

Одна связка с типовой облачной CRM — несколько дней. Связка с учётной системой на стороне клиента — от двух недель и до восьми, если система старая или справочники не в порядке: нужен доступ к контуру, согласование формата и тестовая база. Основное время уходит не на разработку, а на сверку справочников и на обработку случаев, когда внешняя система недоступна.

Интеграция Telegram-бота с CRM и учётной системой

Как связать Telegram-бота с CRM и учётной системой: заявки уходят в CRM, остатки и цены — в бот. Способы обмена, типовые поломки и что заложить заранее.

Telegram-бот, который собирает заявки и никуда их не передаёт, экономит время только на первом этапе. Дальше начинается ручной труд: менеджер переносит данные в систему, где живут остальные сделки, и делает это с ошибками и с задержкой. Интеграция бота с CRM убирает именно этот участок — заявка попадает в сделку в момент отправки, а бот в ответ показывает пользователю актуальные цены и остатки из учётной системы.

Что с чем обычно связывают, какими способами это делают и где такие связки ломаются — по порядку.

Что связывают с Telegram-ботом

У большинства проектов набор внешних систем повторяется, меняются только названия продуктов.

Система	Что отдаёт боту	Что получает от бота
CRM	Статус сделки, историю обращений	Новую заявку с источником и контактом
Учётная система	Каталог, цены, остатки, статус заказа	Заказ, резерв позиции
Платёжный шлюз	Подтверждение оплаты	Счёт на оплату
Служба поддержки	Ответ оператора	Обращение и историю диалога

Правило, которое экономит месяцы переделок: у каждой сущности должен быть один хозяин. Цена живёт в учётной системе, клиент — в CRM, платёж — в шлюзе. Бот ничего не хранит самостоятельно, он только показывает и передаёт. Как только бот заводит собственный справочник товаров «чтобы быстрее», через полгода появляются две реальности, и разбираться, какая из них верная, приходится вручную.

Слой интеграции существует ровно для одного: чтобы падение внешней системы не превращалось в потерянную заявку.

Три способа связать системы

Выбор способа определяет не вкус разработчика, а то, насколько быстро данные должны быть свежими.

Способ	Свежесть данных	Когда подходит
Опрос по расписанию	Минуты или часы	Каталог, цены, остатки при редком изменении
Webhook	Секунды	Оплата, смена статуса заказа, ответ оператора
Очередь сообщений	Секунды, с гарантией доставки	Всё, что нельзя потерять: заявки, платежи

Опрос — самый простой и самый устойчивый вариант: если внешняя система полежала полчаса, следующий запуск просто заберёт данные заново. Webhook быстрее, но требует, чтобы принимающая сторона всегда была доступна, и обязательно проверки подписи запроса — иначе создать «оплаченный» заказ сможет кто угодно. Очередь дороже в поддержке, зато переживает недоступность получателя без потерь.

Практический совет: начинайте с опроса везде, где задержка в пять минут не мешает бизнесу. Переход на webhook почти всегда возможен позже и почти никогда не требует переписывать логику.

Где такие связки ломаются

Четыре поломки повторяются от проекта к проекту, и все четыре предотвращаются на этапе проектирования. Если вы не знаете, что такое CRM и зачем в неё складывать заявки, начните с разбора что такое CRM-система — дальше речь пойдёт о том, как в неё попадают данные.

Дубли заявок. Пользователь нажал кнопку дважды, сеть моргнула, бот повторил запрос — в CRM три одинаковые сделки. Лечится ключом идемпотентности: каждый запрос несёт идентификатор, повтор с тем же идентификатором ничего не создаёт. Это единственная защита, которая работает надёжно.

Разные справочники. В CRM клиент заведён по телефону, в учётной системе — по номеру договора. Пока не решено, что считается одним и тем же клиентом, любая синхронизация будет плодить дубликаты. Это вопрос не к разработчику, а к бизнесу, и задавать его нужно до старта.

Недоступность внешней системы. Учётная система уходит на обслуживание, а пользователь в это время оформляет заказ. Правильное поведение — принять заказ, поставить в очередь и предупредить, что подтверждение придёт позже. Неправильное — показать ошибку и потерять клиента.

Сетевые ограничения. Прямой доступ к API мессенджера с сервера бывает закрыт на стороне провайдера или страны размещения, и выясняется это в день переноса на боевой контур. У нас так и произошло в проекте мини-приложения для двух мессенджеров: на тестовом контуре всё работало, на боевом — нет. Спас вынесенный отдельно слой обмена с платформой: переключение на прокси и на опрос вместо webhook затронуло один модуль. Держать оба режима сменными стоит несколько часов на старте и экономит недели переделки на финише.

Что заложить в проект заранее

Журнал обмена. Каждый запрос к внешней системе и ответ на него пишутся в лог с идентификатором. Без этого разбор ситуации «заявка не дошла» превращается в гадание.
Повторы с нарастающей задержкой. Не получилось с первого раза — повторить через минуту, потом через пять; когда попытки исчерпаны, обмен уходит в ручной разбор, а не пропадает.
Ручной разбор. Экран, где видно застрявшие обмены и можно повторить их кнопкой. Дешевле любой автоматики и спасает в первый месяц после запуска.
Тестовый контур. Отдельная база CRM и учётной системы. Проверять интеграцию на боевых данных — способ создать десяток фиктивных сделок и объясняться с отделом продаж.

Если бот собирает не только заявки, но и показывает каталог с корзиной, интерфейс переписки быстро становится тесным — тогда логичнее делать мини-приложение внутри мессенджера, а бота оставить точкой входа и каналом уведомлений. Разобраться, нужен ли вообще бот или задача решается сайтом, помогает разбор развилки «сайт или Telegram-бот».

Как понять, что интеграция работает

Интеграция ломается тихо: заявки перестают доходить, а узнают об этом через неделю от отдела продаж. Три простых проверки закрывают этот риск.

Счётчик за сутки. Сколько заявок бот принял и сколько сделок появилось в CRM. Расхождение — повод разбираться сегодня, а не в конце месяца.

Проба на живой системе. Раз в час автоматически создаётся тестовая заявка и проверяется, что она дошла и корректно помечена. Не дошла — оповещение приходит команде, а не клиенту.

Возраст последнего обмена. Если последняя успешная синхронизация с учётной системой была шесть часов назад при расписании в пять минут, что-то остановилось. Это самая простая проверка и самая полезная: она ловит молчаливые отказы, при которых ошибок в логе нет вовсе.

Сколько занимает интеграция бота с CRM

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

Отдельная и почти всегда забытая статья — обработка сбоев. На нашем проекте мини-приложения с обменом примерно четверть времени интеграции ушла на сценарии, где что-то пошло не так: повторы, идемпотентность, ручной разбор застрявших обменов. Планируя бюджет, закладывайте эту часть отдельной строкой — ориентиры по стоимости бота целиком собраны в разборе цен на Telegram-бота.

Технические детали методов и лимитов есть в официальной документации Telegram Bot API — там же описано поведение вебхуков, ограничения на частоту запросов и проверка секретного токена, без которой принимать вебхуки нельзя.

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