Менеджер жмёт play в карточке — значит, интеграции с CRM нет

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

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

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

Что считать интеграцией голосового агента с CRM и телефонией

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

Телефония. Агент должен сидеть на вашем номере, а не на подменном: Mango Office, UIS, Телфин, Zadarma, Asterisk, ОАТС Билайн, МТС Exolve, Ростелеком. Вопрос поставщику один — агент подключается к вашей АТС или требует перенести номер к нему. Второй вариант означает, что переезд к другому подрядчику будет стоить смены номера.

Данные. Агент читает и пишет в Битрикс24, amoCRM, RetailCRM, МойСклад или 1С. Читает — чтобы узнать клиента до разговора. Пишет — чтобы менеджер не переспрашивал.

События. Звонок запускается не по кнопке, а по изменению в CRM: появилась заявка, сделка висит в статусе третий день, клиент не пришёл на встречу. Такое умеют и коробочные решения — Aimylogic позволяет запускать обзвон по событию в CRM, в маркетплейсе Битрикс24 есть Tomoru и TWIN.

Минимальный набор полей, при котором звонок можно не слушать

Это и есть критерий приёмки: менеджеру хватает карточки — интеграция сделана; тянется к плееру — нет.

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

Идентификация по номеру — до того, как создалась сделка

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

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

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

Почему агент должен писать в те же поля, что и люди

Соблазн понятный: завести отдельную группу «AI-полей», чтобы не смешивать с тем, что заполняют менеджеры. Через квартал это даёт два параллельных набора данных, две версии одного отчёта и спор о том, какая правильная.

Пишите в те же поля. Тогда любая метрика — конверсия из квалификации, доля дозвонов, средний чек по источнику — считается по всей воронке сразу, без сшивки; что именно считать, разобрано в материале про метрики голосового AI-агента. Разделять стоит не поля, а авторство записи: пометка «заполнено агентом» решает вопрос доверия к данным, не разрывая их.

Здесь же ломается миф «ИИ понимает как человек, ему достаточно свободного текста». Препринт τ-bench (Sierra и Принстон, arXiv:2406.12045): GPT-4o решает одну и ту же задачу с первого раза примерно в 61% случаев, но при восьми повторных прогонах успех по всем восьми падает ниже 25%. Свободное поле воспроизводится плохо, поле со списком значений и проверкой — хорошо. Поэтому формулировки итогов и ответы на частые вопросы держат в базе знаний агента, а не в промпте.

Где интеграция ломается

Четыре типовые точки отказа, все — организационные, а не технические.

Расхождение справочников. В CRM статус называется «Замер назначен», в сценарии агента — «выехал замерщик». Пока значения не сведены один в один, агент пишет в никуда или создаёт новые значения списка.

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

Ручные статусы. Если половина сделок висит в «В работе» месяцами, автоматика по событиям будет дёргать людей не вовремя. Сначала дисциплина в воронке, потом обзвон по событию.

Кастомные воронки. Сильно переписанный Битрикс24 или самописная CRM — это отдельный проект, а не «подключим за два дня». Спрашивайте про API и лимиты запросов до подписания.

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

Вывод

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