Диспетчеризация ИИ-лидов в amoCRM: архитектура двух ботов-агентов

# Ночь — боту, а утро человеку: как архитектура двух Salesbot закрывает слепые зоны CRM

Внедрение искусственного интеллекта в работу отдела продаж часто останавливается на этапе чат-бота, не решающего ключевые проблемы менеджеров. Описанный кейс демонстрирует, как две автоматизированные ветки в amoCRM — «Раздатчик» и «Идентификатор» — замыкают контур обслуживания: от первичного контакта до оперативного реагирования человека.

Проблема «слепой зоны» и создание дублей

При работе с клиентами, заведенными вручную до внедрения ИИ, возникает критический разрыв в логике. Стандартная система интеграции не может распознать существующего клиента, так как у него отсутствует связка (соотношение между чатом в мессенджере и сделкой в CRM) в Redis. Результатом работы алгоритма Is New User? становится открытие новой сделки для клиента, который уже был в базе, что ведет к дублям и потере контекста.

Чтобы устранить эту проблему, внедрен Salesbot «Идентификатор». Этот агент работает в ночное время и по первому сигналу от старого контакта инициирует проверку истории. Система запускает параллельные потоки: вебхук от amoCRM и входящий поток от Instagram Graph API. Поскольку запись в Redis идемпотентна, независимо от того, какой поток пришел первым, создается связка на основе уникального chatId. Это позволяет ИИ-агенту в дневное время опознавать клиента, видеть его прошлые покупки и не запрашивать базовую информацию заново.

Архитектура обновления сделки и роли менеджера

Когда диалог заканчивается (Is Dialog Finished?), данные передаются в CRM через ноду n8n. Критически важным элементом является маппинг данных: вместо того чтобы менеджеру самому открывать историю переписки в мессенджере, все структурированные данные (анкета, сфера, контакт, вердикт ИИ) заносятся в кастомные поля карточки сделки.

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

Salesbot «Раздатчик»: приоритизация задач

Достаточно зафиксировать данные в карточке, но это не означает их проработку. Чтобы избежать эффекта «слепой зоны» для менеджера, который может отложить работу до перерыва, используется внутренний механизм amoCRM Salesbot «Раздатчик».

Алгоритм его работы заключается в четырех шагах: 1. Сканирование: Агент проверяет наличие системных тегов (например, TASK:NEED_MANAGER_CALL) и заполненности поля «Вердикт ИИ». 2. Оценка: Наличие вердикта и данных о клиенте переводит сделку в приоритетную категорию. 3. Постановка задачи: Вместо разового уведомления, которое легко проигнорировать, создается полноценная задача в разделе «Мои задачи» с жестким дедлайном. 4. Контроль: Менеджер видит задачу в списке с таймером, что исключает возможность пропустить горячий лид.

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

Техника «стоп-кран»: вмешательство человека

В боевой системе важно предусмотреть механизм передачи управления от бота к человеку в любой момент. В описанной архитектуре это решается на двух уровнях.

Первый уровень — проверка перед отправкой сообщения (нода Go or STOP?). Система сканирует связку сделки и, если обнаружено вмешательство, отменяет отправку и очищает буфер сообщений. Это гарантирует, что клиент не получит двойной ответ от разных сущностей.

Автор упоминает перспективу второго уровня — создание скрытого чекбокса «Остановить ИИ» в карточке сделки, который будет блокировать работу агента в будущем. На данный момент основным триггером для остановки считается смена этапа сделки на статус «взят в работу».

Итоги внедрения

По результатам эксплуатации архитектуры, было отмечено отсутствие дублей сделок благодаря модулю «Идентификатор». Статистика показывает, что задача «Связаться с клиентом (Лид от ИИ)» ставится в 100% случаев для лидов с вердиктом ИИ. Временной разрыв между началом диалога и реакцией менеджера минимизирован, что привело к оценке снижения рутинной работы команды на 40%. Проект продолжает развитие, и в ближайших этапах планируется разбор сложного бага, связанного с расходованием токенов языковыми моделями.

Глоссарий терминов

* Redis-ключ связки: Хранилище данных, в котором создается уникальная пара между идентификатором чата в мессенджере и ID сделки в CRM для быстрого опознавания клиента. * Идемпотентность: Свойство операции, при котором повторное выполнение той же команды (например, запись в базу данных) дает тот же результат, что и первое выполнение. В данном случае гарантирует, что дубликат сделки не создастся, даже если два источника данных придут одновременно. * Вебхук (Webhook): Технология, позволяющая сервису (например, Instagram API) автоматически отправлять данные (сообщения, изменения) в другой сервис (n8n) по факту наступления события. * Диспетчеризация: Процесс автоматического распределения полученных лидов конкретным исполнителям на основе заданных правил и приоритетов.