CRM и Телеграм-бот: как связать заявки без потерь

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

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

Что должно быть в нормальной связке

• какие поля заявки нужны до интеграции
• как не плодить дубли в CRM
• где хранить статусы и ошибки
• с чего начать, если CRM пока не готова

Сначала опишите карточку заявки

Интеграция начинается не с API, а с полей.

Минимально нужно понять:

• имя клиента
• телефон или username
• выбранная услуга
• комментарий
• источник
• дата и время
• UTM или рекламный источник, если есть
• статус обработки

Если у CRM уже есть обязательные поля, их нужно знать до разработки. Иначе бот будет собирать одно, а CRM требовать другое.

Для первого этапа можно собрать таблицу:

Поле в боте	Поле в CRM	Обязательно
phone	телефон контакта	да
service	направление сделки	да
comment	комментарий	нет
source	источник заявки	да
telegram_id	внешний id	желательно

Такой маппинг экономит часы на переделках.

Дубли нужно ловить сразу

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

Нужно заранее решить:

• искать дубль по телефону
• искать дубль по telegram_id
• обновлять старую сделку или создавать новую
• что делать, если телефон не указан
• куда писать технический id заявки

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

Статус нужен и менеджеру, и клиенту

Плохой сценарий: бот сказал “заявка принята”, а дальше тишина.

Лучше сразу задать статусы:

• новая
• передана менеджеру
• в работе
• нужна ручная проверка
• ошибка CRM
• закрыта

Клиенту не обязательно показывать внутренние статусы. Но менеджер должен видеть, где заявка застряла. Если CRM недоступна, бот не должен молча терять данные. Он должен сохранить заявку локально или в таблице, поставить флаг ошибки и отправить уведомление.

Когда достаточно Гугл-таблицы

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

Таблица позволяет:

• проверить поля заявки
• увидеть реальные ответы клиентов
• быстро изменить форму
• не ждать CRM-доступов
• сохранить историю для будущего маппинга

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

Что проверить перед запуском

Перед запуском интеграции нужно пройти несколько сценариев:

1. новая заявка с телефоном
2. заявка без телефона
3. повторная заявка того же пользователя
4. недоступная CRM
5. неверный формат поля
6. длинный комментарий
7. двойной клик по кнопке отправки

Если хотя бы один сценарий теряет данные, рано считать интеграцию готовой.

В кейсе Битрикс24 → Яндекс Метрика ценность была в замкнутой цепочке: форма, CRM, Метрика. Для связки бота и CRM логика такая же. Важна не сама отправка, а прослеживаемость заявки до результата.

Где здесь место n8n

n8n хорошо подходит как диспетчер:

• принять webhook от бота
• привести поля к формату CRM
• создать или обновить сделку
• отправить уведомление
• записать ошибку

Но если появляется сложный дубль-контроль, платежи, личный кабинет или долгие статусы, лучше добавить backend. Иначе workflow начинает держать слишком много ответственности.

Если нужна такая связка, проще начать с интеграции API и CRM или подготовить вводные по гайду для CRM-интеграции.

Как принимать интеграцию

Связку бота и CRM нельзя принимать по фразе “заявка улетела”. Нужно пройти несколько сценариев и посмотреть итог в реальной карточке.

Минимальная проверка:

1. Новая заявка создаёт новую сделку.
2. Повторная заявка не плодит дубль без причины.
3. Неполные данные не ломают маршрут.
4. Ошибка CRM видна в логе или уведомлении.
5. Менеджер получает понятный сигнал.
6. Клиент видит нормальный статус, а не тишину.

Если есть UTM, источник или рекламная кампания, они тоже должны доезжать до CRM. Иначе потом нельзя понять, откуда пришла заявка и какой канал работает.

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

Что будет, если CRM упала

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

Если CRM ответила ошибкой, система должна:

• сохранить исходные данные заявки
• поставить статус ошибки
• показать менеджеру уведомление
• не создавать бесконечные повторы
• дать возможность повторить отправку
• записать ответ CRM в лог

Такой fallback особенно важен для рекламы. Если человек пришёл с платного трафика, потерять заявку из-за временной ошибки внешнего сервиса дорого. Лучше получить уведомление и вручную дожать обращение, чем узнать о проблеме через жалобу клиента.

На первом этапе резерв может быть простым: таблица, файл журнала или внутренняя база бота. Главное, чтобы заявка не исчезала между кнопкой в боте и карточкой в CRM.

Вывод

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

Хорошая интеграция не просто создаёт карточку. Она сохраняет данные, показывает статус и даёт понятный след, если внешний сервис ответил ошибкой.