ИИ-квалификатор заявок: критерии отбора, передача менеджеру и проверка ошибок

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

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

Какие признаки собрать до сборки бота

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

Основа анкеты может опираться на BANT: бюджет, участники решения, потребность и срок. Но посетитель не обязан сразу раскрыть бюджет или представляться директором. Ответ «собираю варианты для руководителя» означает стадию покупки, а не повод закрывать заявку.

Сегмент	Полезные уточнения	Что нельзя выводить автоматически
B2B-услуги	Задача, объём, текущий процесс, срок обсуждения	Клиент без указанного бюджета не сможет оплатить услугу
Оптовые продажи	Номенклатура, партия, регион доставки, документы	Маленький первый заказ исключает дальнейшее сотрудничество
Обучение и бытовые услуги	Цель, подходящий формат, удобное время	Сложный вопрос клиента можно заменить навязанной продажей

От разговора к объяснимому статусу

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

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

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

Как устроить интеграцию

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

До покупки отдельного конструктора проверьте возможности своей CRM: в ней уже могут быть средства автоматизации и ИИ. Конструктор вроде Salebot или отдельный интеграционный слой выбирают по нужным каналам и событиям. YandexGPT, GigaChat либо другую разрешённую модель сравнивают на ваших обезличенных диалогах, без заранее назначенного победителя.

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

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

Пилот примерно на две недели

1. Первые дни: составить критерии, разобрать старые обращения, назначить владельца процесса.
2. Затем: написать вопросы по одному за сообщение, добавить выход к человеку и корректную обработку неопределённости.
3. До подключения клиентов: проверить синтетические диалоги, дубли, отказ CRM, противоречивые ответы и смену темы.
4. На ограниченном потоке: менеджер проверяет каждый статус, особенно отрицательный.
5. По завершении: сопоставить полноту анкет, нагрузку и потерянные целевые обращения; решить, стоит ли расширять пилот.

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

Экономика и метрики

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

Дополнительную выручку считайте отдельно, по фактическим оплатам сопоставимых групп. Рост доли «горячих» в CRM может объясняться изменением правил, а не улучшением продаж. Отслеживайте время содержательного ответа, завершение анкеты, ошибочные отказы, время сотрудника и конверсию всех входящих в оплату.

Данные и обслуживание

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

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

АГЕНСТВО ИИ TRUE поможет разобрать вашу квалификацию. Для обсуждения пригодятся обезличенные обращения и текущие причины отказов.