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

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

Работать как попало в поддержке не получится — отдельные тикеты специалиста обязательно будут проверять. Вот, какие бывают форматы:
🎯 Проверки от специалистов контроля качества

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

Кто такие специалисты по качеству сервиса?
👨‍💼 Ревью от руководителя

Популярный вариант для небольших команд. Тимлид проверяет тикеты саппорта и даёт обратную связь.
🤝 Проверки от коллег

Интересный вариант проверки, где вы проверяете работу коллеги, а он — вашу.
🧐 Самостоятельные проверки

Вариант обучения, в котором уже закрытый тикет приходит к саппорту на анализ, а саппорт отмечает, с чем мог бы справиться лучше.
🤖 Автопроверки ИИ

Прогресс шагает по планете. Типовые ошибки — отсутствие приветствия, прощания, грамматические ошибки — может отслеживать и бот.
Сколько тикетов отправляется на проверку

С одной стороны, бизнес хочет быть достаточно уверен, что сотрудник работает хорошо, а такие выводы нельзя сделать по одному проверенному тикету; с другой стороны — проверять нужно поменьше, потому что каждая проверка стоит денег и чьих-то усилий.

Статистически обосновано проверять 3-5% случайных тикетов. Если в день вы обработали пятьдесят обращений, одно-два из них уйдут на проверку.

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

Чем более чувствительная тематика продукта (здоровье; психология; сервисы, требующие мгновенного реагирования) и чем более премиальная поддержка предполагается, тем больше будет проверок и выше требования.
Что будут проверять

У каждого проверяющего может быть своё мнение о том, как оценивать работу. Чтобы проверки не были «кто в лес, кто по дрова», принято ориентироваться на чек-листы — своды правил, как нужно себя вести в тикете и чего делать нельзя.

Цель чек-листа — помочь сотрудникам сориентироваться в тикете и доступно донести до всех, что мы считаем в работе специалистов хорошим и полезным. Чек-лист может фиксировать правильную последовательность действий в тикете и быть не только контрольно-сверочным, но и обучающим материалом.

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

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

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

Чек-лист может описывать как-то, что необходимо делать в каждом тикете, так и то, что делать запрещено:
Описывает нужные действия

В начале проверки мы считаем, что рейтинг тикета = 0
За каждое выполненное действие добавляется разное количество баллов, из них складывается итоговая оценка.
Если рейтинг тикета перевалил за целевое значение, этот тикет считается хорошим.
Описывает ошибки

В начале проверки мы считаем, что рейтинг тикета =100
За каждую допущенную ошибку баллы вычитаются: за критическую ошибку — много, за незначительную — поменьше.
Если рейтинг тикета упал ниже целевого значения, этот тикет считается плохим.
Чек-листы могут описывать и то, что хорошо, и то, что плохо. Для каждого канала поддержки хорошо иметь свою инструкцию: пространные и полные ответы в письмах не подойдут для быстрого ответа в чатах.

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

  1. ❌ Забыл поздороваться, ✅ но блестяще решил техническую проблему
  2. ✅ Поздоровался, сказал «пожалуйста» и прислал смайлик, ❌ перепутал тариф и отправил не ту инструкцию

Вы вложили душу в подробный ответ, разобрали проблему по косточкам, дали четкие шаги, а ответа нет. Почему?

Кто проверяет проверяющих

Когда работа с качеством выстроена сложно, особенно если с качеством работают отдельные проверяющие, их работу тоже проверяют: например, один тикет может попадать на независимое ревью двум разным сотрудникам. Результаты их оценки сравнивают между собой, и при расхождении дообучают того, кто был не прав, а его проверку обнуляют. Руководитель ОКК может выступать вторым слоем проверки, проверяя качество проверок качества (качество качество качество проверки проверки 🤪).

Чтобы все понимали понятие «хороший тикет» одинаково, проводят калибровки.

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

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

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

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

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


Парадокс: одни годами отвечают на тикеты, а другие стремительно растут в карьере. Ну и почему так несправедливо?

Что делать, если я не согласен с результатом проверки

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

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

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

Если апелляций много, это говорит о проблемах: или проверяют не так, как в чек-листе, или результаты проверки такие, что непонятны саппортам. Маленький процент апелляций к проверкам — 1−3% — говорит о том, что саппорты в целом с работой ОКК согласны.

Сложные отношения саппортов с проверками

Никому не нравится, когда его работу проверяют и указывают на ошибки. Руководители всегда позиционируют проверки так: это нужно для вашего собственного роста, для улучшения навыков и результатов работы. Заявление корректное, но им сложно проникнуться.

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

Вот, что можно сделать, чтобы бояться проверок поменьше:

  • Спрашивайте первыми
    Не ждите, пока звёзды сойдутся и к вам снизойдёт понимание, как обрабатывать сложные кейсы. Обсуждайте с коллегами и руководителем непростые тикеты, даже если они не попали на проверку, чтобы подстраховать себя в будущем.
  • Сделайте проверки предсказуемыми
    Изучите чек-лист проверок так, как будто от этого зависит ваша премия (отчасти так и есть) и убедитесь, что вы понимаете каждый пункт. Проверяйте свои тикеты самостоятельно по тем же критериям, прежде чем закрывать: много ошибок можно отловить самому, просто имея перед глазами чёткий список требований.
  • Помните, что ревью проверяет работу, а не вас лично
    Если вы ошиблись в тикете, это не значит, что вы тупой. Возможно, вам не хватило обучения, инструкций, скрипт тупой и его невозможно выполнять, или вас просто перегрузили работой, и поддерживать какое-то качество просто невозможно. Здраво оцените, могли бы вы сработать лучше, если бы приложили больше сил. Если нет, поговорите об отсутствующих инструкциях с руководителем.
  • Смотрите на результат проверки как на диагноз, а не приговор
    В мире нет ни одного человека, который не допускал ошибок никогда. Даже если вы идеально знаете все пункты с ошибками, вы имеете право просто устать. Если ошибка систематическая, подумайте сами или спросите совета у руководителя, что сделать, чтобы стало лучше: недобираете баллов за эмпатию — посмотрите тикеты коллег, у которых с ней отлично, и подсмотрите что-то для себя; если все сотрудники коллективно в чём-то ошибаются, попросите провести тренинг по техническим деталям.
Как никогда не ошибаться

Никак. Все ошибаются.

Не обижайтесь на результаты проверок и будьте готовы работать со своими ошибками. Всё будет хорошо.

Автор этой статьи в начале карьеры саппорта собрала все критические ошибки, которые предполагал чек-лист проверки, и за первые три месяца работы уронила рейтинг до минимального. Через полгода она уже вела встречи по улучшению качества для всей команды.
📚 Эти ссылки подобрали для вас вручную:
H2H в поддержке
Концепция «Human to Human» (H2H) — это подход для бизнеса про то, что взаимодействие между людьми (даже в профессиональной среде) должно быть человечным, искренним и основанным на эмпатии.
Как писать о багах
Сообщаем о проблемах так, чтобы их тут же решали
Как извиняться в интернете
Извинения в поддержке — универсальная затычка для ситуации, в которой клиент предположительно: расстроен, зол, страдает, вынужден делать лишнее или терпеть неудобства (подчеркнуть нужное). А после извинений общение вроде бы можно и завершать, уточнив, что нам искренне жаль.
Что делать, когда поддержка перегружена
Хелпдеск завален уведомлениями. Случилось страшное: поддержку завалило, и вы в непроглядной тьме тикетов, которым конца и края не видно.