Как связать ИИ-агента с CRM: данные, действия и контроль

Определите, что должно появиться в CRM

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

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

Составьте карту данных и правил

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

Таблицу можно прокрутить по горизонтали.

Для каждого изменяемого поля задайте приоритет источников. Агент не должен затирать проверенные данные новым предположением только потому, что оно появилось позже в разговоре.

Проверьте API, права и доступные операции

Подключение зависит от конкретного продукта, версии, тарифа, прав пользователя и выбранного способа авторизации. Например, документация amoCRM описывает методы создания и обновления сделок; методы доступны с учётом прав пользователя. В Битрикс24 универсальный метод создания элемента CRM принимает тип сущности и поля. Точные возможности проверяют по актуальной документации и вашему аккаунту.

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

Продумайте повторные обращения и дубли

Клиент может написать снова, изменить номер или обратиться из другого канала. А система может повторить запрос после временного сбоя. Поэтому до запуска согласуйте правила поиска существующего контакта и создания новой сделки. Совпадение имени само по себе не является надёжным основанием объединять клиентов.

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

Не обещайте действие до подтверждения сервиса

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

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

Передавайте менеджеру полезный контекст

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

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

Примите интеграцию по конкретным проверкам

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

• Нужные данные сохранены в правильных полях.
• Повтор не создал лишнюю карточку или задачу.
• Ошибки видны ответственному и допускают восстановление.
• Менеджер получил согласованный контекст.
• Клиент не получил неподтверждённое обещание.

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

Согласуйте повторы и минимальные права

Технический повтор одной отправки отличается от новой задачи прежнего клиента. Для первого нужен устойчивый ID операции и восстановление результата; для второго — правила связи с контактом и действующей сделкой. Не объединяйте всё по одному совпадению телефона без понимания бизнес-смысла.

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

На сайте ЛидПотока снимок атрибуции связан с ID отправки и не меняется при повторе. Принципы разобраны отдельно в материале об источниках заявок. Штатный контроль дублей CRM и защита от повтора операции решают связанные, но разные задачи.

Заполненная карта полей и событий

Учебная карта, близкая к контракту формы этого сайта. Синтетический op-sales-1 обозначает операцию в стенде; production использует UUID.

Таблицу можно прокрутить по горизонтали.

Адаптер CRM может отображать эти данные в поля и служебный контекст. Проверка API сделок в документации amoCRM подтверждает методы платформы; работу нашей формы доказывают отдельные локальные проверки.

Как повторить локальный стенд

Скачайте самодостаточный Python-стенд и выполните python3 service-demos.py. Нужен Python 3, только стандартная библиотека; сеть, CRM, LLM и внешние сообщения не используются. Скрипт проверяет продажи, знания и конкуренцию за слот, выводит JSON с before/after и проверяет результат через assert. Временная база удаляется после запуска.

Ожидается: sales — 2 строки в наивном варианте и 1 после повтора по ключу; support — answer до проверки актуальности и handoff после; booking — два успешных предварительных чтения против одной атомарной записи и конфликта. Эти узкие модели не заменяют испытания реальной системы.