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

Пользователям проще работать. А в отчёте отдела - падение объёма выполненной работы.

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

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

У одного из разработчиков программного обеспечения для промышленности возникла похожая задача: как учитывать помощь клиентам, если они нашли ответ сами? В описании проекта, компания рассказала о развитии базы знаний. После посещения сайта клиентов опрашивали: удалось ли найти нужное и помогло ли это обойтись без обращения к специалисту.

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

При этом снижение обращений само по себе тоже ничего не гарантирует. Возможно, инструкция помогла. А возможно, люди не нашли способ связаться с поддержкой, перестали доверять ответам или начали спрашивать знакомого специалиста напрямую.

Заменить цель «больше закрытых заявок» на «меньше открытых» - ещё не значит исправить оценку.

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

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

Для небольшой правки не обязательно затевать большое исследование. Но одного числа в отчёте недостаточно, чтобы понять, что произошло.

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

А как оценить самого сотрудника? Если мы просим его предотвращать обращения, но считаем только ответы, часть его полезной работы остаётся незаметной. Потратить час на улучшение инструкции или за тот же час закрыть несколько заявок? Для отдела первое может быть полезнее, но в личном показателе отразится только второе.

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

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

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