Регламент квалификации входящих заявок: как формализовать, чтобы автоматизировать

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

Заказчик - B2B-консалтинг для премиум-сегмента. Ниша узкая, поток заявок невысокий: до 20 заявок в месяц. Источники - сайт, рекомендации, рассылки.

На каждую новую заявку менеджер тратил 15-30 минут. За эти полчаса он:

• Изучал данные из карточки заявки (имя, телефон, почта, компания).

• Шёл в открытые источники: специализированные реестры, отраслевые индексы, общий поиск.

• Собирал картину: кто пришёл, какую роль занимает, в какой структуре, какие признаки.

• Относил клиента к одному из четырёх уровней по внутренней рубрике (премиум / стандартный / малый / отказ).

• Записывал в карточку: текстовый разбор в примечание, уровень - в специальное поле контакта.

В цифрах: до 20 заявок в месяц × 15-30 минут = 5-10 часов работы менеджера в месяц на одну только квалификацию. Поток небольшой, но работа без творческой составляющей: менеджер не разговаривал с клиентом, не продавал, не вёл сделку - сидел и заполнял карточку по чек-листу. И главное - пока менеджер заполнял, клиент ждал звонка. В премиум-сегменте задержка критична: если конкурент перезвонил раньше, сделка ушла.

До технологий - три условия, без которых ничего не получится.

1. Описанный регламент квалификации. У заказчика регламент был и включал:

• Чёткие критерии каждого уровня: что делает заявку «премиум», что «стандартом», что «малым».

• Список источников, в которых имеет смысл искать сигналы (специализированные реестры, отраслевые базы).

• Перечень признаков целевого архетипа клиентов: какие должности, в каких структурах, какие маркеры.

• Правила для пограничных случаев: что делать, если данные неполные, как трактовать непубличность.

Без регламента автоматизация невозможна - модель не догадается о критериях, которые в голове у опытного менеджера.

2. Структурированное хранение данных. Заявки и контакты должны лежать в CRM с понятными полями. Если поля произвольные, заполняются как попало, у каждого менеджера своя структура - сначала порядок в данных, потом всё остальное.

3. Специальное поле под результат квалификации. Нужно куда писать результат. У заказчика на контакте было поле «Тип клиента» с фиксированным списком значений (премиум / стандартный / малый / отказ). Если поля нет - добавляется в CRM руками за минуту.

Без этих трёх вещей переход на автоматизацию начинается не с программирования, а с организационной работы внутри компании.

Что сделали технически

Очень коротко, без деталей.

Сценарий ловит событие «новая заявка сменила этап» из CRM. Достаёт данные карточки. Отправляет на разбор в языковую модель с протоколом поиска и явным списком признаков. Получает разбор и относит клиента к одному из четырёх уровней. Записывает результат обратно в карточку.

Время одного прогона - порядка 3 минут. Расход токенов обходится в копейки на масштабе компании.

Заказчик собрал контрольный набор из 8-12 заявок, по которым менеджер уже принял свой вердикт. На наборе сравнивали до и после.

• На непубличных премиум-клиентах автомат ранее ошибался в 4 случаях из 8. После доводки - в 1 из 8.

• Стоимость одного прогона - несколько рублей. На потоке заявок не статья расходов.

• Менеджер перестал тратить время на типовую квалификацию. Смотрит только спорные случаи, где автомат сам помечает «не уверен».

В часах работы:

• Раньше: 5-10 часов в месяц на квалификацию (до 20 заявок × 15-30 минут).

• Сейчас: ~1 час в месяц на пограничные случаи и контрольную выборку.

• Освободившееся время менеджер тратит на разговор с клиентом - на этап, который автоматизировать нельзя.

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

Что было сложно и о чём предупреждаем

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

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

Сценарий перекладывается практически на любую CRM с открытым программным интерфейсом - Битрикс24, RetailCRM, amoCRM, HubSpot. Принцип одинаковый: вход - событие, обработка - две ИИ-ноды с валидатором, выход - запись в карточку.

Хорошо ложится в нишах с дорогими сделками, где имеет значение глубина квалификации:

• B2B-консалтинг.

• Юридические и налоговые услуги среднего и верхнего сегмента.

• Финансовые услуги (управление активами, кредитование среднего бизнеса).

• Корпоративные IT-услуги, интеграции.

• Любая ниша с длинным циклом сделки, где сегментация заявок на входе влияет на дальнейший процесс.

Менее применимо в массовом сегменте, где квалификация заявок и так формальна - там автоматизация даёт меньший эффект в часах работы.

Открытый шаблон

Каркас сценария на 20 нод выложен в открытый доступ. Промпт под целевую аудиторию заказчика закрыт (под NDA), но промпт и не повторно используемая часть: критерии у каждого заказчика свои.

Зеркала репозитория:

• GitHub

• GitVerse

• GitFlic

Что в шаблоне: структура узлов, вызовы программного интерфейса к CRM, логика валидатора, конфигурация HTTP-запросов и плейсхолдеры под промпты.

Для разворачивания у себя потребуется: сценарный движок n8n (любой хостинг), доступ через программный интерфейс к CRM, ключ доступа к программному интерфейсу языковой модели, и описанный регламент квалификации.

Если есть вопросы по применимости в вашей нише - пишите в комментариях, отвечу.