Чат-бот способен распознавать, что новая заявка пришла от компании, которая уже обращалась, и автоматически добавлять её к существующей сделке в CRM. Для этого бот сверяет ключевые поля — ИНН, домен почты, название организации — с базой контактов и либо создаёт новую карточку, либо дополняет старую. Такой механизм экономит время менеджера и не даёт одному клиенту превратиться в три дубля воронки. В статье разберём, какие данные нужны для идентификации, как настроить логику сопоставления и что делать, когда совпадение неточное.
Почему дубли заявок — головная боль для B2B
Закупщик крупного клиента пишет в Telegram. Через неделю его коллега оставляет заявку на сайте. Ещё через месяц главный инженер уточняет характеристики в Viber. Три разных человека — одна компания, но CRM видит три независимых лида. Менеджеры тратят время на выяснение, кто из них «горячий», а кто давно ждёт ответа. Хуже того, одному клиенту могут позвонить дважды с разными условиями.
Интеграция чат-бота с CRM позволяет боту создавать или обновлять карточку лида, записывать все ответы из диалога, выставлять статус и теги, ставить задачу менеджеру и фиксировать стадию воронки (Консоль.про). Без такой связки чат-продажи превращаются в изолированный канал, где информация теряется между сообщениями.
Какие данные помогают распознать повторное обращение
Идентификатор компании надёжнее имени контакта. Вот что бот может использовать для сопоставления:
| Поле | Надёжность | Где получить |
|---|---|---|
| УНП / ИНН | Высокая | Спросить в диалоге или взять из карточки CRM |
| Домен корпоративной почты | Средняя | Автоматически из email или Telegram-username |
| Название организации | Средняя (требует нормализации) | Первый вопрос бота или поле формы |
| Телефон с общим кодом | Низкая | Проверка по префиксу номера |
Сочетание двух полей — например, домен почты плюс название — даёт достаточную точность для большинства сценариев. УНП работает идеально, но не каждый клиент готов его назвать на первом шаге диалога. Бот ведь должен собирать данные по B2B-заявке, не превращая диалог в анкету.
Как настроить логику сопоставления в связке бот — CRM
Типичная схема выглядит так: бот получает сообщение, извлекает идентификатор (домен, УНП, телефон), отправляет запрос в CRM на поиск существующей карточки. Если карточка найдена — бот добавляет новую заявку как активность или сделку внутри неё. Если нет — создаёт новую карточку и заносит все собранные данные.
Практические шаги:
- Определите приоритет полей для сопоставления. УНП — первый приоритет, домен — второй, название — третий.
- Настройте в CRM кастомное поле «Домен» или «УНП», если его ещё нет. Без него API не сможет искать по этому признаку.
- Добавьте в сценарий бота условие: «Если найден контакт с таким доменом — связать заявку с существующей компанией».
- Для неточных совпадений (например, «ООО Альфа» vs «Альфа ООО») используйте нормализацию строк: убрать пробелы, привести к нижнему регистру, удалить типовые суффиксы.
Бот может сегментировать клиентов по тегам, статусам, источникам, проводить опросы и сохранять ответы в системе (ChatLabs). Это же работает и для объединения заявок: каждый диалог получает тег с номером компании, и менеджер видит всю историю в одном месте.
Что делать, когда совпадение неточное
Иногда бот находит похожую, но не идентичную запись. «ИП Иванов» и «Иванов И.И.» — это один клиент или разные? Автоматика здесь рискует ошибиться.
Варианты решения:
- Бот уточняет у клиента: «Вы уже обращались от компании „ИП Иванов"?» Один вопрос, ответ да/нет.
- Бот создаёт заявку, но ставит менеджеру задачу: «Проверить возможный дубль». Менеджер объединяет вручную за минуту.
- Система использует порог совпадения: 90% — автоматическое объединение, 70–89% — уведомление менеджеру, ниже 70% — новая карточка.
Главное — не молчать. Если бот сомневается, он должен либо спросить, либо передать решение человеку. Разрушительные действия вроде объединения двух реальных компаний в одну требуют подтверждения.
Типичные ошибки при объединении заявок
- Искать только по email контактного лица. Люди меняют почту, увольняются, используют личные ящики. Домен компании стабильнее.
- Не хранить историю обращений. Объединили заявки — а старые сообщения потерялись. CRM должна сохранять каждый диалог.
- Игнорировать разные юрлица одной группы. «Альфа-Строй» и «Альфа-Логистика» — связанные компании, но сделки отдельные.
- Не уведомлять менеджера о повторном обращении. Клиент вернулся — это сигнал, а не рутина.
- Полагаться только на ручное объединение. Менеджер занят, дубли копятся неделями.
Как это выглядит в реальном сценарии
Представьте: снабженец производственной компании запрашивает цену на комплектующие. Бот собирает данные, спрашивает домен почты (@zavod.by), создаёт карточку в CRM. Через три недели инженер той же компании пишет из Viber с вопросом о совместимости. Бот видит домен, находит карточку, добавляет заявку как новую сделку внутри неё. Менеджер открывает профиль и видит обе заявки, историю переписки, контакты двух сотрудников.
Для более сложных запросов — когда клиент просит расчёт по нестандартной конфигурации — бот может собрать предварительное коммерческое предложение и приложить его к карточке. Менеджер получает не просто заявку, а готовый черновик.
3 шага, которые можно сделать на этой неделе:
- Добавьте в CRM кастомное поле «Домен компании» и заполните его для существующих клиентов — займёт час-два.
- Настройте в сценарии бота вопрос о корпоративной почте или УНП на раннем этапе диалога.
- Создайте тестовую заявку от имени существующего клиента и проверьте, объединяется ли она с карточкой или создаёт дубль.
