Как подключить чат-бот к CRM: обмен, дубли, права

Чат-бот подключают к CRM через её программный интерфейс (API), под отдельной служебной учётной записью с минимальными правами. Бот сначала ищет клиента, потом находит или создаёт карточку, записывает обращение и передаёт диалог человеку с контекстом. Подключение ломается не на передаче данных, а на трёх вещах: бот не узнаёт клиента и создаёт вторую карточку, повторная доставка одного сообщения создаёт вторую сделку, и у бота прав больше, чем нужно.

Статья — про устройство обмена, а не про выбор бота. Услуга описана на странице «Интеграция чат-бота с CRM», а о том, где достаточно сценарного бота и где нужен агент, сказано в статье «Чем ИИ-агент отличается от чат-бота».

Что бот делает с CRM: пять операций и риск каждой

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

Принцип такой же, как для агентов с действиями: чем необратимее операция, тем меньше самостоятельности у бота. Подробно о правах и подтверждениях — в статье «Права ИИ-агента и подтверждение действий».

Как бот узнаёт клиента и не создаёт вторую карточку

Главная причина дублей — не ошибка кода, а то, что бот и CRM знают клиента по разным идентификаторам. В мессенджере у человека есть внутренний номер аккаунта, телефон он может не показывать, а в CRM карточка заведена по телефону и фамилии.

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

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

Повторы, сбои и порядок: как записывать в CRM без дублей и потерь

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

• Ключ повтора. Каждое событие получает собственный номер (например, идентификатор сообщения мессенджера). Перед записью проверяется, не обработано ли оно, и повторная доставка ничего не создаёт.
• Очередь записи. Бот не пишет в CRM прямо из обработчика сообщения. Событие кладётся в очередь, отдельный обработчик пишет в CRM, а при ошибке повторяет с растущими паузами.
• Блокировка одновременных записей. Если клиент отправил три сообщения подряд, обработчики не должны одновременно искать «нет карточки» и создать три. Запись по одному клиенту идёт по очереди.
• Журнал обмена. Для каждого события видно: получено, записано, ошибка, повтор. По журналу отвечают на вопрос «почему обращения нет в CRM».

Что видит клиент при недоступности CRM, решается отдельно. Бот может продолжить диалог, сохранив обращение в очереди, и сказать, что заявка принята. Нельзя отвечать «заявка создана номер такой-то», пока CRM номер не вернула.

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

Сопоставление полей: что бот заполняет и кто хозяин данных

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

Справочники CRM (источники, воронки, причины отказа) бот не придумывает, а берёт значения из системы. Новое значение появляется в справочнике по решению владельца CRM. Если справочники в CRM ведутся в нескольких местах, это нужно исправить до подключения, иначе бот размножит беспорядок. Общая схема распределения хозяев данных между системами описана в статье «Интеграция 1С с CRM: типовые схемы».

Права бота в CRM и персональные данные

Бот работает под служебной учётной записью. Права на неё выдаются по списку операций из первой таблицы, а не по принципу «дайте администратора, чтобы заработало».

• Минимум по операциям. Если бот не должен удалять и объединять карточки, у записи нет такого права. Проверяется попыткой, а не чтением настроек.
• Минимум по данным. Бот видит только те воронки и поля, с которыми работает. Если CRM позволяет ограничить доступ по подразделению или воронке, ограничение включают.
• Секреты. Ключи и токены лежат в хранилище секретов, а не в коде и не в репозитории. Срок жизни и порядок замены записаны в регламенте.
• Тестовая и боевая среда. Бот сначала подключается к тестовому аккаунту CRM или к отдельной воронке. Боевая запись включается после приёмки.
• Журнал. По каждой записи видно, что бот создал или изменил и по какому событию. Это нужно и для разбора ошибок, и для вопросов службы безопасности.

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

Передача человеку: что видит оператор и как не потерять диалог

Бот закрывает типовое и должен вовремя звать человека. В подключении к CRM это означает, что передача — не сообщение «ждите», а задача менеджеру с контекстом.

• Причина передачи. Клиент попросил человека, бот не уверен, вопрос вне темы, клиент недоволен. Причина записывается в карточку, потому что по ней потом настраивают бота.
• Сводка диалога. Менеджер читает несколько строк, а не прокручивает переписку. Полный диалог доступен по ссылке.
• Срок реакции. Задача получает срок, а при его нарушении уведомляется руководитель смены. Если сотрудников нет на связи (ночь, выходной), бот честно говорит, когда ответят.
• Возврат боту. После решения вопроса менеджером диалог либо закрывается, либо возвращается боту. Иначе бот и человек отвечают клиенту одновременно.

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

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

Проверка идёт по сценариям, а не по ощущению «работает». Набор сценариев составляется на обследовании и входит в приёмку.

1. Новый клиент пишет впервые: создаются контакт и обращение, поля заполнены, источник указан.
2. Существующий клиент пишет из нового канала: идентификатор добавлен к старой карточке, новая не создана.
3. Один номер у двух карточек: бот не выбирает, а отдаёт вопрос оператору.
4. Одно сообщение доставлено дважды: запись одна.
5. Три сообщения подряд от нового клиента: карточка одна.
6. CRM недоступна: обращение лежит в очереди, после восстановления записано один раз.
7. Менеджер изменил поле, затем клиент написал снова: поле не затёрто.
8. Попытка бота выполнить запрещённую операцию (удаление, слияние) отклонена правами.
9. Передача человеку: задача создана с причиной и сводкой, срок поставлен.
10. Клиент спрашивает про чужой заказ: бот не раскрывает данные.

Затем запуск на части трафика: один канал или один отдел, а не все сразу. Первые дни смотрят журнал обмена, число дублей и отзывы менеджеров. Критерий успеха — не «бот отвечает», а «менеджер не перепроверяет записанное».

Типичные ошибки и признаки плохого подключения

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

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

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один канал и одну CRM, 350 000 ₽ и 3–4 недели за несколько каналов и систем. На выходе таблица операций бота, правила идентификации и слияния, матрица хозяев данных, список прав служебной учётной записи и набор сценариев приёмки. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.

Дальше лёгкий пилот одного сценария и одной CRM (150 000–400 000 ₽, 2–8 недель), затем при необходимости тяжёлый пилот с действиями в CRM и вывод в эксплуатацию. Мы делаем один канал и одну связку, а не внедрение CRM целиком, не дежурим круглосуточно и не даём юридических консультаций. Исходники лежат в вашем репозитории с первого коммита. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Интеграция чат-бота с CRM».