ИИ-агенты, которые делают работу

Квалификация заявки: агент читает первое сообщение от клиента, определяет параметры — бюджет, регион, продукт, ставит тег и переводит сделку на нужный этап в amoCRM или Bitrix24, без того, чтобы менеджер вручную разбирал каждую заявку.

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

Отчёт голосом: агент собирает цифры из CRM и аналитики за день или неделю и присылает руководителю отдела продаж голосовое сообщение в Telegram или MAX — короче, чем открывать дашборд, и точнее, чем пересказ менеджера на планёрке.

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

Агент работает через API amoCRM или Bitrix24: читает поля сделки, историю переписки, ставит задачи, меняет этап воронки. Это не отдельное приложение, которое нужно открывать параллельно с CRM, — результат его работы виден в той же карточке сделки, где менеджер и так работает.

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

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

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

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

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

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

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

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

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

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

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

Если задача проще — принять заявку, задать пару уточняющих вопросов и завести сделку, — хватит бота со сценарием: разработка чат-ботов.