Как ИИ-агент квалифицирует заявки в amoCRM

Что агент видит на входе

Заявка приходит в amoCRM с разным набором данных в зависимости от источника: с сайта — текст из формы и UTM-метки, из MAX или мессенджера — переписка, с рекламы Яндекс.Директа — быстрая заявка почти без текста. Агент забирает всё, что есть, а если данных мало — задаёт один-два уточняющих вопроса прямо в переписке: что за задача, какой бюджет, есть ли сейчас CRM. Это не форма с обязательными полями — клиент отвечает свободным текстом, агент разбирает его.

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

Как это превращается в поля сделки

Разбор текста — это половина работы. Вторая половина — довести результат до карточки сделки так, чтобы менеджер открыл её и за пять секунд понял, с чем имеет дело. Агент проставляет теги (например, «целевой», «отказ — не наш профиль», «нужна консультация по цене») и заполняет кастомные поля: сфера бизнеса, ключевая задача клиента своими словами, источник контекста. Это делается через API amoCRM — тот же принцип, что и в настройке amoCRM под конкретный процесс продаж: воронка бесполезна, если поля в карточке никто не читает или они заполнены вручную через раз.

Маршрутизация — отдельный шаг после квалификации. Целевая заявка со внятным запросом уходит менеджеру сразу, с кратким саммари вместо сырой переписки. Нецелевая — в отдельный статус воронки с автоматическим вежливым отказом или переадресацией (например, если человек ищет не CRM, а просто консультацию по рекламе). Спам и боты отсекаются тем же слоем и не долетают до человека вообще. Никакого «менеджер разберётся» — если сортировка не автоматизирована, она не работает стабильно, потому что зависит от того, кто именно сегодня на смене и насколько он внимателен после двадцатой заявки за день.

Антипаттерн: автоответчик по ключевым словам

Частая ошибка — брать «умного бота» на связках триггеров по ключевым словам вроде «если в сообщении есть слово „цена“, отправить прайс». Это работает ровно до первого нестандартного сообщения. Клиент пишет «сколько стоит подключить, если у нас уже есть Битрикс и три филиала» — и бот либо присылает шаблонный прайс мимо контекста, либо зависает, потому что фраза не совпала ни с одним триггером.

Разница между таким автоответчиком и агентом — в том, что агент работает не по совпадению строк, а по смыслу сообщения целиком, с учётом истории переписки и данных из CRM (были ли уже сделки, что клиент искал раньше). Он может понять, что «уже есть Битрикс» — это не про отказ, а про миграцию, и это меняет квалификацию сделки на «целевой, но сложный кейс». Ключевые слова так не умеют в принципе — это плоская логика, а квалификация лида нелинейна: два одинаковых слова в сообщении могут значить противоположные вещи в зависимости от контекста.

Квалификация как событие в аналитике

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

Данные и 152-ФЗ

Переписка с клиентом и данные сделки — персональные данные, и хранить их нужно там же, где хранится вся CRM: в контуре, подчинённом 152-ФЗ. Для разбора текста я использую модели, совместимые с этим требованием — YandexGPT, GigaChat или self-hosted модель на своём сервере, — а не отправляю переписку клиента в зарубежный API без основания. Это не идеологический выбор, а условие, при котором квалификацию вообще можно эксплуатировать на реальных заявках, а не только в демо.

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