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

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

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

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

2. Какой побочный эффект мы можем пропустить? Рядом со скоростью нужен показатель качества, соответствующий процессу. Заранее договоритесь, что считается повтором, за какой период его проверяют и как учитывают сложность обращений. Универсальный порог здесь не поможет.

3. На что сотрудник действительно влияет? Ожидание ответа другого отдела и время собственной работы — разные причины задержки. Их стоит разделять, чтобы не требовать от человека исправить то, для чего у него нет полномочий.

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

В C | F | G Consulting начинаем разбор KPI с результата процесса, поведения команды и качества исходных данных. Красивое значение показателя полезно тогда, когда за ним стоит проверяемое улучшение работы.

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

Евгений Чапурин