80% компаний уверены, что предоставляют отличный сервис. Среди их клиентов с этим согласны 8%
Эту разницу в исследовании Bain & Company назвали «delivery gap» – разрывом в предоставлении услуг. Самое неприятное — внутри компании этот разрыв почти не виден. Дашборд зелёный, заявки закрываются в срок, среднее время ответа в норме. А клиенты тихо уходят к конкурентам, не оставив ни одного отзыва.
Знакомая сцена: оператор закрывает тикет за три минуты, отчёт за неделю выглядит прекрасно, руководитель доволен. Через месяц тот же клиент возвращается с тем же вопросом — или не возвращается вообще. В цифрах за ту неделю не было ни одного сигнала, что что-то пошло не так.
Проблема в том, что скорость и количество закрытых заявок измеряют не то. Заявку можно закрыть быстро и формально правильно — и при этом не помочь. А качество живёт не в сводных метриках, а в конкретных ответах, которые сотрудник пишет клиенту. Разберём, как это качество увидеть и как им управлять, не превращая контроль в бюрократию.
Почему «закрыли быстро» — это еще не значит, что помогли
Главная ловушка операционных метрик в том, что они описывают процесс, а не результат для клиента. Время первого ответа, среднее время решения, число закрытых тикетов — всё это полезно, но отвечает на вопрос «как быстро мы шевелимся», а не «решили ли мы проблему по-настоящему».
Самый честный индикатор того, что помогли не до конца, — повторные обращения. Клиент пишет снова по тому же вопросу, потому что ответ был неполным, инструкция непонятной или проблему закрыли «по шаблону», не вникнув. И цена этого выше, чем кажется: по данным отраслевой статистики, до 67% оттока клиентов можно предотвратить, если решать вопрос с первого обращения. Отток — это не абстракция, это деньги: 93% клиентов готовы покупать повторно при хорошем сервисе, а 33% задумываются о смене компании после одного плохого опыта.
Есть и более тонкий сигнал — расхождение между метриками. Если FCR (решение с первого обращения) высокий, а CSAT или NPS низкий — это красный флаг. На первый взгляд всё хорошо: вопрос закрыт быстро. Но клиент недоволен. Такой разрыв почти всегда означает одно из трёх:
- формальное закрытие — специалист технически «решил» вопрос, не разобравшись в сути;
- проблему в коммуникации — решение верное, но тон, безразличие или невнимательность свели весь эффект на нет;
- несовпадение ожиданий — клиент рассчитывал на большее, а получил базовый ответ.
Вывод простой: ни одна метрика в одиночку не говорит правды. Управлять качеством можно, только если регулярно смотреть на сами ответы, а не только на их статистику.
Контроль начинается с анализа, что сотрудник пишет клиенту
Качество поддержки наглядно видно по переписке. Поэтому основа контроля — не отчёты, а регулярная проверка реальных ответов. В каждом ответе имеет смысл смотреть на ряд вещей: понял ли сотрудник суть проблемы, задал ли уточняющие вопросы, полное ли решение предоставил, выдержаны ли логика и тон.
Здесь две типичные крайности, и обе убивают процесс. Первая — проверять ответы от случая к случаю или только когда уже прилетела жалоба: это даёт искажённую картину и не влияет на поведение команды. Вторая — пытаться просматривать все заявки подряд: проверяющие перегружаются за неделю, и всё затухает.
Рабочая норма выглядит так:
- фиксированный объём — например, 5–10 заявок на сотрудника в неделю;
- проверка по всем без исключения, независимо от опыта (а не только по новичкам);
- приоритет сложным и показательным кейсам — конфликтные ситуации, повторные обращения — плюс случайная выборка для общей картины.
Важно: проверка — это не способ найти виноватых, а инструмент, позволяющий увидеть типовые ошибки и понять, где доработать процессы или базу знаний.
Чек-лист, который делает оценку честной
Без единых критериев оценка субъективна: один проверяющий считает ответ хорошим, другой — посредственным, а сотрудник вообще не понимает, по каким правилам его судят. Чек-лист превращает проверку в управляемый процесс. Оптимально — 7–10 пунктов, чётких и измеримых, чтобы не было двойных толкований:
✔ корректность решения — вопрос клиента закрыт полностью и правильно;
✔ уточнения — если задача неясна, сотрудник задал вопросы, а не угадывал;
✔ структура и логика — шаги решения понятны и последовательны;
✔ понятность — без «воды» и лишних терминов, язык простой;
✔ тон — выдержан корпоративный стиль, нет резких формулировок;
✔ использование базы знаний — шаблоны и инструкции применены корректно;
✔ полнота и своевременность — ответ вовремя, детали учтены.
Каждый пункт оценивается однозначно: «выполнено / не выполнено» или по простой шкале 0–2. Чем проще шкала, тем дольше живёт процесс — попытки построить «идеальную» систему с коэффициентами обычно заканчиваются тем, что ею перестают пользоваться.
Еженедельные разборы — то, что реально меняет поведение
Прогонять ответы по чек-листу мало. Без разбора конкретных случаев контроль быстро становится формальностью. Разбор отвечает на главный вопрос команды: «как надо и как не надо». Несколько правил, чтобы он работал:
- берите 3–5 заявок за неделю, не больше;
- разбирайте и ошибки, и сильные ответы — на хороших примерах учатся не хуже;
- обсуждайте конкретные формулировки, а не сотрудника;
- фиксируйте выводы: как отвечать в типовой ситуации, что поправить в базе знаний и обучении.
И главное про формат: как только разбор превращается в публичную критику, люди начинают защищаться, замалчивать сложные кейсы и избегать внимания. Спокойный тон с фокусом «как сделать лучше» даёт заметный эффект уже через несколько недель.
Копайте до корневой причины, а не до виноватого
Когда одна и та же проблема всплывает регулярно, дело редко в конкретном операторе — чаще в процессе, инструкции или продукте. Чтобы это увидеть, support-команды берут простые методы из управления качеством:
→ «5 почему» (метод Toyota): задавайте «почему это произошло?» до тех пор, пока не дойдёте до причины, на которую реально можно повлиять. Клиент снова забыл пароль → нет напоминаний о смене → процесс их не предусматривает → нет регламента проверки доступа. Вот это и чиним.
→ Диаграмма Исикавы («рыбья кость»): раскладывает проблему на категории причин — процессы, инструменты, люди, информация — и не даёт остановиться на первом удобном объяснении вроде «клиент сам не разобрался».
Дальше — устранение корня: обновить инструкцию, добавить обязательный шаг или подсказку в интерфейсе, дополнить базу знаний. Это превращает поддержку из «тушения пожаров» в управляемый процесс, где одни и те же заявки перестают возвращаться.
Шесть способов превратить контроль качества в бесполезную бюрократию
На практике система ломается не на старте, а потом. Вот ошибки, из-за которых она не даёт эффекта:
- Нерегулярная проверка — запустили с энтузиазмом, потом неделями не возвращались. Сотрудники быстро понимают, что это необязательно.
- Перегруженный или абстрактный чек-лист — им либо неудобно пользоваться, либо каждый трактует критерии по-своему.
- Разбор-«разнос» — фокус на сотруднике, а не на его ответах. Команда закрывается.
- Неправильная выборка — либо всё подряд (перегруз), либо случайные простые заявки (ноль ценности).
- Контроль без последствий — ошибки фиксируют, но база знаний и стандарты не меняются. Проверка ради проверки.
- Слишком сложная система оценки — баллы, коэффициенты, формулы. Занимает много времени → ею перестают пользоваться.
Чек-лист: контроль качества у вас не работает, если…
Быстрая самопроверка — отметьте, что про вас:
✔ судить о качестве можно только по скорости и числу закрытых заявок — сами ответы регулярно не читает никто;
✔ проверяют выборочно и в основном новичков, а не всю команду;
✔ нет единого чек-листа — «хороший ответ» каждый понимает по-своему;
✔ повторные обращения не выделены в отдельную категорию и не анализируются;
✔ высокий FCR соседствует с низким CSAT/NPS — и это никого не настораживает;
✔ разборы случаются «когда есть время», а выводы из них никуда не записываются.
Три и больше галочки — качество у вас, скорее всего, держится на нескольких сильных сотрудниках. Уйдёт такой — уровень поддержки просядет, и вы увидите это только по оттоку.
Что в итоге
Контроль качества — это не надзор, а способ сделать качество предсказуемым и не зависящим от того, кто именно взял заявку. Три простых элемента — регулярная проверка ответов, понятный чек-лист и еженедельные разборы — превращают случайное качество в системное и заметно снижают повторные обращения. Любой современный сервис-деск собирает FCR, время ответа и нагрузку автоматически и помогает быстро поднять выборку заявок для разбора — мы в Админ24 в том числе. Но дело не в инструменте: даже идеальная аналитика остаётся косметикой, пока кто-то регулярно не читает сами ответы и не делает из них выводы.
А как у вас измеряют качество поддержки — по скорости и числу закрытых заявок или кто-то реально читает переписку? И ловили ли вы у себя тот самый разрыв, когда метрики зелёные, а клиенты недовольны?