Интеграция AI-агента звонков с CRM: план подключения

Вопрос об интеграции на самом деле двойной

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

Большинство проектов отвечает на первый и оставляет второй открытым. Результат знаком: агент звонит, менеджер звонит тому же клиенту, клиент дважды объясняет одно и то же и меняет мнение о компании.

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

В каком направлении идут данные

Направлений два, и работают они с разной частотой и разным объёмом. Планировать их нужно отдельно.

1. 1Из CRM в агента: кому звонитьЦелевой список строится фильтром: источник, статус, диапазон дат, этап. Объём здесь большой, частота низкая — раз или несколько раз в день.
2. 2Из CRM в агента: контекст разговораИмя клиента, результат прошлого звонка, открытый заказ или договор. Именно эта часть сильнее всего меняет качество разговора и чаще всего пропускается.
3. 3Из агента в CRM: результат звонкаКод результата, извлечённые поля, резюме, следующий шаг. Частота высокая — после каждого звонка.
4. 4Из агента в CRM: события и статусНачало звонка, завершение, передача. Эти события питают ленту и составляют основу отчётности.

Второй из четырёх пропускают чаще всего. Без контекста агент начинает каждый звонок с нуля, и клиент произносит фразу «я же говорил это в прошлый раз» — она портит остаток разговора.

Четыре способа подключения

Технически выбор сводится к четырём вариантам, и подходящий зависит от уже существующих систем.

• Webhook: одна система уведомляет другую о событии — простейший путь к реальному времени
• Запросы к API: одна система читает или пишет в другую в нужный момент
• Обмен файлами: CSV или похожий формат, ежедневно или еженедельно — до сих пор самый надёжный способ работать со старыми системами
• Готовая интеграция: если обе стороны поддерживают одну платформу, настройка занимает несколько часов
• Промежуточный слой: подключение через интеграционную платформу — быстро, но это дополнительная зависимость

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

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

Идентичность и дубликаты

Самый крупный источник проблем при соединении двух систем — как узнать одного и того же клиента с обеих сторон. На стороне звонков ключом обычно служит номер телефона, а номер — слабый ключ.

• Один номер может принадлежать двум людям — семья, офис, общая линия
• У одного человека несколько номеров, и звонит он в разное время с разных
• Форматы записи разные: с кодом страны, без, с пробелами, с дефисами
• В старой базе номера не проверялись, и часть из них неверна
• Собственные номера компании могут попасть в базу как клиентские

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

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

Реальное время или пакет

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

1. 1Случаи, требующие реального времениЗвонок новому лиду сразу, приём входящего звонка, подтверждение оплаты или заказа. Задержка здесь напрямую снижает результат.
2. 2Случаи, где хватает пакетаСписки кампаний, напоминания, реактивация, опросные звонки. Достаточно одной синхронизации в день.
3. 3Смешанная модельСамый используемый вариант: критические события через webhook, остальное ежедневным пакетом. И проще, и снижает нагрузку.

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

Разделение работы с командой

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

• Какие сегменты уходят агенту: обычно повторяемая и объёмная часть
• Какие остаются менеджерам: крупные клиенты, идущие переговоры, особые случаи
• Лид, которому звонит агент, уходит из списка менеджера — и наоборот
• Когда после звонка лид переходит менеджеру, контекст идёт вместе с ним
• Менеджер может забрать лид в любой момент, и это фиксируется в системе

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

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

Пилот: параллельная работа

Открывать интеграцию сразу на всю базу — самый дорогой путь. Работает параллельный пилот.

1. 1Выбирается один сегментОдин источник лидов или одна категория. Объём небольшой — десять-двадцать звонков в день.
2. 2Две недели работы параллельноАгент звонит, результаты пишутся в CRM, руководитель ежедневно проверяет эти строки. Цель не качество звонка, а подтверждение, что данные ложатся верно.
3. 3Составляется список ошибокКакое поле остаётся пустым, какой код выбирается неверно, какой формат номера создаёт проблему. Список обычно короткий и закрывается за день правок.
4. 4Затем объём увеличиваетсяДобавляется второй сегмент. Каждый новый проходит ту же двухнедельную проверку, но всё быстрее.

Типичные точки поломки

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

• Формат номера: один номер записан двумя способами и считается двумя клиентами
• Часовые пояса: время звонков и даты отчётов считаются в разных поясах
• Несовпадение полей: с одной стороны фиксированный список, с другой свободный текст
• Отсутствие повторных попыток: запрос не прошёл, данные потеряны, и никто не знает
• Тихий отказ: интеграция остановилась, а уведомления не пришло
• Объём: в пилоте десять строк работают, на реальном объёме упираются в лимит запросов

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

Измерение

У интеграции должны быть собственные показатели, потому что её отказ обычно происходит тихо.

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

Вторая строка — самая простая и самая полезная проверка. Если две цифры не сходятся, данные теряются в интеграции. Сам список полей приведён в материале поля CRM для звонков.

Подключение на стороне Vexvon

Вот что сторона Vexvon даёт для интеграции.

• Кампания звонков строится фильтром CRM — целевой список отдельно не готовится
• Preview до запуска показывает, до скольких удастся дойти и какие строки без номера
• В сценарии задаются извлекаемые поля, и результат пишется в CRM полями
• Инструменты агента бывают трёх видов: статические ответы, встроенные инструменты и webhook-инструменты, обращающиеся к собственным системам компании
• У лидов хранится связь с дубликатом, а при импорте CSV выполняется проверка
• Собственные номера компании хранятся отдельным списком и лидами не считаются
• Через триггеры возможна передача во внешние системы — уведомление в Telegram или лид в Bitrix24

Общее описание архитектуры интеграций — на странице интеграций, а ответ на тот же вопрос со стороны чата — в материале интеграция чат-бота через API и webhook.

Первый шаг

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

Чтобы составить план подключения для ваших систем, напишите нам.