Как проверить ИИ-квалификацию лида до передачи менеджеру

Что считать качественно квалифицированным лидом

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

Один из распространённых подходов — BANT: бюджет, полномочия, потребность и сроки. Salesforce Trailhead описывает эти четыре области как ориентиры для разговора. Это не обязательная анкета и не правило требовать ответ на каждый пункт сразу. Особенно в первом сообщении вопрос о точном бюджете может быть преждевременным.

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

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

Начните с потребности, а не с формы

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

Короткий сценарий может выглядеть так:

— Клиент: «Интересует ИИ для продаж».

— Агент: «Подскажите, какую задачу в продажах хотите закрыть в первую очередь: отвечать на входящие обращения, собирать данные по заявке или передавать готовый контекст менеджеру?»

— Клиент: «Собирать заявки, менеджеры тратят время на одни и те же вопросы».

— Агент: «Понял. Из какого канала чаще приходят заявки и кто затем работает с ними?»

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

Ведите карточку «факт — неизвестно — следующий вопрос»

Самая частая ошибка в передаче — смешать слова клиента и вывод агента. Менеджер читает «нужна автоматизация срочно» и не понимает: клиент назвал срок или агент так интерпретировал тон сообщения? Разделение на три поля снимает эту проблему.

Факт. Только то, что клиент сообщил или подтвердил.

Неизвестно. Поле, которое ещё не обсуждали; не ставьте вместо него предположение.

Следующий вопрос. Один вопрос, который наиболее заметно улучшит понимание заявки.

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

Передавайте лид по триггерам, а не по ощущению

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

Полезно заранее записать триггеры передачи. Они делают поведение агента предсказуемым для клиента и команды:

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

Вместе с триггером менеджер должен получить не пересказ «клиент тёплый», а карточку и историю существенных сообщений. В ИИ-команде Smokva можно организовать внутреннее поручение на разбор заявки: назначить роль, приложить контекст и указать, что именно нужно подготовить. Доступные роли и права стоит проверить в своём кабинете до описания процесса команде.

Дайте агенту промпт со стоп-условиями

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

Роль: вы помощник первичной квалификации входящих заявок.

>

Цель: понять задачу клиента и передать менеджеру подтверждённый контекст.

>

Порядок работы:

1. Сначала уточните рабочую задачу клиента одним коротким вопросом.

2. Затем по необходимости проясните канал, участников решения, срок или бюджетный ориентир.

3. После каждого ответа обновляйте карточку: «факт», «неизвестно», «следующий вопрос».

4. Не требуйте точный бюджет в первом сообщении.

>

Стоп-условия:

— клиент просит менеджера;

— клиент спрашивает об индивидуальной цене, договоре или оплате;

— для ответа нет подтверждённых материалов;

— клиент не хочет продолжать уточнение.

>

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

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

Проверьте сценарий на десяти учебных заявках

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

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

Проверяйте ответы по простому листу:

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

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

Частые ошибки

Считать отсутствие бюджета отказом. Бюджет может не обсуждаться на раннем этапе. Зафиксируйте это как неизвестное и сначала проясните потребность.

Задавать список вопросов одним сообщением. Клиенту легче ответить на один вопрос, связанный с его последней репликой.

Приписывать намерение. «Срочно», «готов купить», «лицо, принимающее решение» — не факты, пока клиент этого не подтвердил.

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

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

Три коротких вопроса

Нужно ли собрать все поля BANT до передачи? Нет. Передавайте лид при явном запросе клиента, важном вопросе или подтверждённой задаче; неизвестные поля отмечайте честно.

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

Что делать, если агент не знает ответа? Не додумывать. Зафиксировать вопрос и передать менеджеру контекст через настроенный маршрут. Если передачи нет, назвать доступный способ связи.