Почему часть звонков нельзя оценивать по критерию замера

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

Не каждый звонок можно оценивать по выбранному критерию.

Это звучит очевидно, но в проектах по контролю качества об этом часто забывают.

Берут критерий.
Запускают оценку.
Смотрят проценты.
Сравнивают менеджеров.

А потом выясняется, что часть звонков вообще не должна была попадать в расчёт.

Потому что в них выбранный этап объективно не требовался.

И если такие звонки всё равно оценивать, система становится несправедливой.

А несправедливая система быстро теряет доверие.

Гипотеза

После настройки критерия по замеру у нас была гипотеза:

если звонок достаточно длинный и клиент обсуждает покупку ворот, менеджер должен закрывать его на замер или фото/видео проёма.

В целом гипотеза логичная.

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

Но реальность оказалась сложнее.

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

И если бы мы требовали от менеджера закрывать на замер в каждом таком звонке, мы бы начали наказывать его за адекватное поведение.

Какие звонки нельзя оценивать одинаково

В проекте начали проявляться разные типы ситуаций, где критерий “закрыл на замер” не должен применяться.

1. У клиента ещё нет объекта или проёма

Человек может только строиться.

У него ещё нет финальных размеров.
Нет готового проёма.
Нет понимания сроков.
Нет конкретного решения по объекту.

Если в такой ситуации менеджер агрессивно закрывает на замер, это не сила продаж.

Это неадекватность этапу клиента.

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

2. Клиент просто мониторит рынок

Часть клиентов звонит не потому, что готова покупать.

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

В таком звонке замер может быть преждевременным.

Если клиент ещё не принял решение даже на уровне “я хочу покупать”, следующий шаг должен быть другим.

Например: зафиксировать ориентир, дать полезный материал, понять срок возврата к теме.

3. Клиент не подходит по продукту

Может выясниться, что ему нужен другой тип ворот или другой продукт.

Или компания не работает с таким запросом.

Или условия доставки, монтажа, комплектации не совпадают.

В таком случае закрывать на замер бессмысленно.

Менеджер должен корректно квалифицировать клиента и не тратить ресурс компании.

4. Клиент не подходит по географии или логистике

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

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

Сначала нужно понять, можем ли мы вообще решить задачу.

5. Клиент не конечный покупатель

Иногда звонит не тот, кто принимает решение.

Например, помощник, подрядчик, родственник, сотрудник, который просто собирает информацию.

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

Замер может быть уместен позже, но не всегда прямо в этом звонке.

Почему это было важно признать

Если бы мы не ввели логику “не применимо”, отчёт начал бы искажаться.

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

И менеджер был бы прав, когда спорил бы с оценкой.

Более того, он получил бы сильный аргумент против всей системы:

“Смотрите, нейросеть вообще не понимает, что происходит в звонке”.

И это разрушило бы доверие не только к одному критерию, но и к продукту в целом.

Поэтому нам было важно отделить:

плохое поведение менеджера

от ситуации, где критерий не должен применяться.

Это разные вещи.

Почему руководители часто пропускают эту проблему

Руководителю хочется простого отчёта.

Сколько звонков хороших.
Сколько плохих.
Кто лучше.
Кто хуже.
Где процент выше.
Где ниже.

Но продажи почти никогда не так просты.

Особенно в сложном продукте.

Если не учитывать тип клиента и стадию, менеджеры начнут играть в метрику.

Они будут закрывать на замер там, где это не нужно, просто чтобы получить балл.

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

Это одна из самых опасных ловушек в операционном управлении:

когда метрика начинает управлять поведением не в ту сторону.

Что увидел клиент

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

Закрытие на замер важно.

Но только в легитимных звонках.

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

Это помогло сделать разговор с командой честнее.

Мы не говорим:

“Всех закрывать на замер”.

Мы говорим:

“Если клиент подходит и следующий шаг уместен - закрываем. Если нет - корректно квалифицируем и выбираем другой следующий шаг”.

Это уже не слепой контроль скрипта.

Это управление логикой разговора.

Что увидели мы

Для нас это был важный продуктовый урок.

Перед тем как оценивать действие, нужно оценить контекст.

AI должен не только отвечать на вопрос:

“Сделал ли менеджер нужное действие?”

Он должен сначала понять:

“Было ли это действие уместно в данном звонке?”

Это уже другой уровень сложности.

Потому что система должна различать:

• целевой и нецелевой звонок;
• готового и неготового клиента;
• клиента на ранней стадии и клиента с острой потребностью;
• запрос по продукту и запрос вне продукта;
• ситуацию, где нужен замер, и ситуацию, где нужно только прогреть.

Иначе отчёт будет красивым, но несправедливым.

Founder-призма

Для меня это особенно чувствительная тема.

Я искренне хочу, чтобы продукт помогал собственникам.

Но если мы принесём им несправедливую аналитику, мы сделаем хуже.

Собственник посмотрит на отчёт и решит, что менеджер плохо работает.

Менеджер будет знать, что оценка несправедлива.

Руководитель окажется между цифрой и реальностью.

И вместо ясности появится конфликт.

Это ровно то, чего я не хочу.

Я не хочу, чтобы “Дожми Продажи” становился дубинкой.

Я хочу, чтобы он становился инструментом честного управленческого разговора.

А честный разговор начинается с признания: не каждый звонок можно оценивать одним и тем же критерием.

Как это влияет на отчёт

После появления логики “не применимо” итоговая метрика становится чище.

Мы смотрим не на все звонки подряд.

Мы смотрим на звонки, где критерий действительно мог быть выполнен.

Это снижает объём выборки, но повышает качество вывода.

Лучше анализировать меньше звонков, но честно, чем много звонков с искажением.

И здесь важно объяснять клиенту: N/A - это не мусор и не потеря данных.

Это защита от неправильного вывода.

Вывод для клиента

Если вы внедряете критерий качества, обязательно задайте вопрос:

в каких звонках этот критерий вообще применим?

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

Для одного менеджера пришло больше готовых клиентов.
Для другого - больше ранних запросов.
Для третьего - больше нецелевых.
Для четвёртого - больше сложных логистических случаев.

Если всё это сложить в одну метрику, отчёт начнёт врать.

Не потому что AI плохой.

А потому что критерий плохо ограничен.

Вывод для нас

В следующих проектах нам нужно сразу вводить три уровня оценки:

1. легитимен ли звонок для критерия;
2. было ли нужное действие;
3. насколько сильным было это действие.

Без первого уровня остальные могут быть несправедливыми.

Это важное изменение в методологии продукта.

Мы не должны просто искать поведение.

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

Следующий вопрос

Когда мы отделили легитимные звонки от нелегитимных, стало понятно:

даже хороший критерий и честная шкала не взлетят без доверия команды.

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

Так мы пришли к следующему выводу:

первая неделя внедрения нужна не для роста, а для доверия к системе.