«Не применимо» в оценке звонка: почему отсутствие критерия не равно нулю

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

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

Сцена для разбора такая: в понедельник руководитель отдела продаж открывает отчёт по звонкам за прошлую неделю. У менеджера Петровой десять звонков, итоговый балл 6,4 из 10. У менеджера Соколова тоже десять звонков, балл 7,1. Руководитель делает вывод, что Соколов работает лучше, и собирается обсуждать это на планёрке. При этом у Петровой шесть звонков были короткими техническими уточнениями по уже идущей сделке, а у Соколова — восемь полноценных первых контактов с новыми лидами. Оценка вроде бы честная, цифры посчитаны правильно, а вывод из них неверный. Дальше — про то, как устроена эта ошибка и что с ней делать методически.

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

Три состояния критерия и четвёртое, которое забывают

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

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

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

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

Почему «не применимо» нельзя выводить из удобства

Соблазн очевидный: если критерий снижает балл конкретному менеджеру, объявим его неприменимым. Так оценка превращается в подгонку результата под желаемое. Чтобы этого не случилось, применимость должна определяться свойствами разговора, а не итогом оценки. Тип звонка, этап сделки, инициатор контакта, наличие запроса на конкретное действие — вот из чего складывается решение о применимости. Всё это фиксируется до того, как мы посмотрели, как менеджер справился.

Практически это значит, что правило применимости — отдельный объект, который живёт своей жизнью и не зависит от баллов. Правило говорит: «для звонков типа X критерий Y применим, для типа Z — нет, для неопределённого типа — состояние неизвестно». Меняется правило — меняется и историческая картина, и это надо явно проговаривать, а не делать вид, что цифры за прошлый месяц остались прежними.

Здесь полезно вспомнить, как вообще устроены условные конструкции в автоматизации. В облачных потоках Microsoft условие — это явная ветка с проверкой, которая направляет выполнение по одному из путей, а не молчаливое «если что, пропустим» (Add a condition to a cloud flow). Тот же принцип стоит перенести в методику: применимость критерия — это явное условие с явными ветками, включая ветку «не смогли определить». Не «по умолчанию применимо», не «по умолчанию пропускаем», а проверка, у которой есть все исходы.

Что показывает уверенность распознавания и почему она не решает за нас

Отдельная тонкость — данные, из которых мы вообще узнаём, что происходило в разговоре. Речь распознаётся в текст, и у распознавания есть оценка уверенности. В Google Cloud Speech-to-Text уверенность возвращается на уровне результата распознавания и помогает понять, насколько модель уверена в сказанном (Recognition confidence). Это полезный сигнал, но он не отвечает на вопрос применимости критерия. Низкая уверенность говорит «мы плохо расслышали», а не «критерий здесь не нужен».

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

Как выглядит рабочий объект правила применимости

Чтобы правило не жило в головах и не переписывалось каждый раз заново, ему нужна форма. Ниже — условная схема, не привязанная к конкретному продукту; это то, что стоит зафиксировать в любом инструменте, который вы выберете.

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

Формула, которая меняется от звонка к звонку

Когда применимость введена, итоговый балл перестаёт быть простым средним. Для каждого звонка знаменатель свой: он равен числу критериев, применимых именно к этому разговору. Звонок, где применимы четыре критерия из десяти, и звонок, где применимы все десять, дают баллы по разным базам. Сравнивать их напрямую — всё равно что сравнивать температуру в градусах и в фаренгейтах, не глядя на шкалу.

Отсюда практическое правило: рядом с любым агрегированным баллом должна стоять не только цифра, но и состав. Сколько звонков вошло, сколько критериев в среднем было применимо, сколько состояний «неизвестно» осталось за бортом. Балл 7,1 при среднем знаменателе 9 и балл 7,1 при среднем знаменателе 4 — это два совершенно разных 7,1.

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

Эпизод первый: короткое уточнение, которому приписали провал

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

Система оценки настроена так, что критерий «выявление потребности» применим ко всем звонкам без разбора. Иванов получает минус за то, что не выявлял потребность. Критерий «презентация решения» — тоже минус, презентации не было. Критерий «договорённость о следующем шаге» — минус, следующего шага не предполагалось. Из десяти критериев выполнены два, итог — 2 из 10. Руководитель видит низкий балл и делает вывод, что Иванов разучился работать.

Что меняется с правилом применимости. Тип разговора — «техническое уточнение по идущей сделке». Для этого типа применимы критерии «подтверждение факта», «корректность данных», «вежливое завершение». Остальные — не применимы, они не входят в знаменатель. Иванов получает 3 из 3, и это честно: в рамках того, что от него требовалось, он справился. При этом сам звонок никуда не исчезает из отчёта — он виден как короткий контакт с узким набором критериев, и если таких звонков у менеджера стало вдруг много, это отдельный сигнал, но уже про распределение нагрузки, а не про качество разговора.

Эпизод второй: тип звонка не определён, и все делают вид, что всё в порядке

Другой условный случай. Менеджер Кузнецова ведёт разговор, который начинается как уточнение по счёту, а заканчивается обсуждением дополнительной услуги. По первым репликам классификатор относит звонок к «техническому уточнению», по последним — к «первому контакту». Тип не определён однозначно.

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

Правильная реакция — состояние «неизвестно» на уровне типа разговора. Звонок не получает итогового балла, но попадает в отдельный список на ручной разбор. Разборщик смотрит запись, присваивает тип, и звонок возвращается в оценку уже с явным решением. Это дороже, чем автоматический выбор, но честнее. И таких звонков на практике меньше, чем кажется, — если классификатор настроен разумно, неопределённых случаев единицы процентов, и их разбор не съедает много времени. Точные доли зависят от ваших данных, здесь я их не называю намеренно.

Ручное исключение: кто, когда и на каком основании

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

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

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

Применимость критерия оценки на экране сотрудника

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

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

Отдельно стоит продумать, как показывать динамику. Балл менеджера вырос с 6,0 до 7,0 — это он стал лучше работать или у него изменился набор звонков? Без состава знаменателя на обоих концах периода ответить невозможно. Поэтому в интерфейсе динамика должна идти в паре с изменением состава, а не отдельной цифрой со стрелочкой.

Сводный балл без состава — это не сравнение

Вернёмся к сцене из начала. Руководитель сравнил 6,4 и 7,1 и сделал вывод. С правилом применимости он увидел бы другое: у Петровой средний знаменатель 4,2, у Соколова — 8,7. Их баллы посчитаны по разным базам, и напрямую их сравнивать нельзя. Это не значит, что сравнение вообще невозможно — значит, что его нужно делать иначе: либо внутри групп звонков одного типа, либо с поправкой на состав, либо вообще не через единый балл, а через набор показателей по типам разговоров.

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

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

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

Второй — звонки, где запись неполная. Оборвалась на середине, потеряла кусок из-за канала, расшифровка не справилась с акцентом или терминами. Здесь работает корзина «неизвестно», но важно не смешивать её с «не применимо». Звонок с неполной записью не должен ни получать балл, ни выпадать из отчёта бесследно — он должен быть виден как дыра в данных, которую либо закрывают повторным прослушиванием, либо признают и учитывают в доле покрытия.

Третий — смена правил посреди периода. Если с середины месяца критерий стал неприменим для какого-то типа звонков, сравнивать первую и вторую половину месяца по итоговому баллу нельзя без оговорки. Либо пересчитывайте обе половины по одному правилу, либо не сравнивайте вовсе. Молчаливая смена правил — самый частый источник странных выводов в отчётах, которые выглядят нормально.

Как проверить, что применимость настроена правильно

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

Дальше проверьте граничные случаи. Звонок без определённого типа — попадает ли он в «неизвестно» или молча получает тип по умолчанию? Звонок с неполной записью — виден ли он в отчёте как дыра? Ручное исключение — фиксируется ли с причиной и автором? Смена правила — видна ли она в исторических данных? Эти четыре проверки закрывают большинство сюрпризов.

Полезно также сверить сам подход к оценке с тем, как устроены системы оценки в целом. В документации Microsoft по оценке генеративных приложений описан подход к оценке через набор метрик и критериев и отмечается, что результаты нужно интерпретировать с учётом того, что именно измерялось (Evaluation of generative AI applications). Это не про наши продукты и не доказывает наличие каких-либо функций у нас, но подтверждает общий принцип: без явного определения критерия и условий его применения цифра ничего не значит.

Практикум: пересчитать один отчёт вручную

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

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

Проверка на практике: применимость критерия оценки

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

Один конкретный шаг проверки: откройте последний отчёт по своему отделу и посмотрите, есть ли в нём рядом с итоговым баллом средний знаменатель и доля состояний «неизвестно». Если этих двух цифр нет, начните с них — без них любой балл, каким бы аккуратным он ни выглядел, остаётся числом без контекста. Формат обсуждения задачи и то, какие интеграции реально доступны, стоит уточнять отдельно, потому что наличие конкретного подключения проверяется под вашу конфигурацию, а не предполагается по описанию.

Смежный вопрос разобран отдельно: Нецелевые звонки: что исключать из оценки продаж.