ИИ-менеджер для входящих заявок и продаж

Собрал для Сергея ИИ-менеджера, который ведет входящую заявку от первого вопроса до запроса счета.

Клиент может задать вопрос, уйти в сторону, вернуться к заявке, прислать данные и в конце попросить счет. Агент должен понимать не только последнюю фразу. Ему нужно помнить, что уже известно, на каком этапе находится разговор, что записать в заявку и когда передать диалог человеку.

Задача

Обычный бот умеет вежливо ответить на отдельный вопрос и при этом потерять саму продажу.

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

Нужно было собрать ИИ-менеджера, который:

• отвечает по базе знаний и не выдумывает уверенный ответ, если нужного факта нет;
• собирает имя, телефон, даты, состав и другие вводные прямо по ходу разговора;
• удерживает текущий этап продажи, даже если клиент меняет тему;
• обновляет заявку, когда появляются новые данные;
• распознает готовность к счету и передает разговор менеджеру;
• прекращает автоматические ответы после передачи человеку.

Продажа с памятью и понятными правилами

У каждого диалога есть явный этап:

1. вопросы и консультация;
2. сбор заявки;
3. готовность получить счет;
4. передача человеку.

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

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

Три рабочих инструмента агента

За разговором стоят три понятных действия.

• Найти подтвержденный ответ в базе знаний.
• Обновить данные заявки в CRM.
• Передать разговор менеджеру вместе с выжимкой и причиной.

База знаний построена на PostgreSQL и pgvector. В проверках близкие по смыслу вопросы про размещение с питомцем возвращали один и тот же корректный факт, а бессмысленный запрос не превращался в уверенную выдумку.

Архитектура не привязана к одному мессенджеру. В проектном контуре предусмотрены Телеграм, ВК, WhatsApp и Chatwoot, а текст, расшифровка голоса, данные из фото и файлов приводятся к одному формату перед агентом. Доказательная проверка этого кейса ограничена маршрутами Телеграма и ВК.

Клиент меняет тему — заявка не начинается заново

Разговор о покупке редко идет по идеальному скрипту. Клиент может назвать даты, затем спросить про условия, позже вернуться к составу группы и только после этого оставить телефон.

Агент читает сохраненный контекст и текущий этап. Уже собранные поля остаются в заявке, а новый вопрос не сбрасывает клиента в начало воронки.

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

Если клиент замолчал

Не каждый диалог заканчивается за один подход. Если человек остановился после нескольких ответов, полезные данные не должны исчезнуть вместе с паузой.

В проверенном сценарии паузы собранные поля сохраняются для следующего шага. При этом пустая заявка без полезных данных в CRM не отправляется.

Менеджер получает не мусорную карточку, а только тот контакт, по которому уже есть с чем работать.

Передача без двойных ответов

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

После этого включается человеческий режим. В отдельной проверке следующее сообщение клиента уже не запускало ИИ-ответ.

У разговора остается один владелец. Менеджеру не нужно перечитывать всю историю, а клиент не получает параллельные ответы от человека и агента.

Сколько стоит модельный путь до запроса счета

Для экономики я зафиксировал один сценарий из четырех сообщений:

1. клиент описал нишу и запрос на ИИ-менеджера;
2. назвал имя, роль и каналы;
3. уточнил задачи и оставил телефон;
4. подтвердил готовность оплачивать и попросил выставить счет.

Модель сохранила данные через CRM-инструмент и в финале вызвала передачу менеджеру. Из-за цикла с инструментами получилось восемь модельных обращений.

По официальному тарифу Gemini 3 Flash Preview и курсу ЦБ на дату замера работа модели стоила 1,6859 ₽. В публичном кейсе использую консервативную верхнюю границу — не больше 1,69 ₽.

Это стоимость только модели в фиксированном сценарии. Она не включает сервер, n8n, CRM, сообщения каналов, сопровождение и работу менеджера после передачи. Это также не средняя цена любого реального диалога.

Что проверено

• полный маршрут агента от входящего сообщения до ответа;
• переходы между вопросами, сбором заявки и готовностью к счету;
• сохранение имен, телефона, дат и состава в тестовом Телеграм-контуре;
• поиск по базе знаний на близких по смыслу и нерелевантных запросах;
• передача в CRM в проверочных маршрутах Телеграма и ВК;
• передача выжимки, причины, текущего этапа и собранных данных;
• остановка ИИ после включения человеческого режима;
• сценарий паузы с частично собранной заявкой.

Результат

Получился ИИ-менеджер, который ведет не отдельный ответ, а весь путь клиента:

• консультирует по подтвержденной базе;
• собирает заявку без отдельной анкеты;
• помнит уже полученные вводные;
• удерживает этап продажи;
• распознает момент готовности к счету;
• передает менеджеру готовый контекст;
• после передачи выходит из диалога.

Счет и оплату принимает человек. ИИ берет на себя основную работу до этого момента — поддерживает разговор, превращает переписку в структурированную заявку и передает ее тогда, когда менеджеру уже есть с чем работать.

Граница публичного результата

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

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