Можно ли доверить AI квалификацию B2B-лидов?

AI особенно силён там, где квалификация требует читать текст заявки, смотреть сайт компании, определять отрасль, роль, use case и сопоставлять данные с ICP. Такой процесс быстрее простого ручного triage. Но модель не должна сама придумывать критерии «хорошего» клиента. Их задаёт бизнес, а качество AI проверяется на размеченной истории. Полезна архитектура, где модель выдаёт факты, score, уверенность и объяснение, а low-confidence или high-value лиды эскалируются человеку.

У вопроса «Можно ли доверить AI квалификацию B2B-лидов?» есть практический смысл только тогда, когда он связан с наблюдаемым решением. Не стоит делать вывод по одному признаку. Например, сигнал «большой поток входящих обращений;» важен в связке с «менеджеры тратят много времени на первичный ресёрч;», а результат разумно проверять через precision квалификации;, recall ценных лидов; и false rejection rate;. Такой подход защищает от локальной оптимизации: показатель может улучшиться, а коммерческий результат — нет. Поэтому сначала фиксируется baseline, затем изменение процесса, и только потом сравнивается downstream-эффект.

• большой поток входящих обращений;
• менеджеры тратят много времени на первичный ресёрч;
• часть полей можно извлечь только из текста или сайта;
• важна очень быстрая маршрутизация;
• есть история прошлых лидов и исходов;
• критерии MQL/SQL уже согласованы.

1. Опишите ICP и критерии дисквалификации.
2. Соберите размеченную выборку прошлых лидов.
3. Разделите факты, которые можно получить автоматически, и оценочные решения.
4. Настройте модель на structured output с confidence.
5. Проверьте precision/recall на истории.
6. В production оставьте эскалацию крупных и неоднозначных случаев.

Входящая заявка содержит только имя, телефон и фразу «нужна автоматизация». AI по домену компании определяет отрасль, масштаб, находит описание производства, извлекает возможный use case и предлагает несколько уточняющих вопросов. Менеджер получает не пустую карточку, а подготовленный контекст — но именно он подтверждает opportunity.

• Высокая уверенность, низкий риск. Можно автоматически маршрутизировать. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• Низкая уверенность. Передавать человеку без жёсткого решения. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• Крупный стратегический аккаунт. Human review обязателен независимо от score. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.
• Нет согласованных MQL/SQL. Сначала решите бизнес-логику, потом автоматизируйте. Это не автоматический диагноз, а рабочая гипотеза: её нужно подтвердить данными конкретного сегмента, канала или когорты.

• precision квалификации;
• recall ценных лидов;
• false rejection rate;
• speed-to-lead;
• доля автоматической маршрутизации;
• SQL-rate;
• время менеджера на triage.

Сами по себе precision квалификации; и recall ценных лидов; ещё не доказывают эффект. Их нужно сравнивать с исходным уровнем, учитывать сегмент и смотреть, что происходит дальше по процессу. Если локальная метрика улучшается, а время менеджера на triage. ухудшается или не меняется, это повод проверить, не оптимизируется ли система на удобный, но слабый proxy-показатель.

• обучать модель на субъективных статусах CRM;
• автоматически отказывать по одному признаку;
• не хранить исходные факты и объяснение;
• смешивать fit и intent в один непрозрачный score;
• не проверять drift после изменения рынка.

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

• Что именно должно измениться, если ответ на вопрос «Можно ли доверить AI квалификацию B2B-лидов?» внедрён правильно?
• Какой baseline по показателю «precision квалификации;» у нас есть сейчас?
• Кто владеет следующим действием и где оно фиксируется?
• Как мы отличим улучшение процесса от случайной волатильности?
• Какой сигнал заставит остановить или пересобрать гипотезу?

1. Зафиксировать текущий процесс и исходные данные до изменений.
2. Проверить два наиболее явных сигнала: «большой поток входящих обращений;» и «менеджеры тратят много времени на первичный ресёрч;».
3. Внедрить первые 1–2 шага из плана, не меняя одновременно всю систему.
4. Через согласованное окно сравнить precision квалификации;, recall ценных лидов; и downstream-результат.

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