Интеграция Telegram-бота с CRM: заявки без дублей

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

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

Когда интеграция Telegram-бота с CRM закрывает рабочую задачу

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

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

Важно и то, что бот может работать не только с CRM. Он способен обращаться к нескольким системам через отдельный интеграционный слой — например, читать статус из CRM, а реквизиты из 1С, — но каждая операция и каждое право доступа согласуются отдельно.

Как устроен процесс: от сообщения до задачи в CRM

Типовой контур выглядит так.

1. Идентификация. Бот понимает, кто пишет: клиент, сотрудник или неизвестный пользователь, и с какой карточкой это связано.
2. Вопросы и поля. Задаются обязательные вопросы, проверяется формат ответа — телефон, сумма, дата, артикул.
3. Итог перед отправкой. Пользователь видит собранные данные целиком и подтверждает их.
4. Поиск дубля. Перед записью система ищет существующий контакт или заявку по согласованным ключам.
5. Создание работы. Готовится карточка или задача с нужными полями и следующим шагом для сотрудника.
6. Передача или ответ. Результат уходит менеджеру вместе со сводкой диалога либо пользователь получает разрешённый статус или реквизит.

Каждый шаг описан заранее. Неизвестный сценарий, чувствительное действие и спорный ответ не выполняются автоматически, а передаются сотруднику.

Идентификация контакта и отсечение дубля

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

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

Повторная доставка событий, отказы и риски

Дубли возникают не только от людей. Telegram и CRM доставляют события повторно: сеть моргнула, ответ не успел прийти, webhook сработал дважды. Если обработчик не помнит, что такое событие уже видел, повтор создаёт вторую заявку.

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

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

Пример сценария: заявка из Telegram в CRM

Это рабочий пример сценария, а не опубликованный проект клиента.

Клиент пишет боту отдела продаж в Telegram: нужен расчёт поставки. Бот уточняет компанию, контактное лицо, телефон, объём и желаемую дату, проверяет формат полей и показывает итог. Далее ищет контакт по телефону и названию компании.

Если контакт найден в Битрикс24 или amoCRM, создаётся задача на ответственного менеджера с собранными полями и ссылкой на диалог. Если не найден — готовится черновик карточки, а решение о слиянии остаётся за сотрудником. Менеджер получает уведомление со сводкой: что спросил клиент, какие поля заполнены, какой следующий шаг.

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

Какие данные и доступы нужны для старта

Для первого контура достаточно ограниченного набора.

• Бот: отдельный токен Telegram Bot API, понятный порядок его замены и отзыва.
• CRM: отдельная учётная запись с минимальным набором операций — на старте обычно чтение и создание задач.
• Сеть: доступ с сервера агента к интерфейсу CRM — REST API, webhooks или обмен, доступный именно в вашем тарифе и контуре.
• Данные сценария: перечень обязательных полей, правила дублей, список действий, которые бот выполняет сам, и действий, которые ждут подтверждения человека.
• Инфраструктура: ваш сервер или арендованная площадка в России; классы данных, разрешённые для внешних моделей, фиксируются политикой проекта.

Перечень доступов согласуется с ИТ и ИБ до старта. Если безопасного интерфейса к системе нет, остаются два пути: файловый обмен по расписанию или промежуточный модуль вне системы — так обычно поступают со старыми конфигурациями. Варианты разобраны на странице интеграции с 1С и внутренними системами.

Этапы внедрения и контроль человека

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

1. Сценарий. Фиксируем пользователя, вопросы, обязательные поля и ожидаемое действие.
2. Интерфейс. Проверяем методы Telegram Bot API и доступный интерфейс CRM — API, webhook или обмен.
3. Права. Создаём отдельные учётные данные с минимальным набором операций.
4. Стенд. Прогоняем типовые запросы, повторы, ошибки, таймауты и передачу оператору.

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

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

Как проверить результат и с чего начать

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

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

Эти же проверки закладываются в стенд до запуска. Состав работ и стоимость считаются по открытому прайсу, без скрытых позиций.

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

Если нужен разбор вашего сценария, опишите задачу через контакты OfficeForge: кто пишет боту, какие поля он собирает и что должно появиться в CRM. Состав работ по автоматизации и интеграциям смотрите в разделе услуг.