ИИ-агент в amoCRM: что настроить, чтобы он реально продавал, а не просто звонил

Из каких сущностей собрана amoCRM и что в них должен писать голосовой ИИ-агент

amoCRM построена вокруг 4 сущностей, и голосовой ИИ-агент трогает каждую после единственного звонка: контакт с телефоном и историей касаний, сделка как конкретная попытка продать, воронка и этап, показывающие стадию продажи. Разговор занимает 1-2 минуты, а настройка этих сущностей - недели.

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

Общую схему обмена данными между роботом и CRM и базовый список полей карточки после звонка мы разбирали в материале про интеграцию голосового робота с CRM - повторять её здесь не будем, разберём именно amoCRM. Если у вас Битрикс24, а не amoCRM - устройство сущностей и API другое, отдельный разбор смотрите в статье ИИ-агент в Битрикс24.

Правило поиска дубля по номеру телефона перед созданием контакта

Перед поиском дубля российский номер приводят к единому формату: +7 и 8 в начале считаются одним номером, пробелы и скобки удаляются.

Механика простая, но в ней есть детали, которые обычно пропускают на старте. Номер телефона нужно привести к единому формату перед сравнением - без пробелов, скобок и дефисов, с одинаковой обработкой кода страны: +7 и 8 в начале российского номера - один и тот же номер. Если агент сравнивает номер «как есть», контакт с записями «+7 999...» и «8 999...» будет считаться разным человеком, и дедупликация формально настроена, а фактически не работает.

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

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

Отдельно стоит проговорить пограничные случаи до запуска: общий номер на несколько сотрудников компании, семейный телефон, с которого звонят разные люди. Готового универсального правила здесь нет - его нужно один раз обсудить с руководителем отдела продаж и зафиксировать письменно.

Кто и как решает, какой ответ клиента двигает сделку на следующий этап

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

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

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

Матрицу нужно фиксировать письменно и версионировать: если стадии воронки меняются в середине активной кампании, сравнение «было / стало» по прежним отчётам перестаёт быть корректным. Изменение матрицы - решение руководителя отдела продаж, а не правка, которую интегратор вносит по звонку от одного менеджера.

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

Дополнительное поле в amoCRM - это структура: у него 5 типов (текст, список, дата, число, флажок), по нему можно фильтровать, строить отчёт и настраивать автоматизацию. Примечание - только текст для чтения. В поля идёт всё, что попадает в отчёт или триггер, в примечание - остальное.

Дополнительное поле в amoCRM - это структура: у него есть тип (текст, список, дата, число, флажок), и по нему можно фильтровать, строить отчёт и настраивать автоматизацию. Примечание - это история карточки: текст, который можно прочитать, но нельзя надёжно посчитать. Правильное разделение простое - в поля идёт всё, что должно попасть в отчёт или триггер; в примечание - всё, что нужно прочитать человеку, но не считать машиной.

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

Расшифровку целиком и ссылку на запись разговора, наоборот, в поле класть не нужно - для этого в amoCRM есть примечание, причём именно как отдельный тип записи «звонок», а не текстовая заметка, вставленная интеграцией вручную. Если телефония подключена к amoCRM корректно, такое примечание хранит длительность звонка и запись рядом с расшифровкой, и менеджер может прослушать спорный момент, а не полагаться на пересказ агента.

Нужен разбор под вашу нишу? Оставьте заявку или напишите в Telegram - ответим с расчётом по вашей базе.

Что делать, если менеджер уже перевёл сделку руками

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

Базовое правило простое: автоматика никогда не откатывает сделку назад по воронке, если фактический этап уже дальше того, что предлагает результат звонка агента. Если менеджер продвинул сделку вперёд, а звонок агента формально говорит о более раннем статусе, приоритет - у действия человека; агент в этом случае только дописывает примечание с расшифровкой разговора, не трогая этап.

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

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

Задачи с ответственным и сроком, теги: как настроить, чтобы не терялось

Задача в amoCRM работает только при 3 условиях: конкретный текст, конкретный ответственный и конкретный срок. «Перезвонить» без уточнения откладывается, а «перезвонить в 15:00, клиент просил обсудить рассрочку» выполняется за минуту без прослушивания записи.

Ответственного нельзя определять «по факту, кто первым увидел». Если у контакта или сделки уже есть закреплённый менеджер в amoCRM, новая задача от голосового ИИ-агента должна идти на него - агент не переназначает чужих клиентов. Если ответственного ещё нет, нужно заранее согласованное правило распределения: по очереди между дежурными менеджерами, по сегменту базы или по источнику лида. Без этого правила тёплые контакты копятся в общем списке ничьими - каждый предполагает, что задачу возьмёт кто-то другой.

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

Вебхуки и работа через REST API: как ИИ-агент технически говорит с amoCRM

Связка голосового ИИ-агента и amoCRM держится на 2 механизмах, работающих в разные стороны: REST API позволяет внешней системе читать и записывать контакты, сделки, задачи, примечания и поля, а вебхуки - это уведомления, которые amoCRM сама шлёт при наступлении события.

Вебхуки работают в обратную сторону. Это уведомления, которые amoCRM сама отправляет во внешнюю систему при наступлении события - например, когда в CRM появилась новая сделка или сделка попала в нужный этап воронки. Для голосового ИИ-агента это удобнее, чем постоянно опрашивать CRM «а не появилось ли что-то новое»: вебхук приходит сразу, и агент может начать звонок в течение секунд после появления заявки, а не по расписанию раз в несколько минут.

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

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

Чек-лист перед стартом интеграции и типичные ошибки настройки

До первого звонка по реальной базе согласуют 7 пунктов: правило поиска дубля по телефону, матрицу «ответ клиента → этап воронки», список полей и их типы, правило назначения ответственного, словарь тегов, права технического пользователя API и правило при ручном изменении сделки.

Чек-лист: что согласовать до старта интеграции

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

Типичные ошибки настройки amoCRM под голосового ИИ-агента

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

• Одна воронка на все сценарии. Входящие обращения, исходящий обзвон холодной базы и реактивация старых контактов идут через один и тот же пайплайн - сравнить эффективность сценариев между собой становится невозможно.
• Интеграционному пользователю выданы права администратора. Быстрее на старте, но лишний риск для безопасности и для случайного изменения чужих данных без явной необходимости.
• Нет флага ручного вмешательства. Автоматическое обновление от агента иногда откатывает то, что менеджер только что поправил сам, и никто не может объяснить, почему сделка «прыгает» между этапами.
• Ответственный назначается по факту. Правило распределения задач не согласовано заранее, тёплые лиды повисают в общем списке и достаются тому, кто случайно открыл его первым.
• Поля заведены, но не подключены к отчётам. Данные аккуратно копятся в дополнительных полях сделки, а руководитель отдела продаж по-прежнему считает конверсию вручную в таблице, потому что отчёт поверх этих полей никто не настроил.

Частые вопросы про ИИ-агента в amoCRM

Собраны 6 вопросов про ИИ-агента в amoCRM: как он ищет дубль контакта по номеру, кто решает, какой ответ двигает сделку по воронке, что писать в поля, а что в примечание, и как агент ведёт себя, если менеджер уже перевёл сделку руками.