Служба поддержки может блестяще укладываться в метрику SLA (service level agreement) и «закрывать» сотни чатов в день. Парадокс, но при этом обычно повышается температура: выгорают сотрудники, подгорает у клиентов и они уходят, и, как следствие, сгорает синим пламенем прибыль компании. Ещё один парадокс: это руководство компании само поставило специалистов в такие условия.
Как же получается, что топ-менеджмент своими руками испепеляет нажитое непосильным трудом? Разбираемся в статье.
Всем привет. Вновь в эфире Вячеслав Зыкин, экс-начальник службы поддержки в системном интеграторе. Всё, что написано ниже, прожито на собственном опыте. Все шишки набиты самостоятельно, разборы полётов приведены, лучшие практики зафиксированы в базе знаний.
Метрики, которые вредят службе поддержки
Почему же поддержка горит в трёх местах? Потому что в ключевых показателях эффективности (KPI) у сотрудников стоят метрики, вынуждающие специалистов не решать проблемы, а «закрывать тикеты». Отсюда вечная гонка, отсюда искусственный вал тикетов, отсюда ответы в стиле и тоне «уже отвалите от меня все».
Среднее время ответа и SLA в 2 минуты
SLA (service level agreement или соглашение об уровне предоставления услуги) в духе «ответ за 2 минуты» рождает иллюзию контроля, но не гарантирует решения проблемы. Чтобы не провалить показатель, сотрудники шлют дежурные фразы «Спасибо за ожидание, уже решаем», откладывая реальную работу над запросом. Это превращает поддержку в чат-бота с живым аватаром: формально ответ есть, а ценности — нет.
Стресс от секундомера подталкивает специалистов к микромультизадачности: они мельтешат между чатами, сбиваются, чаще ошибаются и быстрее выгорают. В сложных кейсах требование «быть быстрым» вступает в прямой конфликт с требованием «разобраться до конца». Сотрудник либо даёт поверхностный ответ, либо пытается эскалировать задачу дальше по цепочке — клиент повторяет свою историю несколько раз и закономерно начинает закипать и ненавидеть всю компанию, а не только футболящих его специалистов.
Кстати, высокое искусство эскалации тоже надо осваивать, иначе ещё и распри внутри команды добавят хаоса.
Среднее время обработки (AHT) как убийца качества
AHT — Average Handle Time — задумывали как инструмент эффективности, но в жёстких рамках он подталкивает специалистов к откровенной халтуре. Сотрудник стремится «сэкономить» секунды, закрывает обращение после первого формального ответа и не спрашивает: «А получилось ли у вас?» В результате клиент уходит с туманным пониманием «что-то где-то нажать», и возвращается с ещё с тем же запросом, только в более раздражённом состоянии.
При таком подходе нет места эмпатии: на детальное объяснение, уточняющие вопросы, проверку результата просто не закладывают время. Специалист учится не докапываться до корня проблемы и решать её, а минимизировать время контакта. В статистике это выглядит красиво: вот какая высокая производительность. В реальности это негативный опыт клиента, снижение лояльности и переход к конкурентам.
В своей компании мы пользуемся такими просчётами: даём потенциальным клиентам возможность порешать вопросы с нашей поддержкой в течение ограниченного времени. Это срабатывает, бывали случаи перехода крупных корпоративных клиентов к нам.
Количество закрытых тикетов: галеры и рабы
Когда ключевая цель — «столько-то закрытий в смену», команда начинает оптимизироваться под счётчик. Специалисты начинают сортировать обращения, выбирают лёгкие, а сложные кейсы перекидывают коллегам, смежным отделам или в разработку. В хелпдеске образуется снежный ком из повторно открытых заявок, дубликатов и переписок по одной и той же проблеме.
Внутри команды формируется культура избегания ответственности, где важно не помочь клиенту, а не утонуть в тяжёлых задачах. Если управлять только по этим метрикам, поддержка будет формально вежливой, о совершенно бесполезной для клиента. Ибо сотрудники не заинтересованы в лояльном клиенте — у них другие приоритеты, им за клиентоцентричность не платят.
Метрики, которые помогают бизнесу
Но не отслеживать вообще никакие метрики — значит пустить работу на самотёк, а зарплату начислять, бросая игральные кости. Всё равно должны быть KPI, которые бьются с тактическими и стратегическими целями компании. Об этом есть отдельная статья, но повторить лучшие практики не грех.
CSAT, чтобы смотреть глубже оценки
Метрика CSAT (Customer Satisfaction Score) показывает удовлетворённость клиентов после взаимодействия с поддержкой, но сам по себе он неоднозначен. Клиент может поставить «5», потому что оператор был вежлив и старателен, даже если проблема решена наполовину или лишь на время. Поэтому CSAT важно анализировать в связке с текстом комментария, типом обращения и временем до финального решения.
Опасный сигнал — высокая скорость ответа, приличный CSAT и одновременно негативная тональность комментариев: «ответили быстро, но толком не помогли». Это маркеры токсичной операционной модели, где люди компенсируют системные проблемы личной вежливостью. Задача менеджера — не «подкручивать формулировки» вопросов, а менять процессы в поддержке, которые мешают реально помогать.
В практике нашей компании есть отдельный человек, который работает на удаленке и не знаком ни с кем из сотрудников поддержки. В его задачу входит анализ CSAT — он контактирует с клиентами и выясняет, помог ли сотрудник, была ли эта помощь действенной или формальной. Ответы клиентов этот человек передаёт руководителю поддержки — у того появляется реальные данные для принятия решений. Кстати, данные для CSAT собирает этот же человек в ходе общения с клиентами. Есть большая разница в том, кто просит оценить работу — сам специалист, который её сделал, или «посторонний» человек. Пока что рабочая гипотеза такова: клиент более объективен с «посторонним».
CES: усилие клиента как основа лояльности
Метрика Customer Effort Score измеряет, насколько трудно клиенту было решить свою проблему. Исследования Harvard Business Review показывают, что снижение усилий клиента сильнее влияет на лояльность, чем попытки «восхищать» его вау-сервисом. Gartner добавляет: уровень усилий лучше предсказывает будущую лояльность, чем общая удовлетворённость.
Чтобы CES работал, его нужно измерять не после первой реплики, а после полного закрытия цикла — когда клиент либо достиг результата, либо сдался. Вопрос формулируют просто: «Насколько легко вам было решить свой вопрос?» Чем меньше шагов, перескоков между каналами и повторений одной и той же информации, тем выше оценка и, как показывают данные, тем больше шанс повторных покупок и роста чека.
Это теория. На практике мы разбираем не все тикеты сплошным методом, а выделяем сложные кейсы и проводим разборы их решения, фиксируя приёмы эффективной работы в базе знаний. И те, что применил специалист, и те, что порекомендовали бы коллеги, когда возникнет подобная задача.
Retention Rate и LTV: поддержка как фактор выживаемости
Метрика Retention Rate (коэффициент удержания клиентов) и LTV (пожизненная ценность клиента) позволяют ответить на главный вопрос: «Способствует ли поддержка лояльности клиента и его готовности остаться, увеличивает ли ценность сотрудничества?» Если смотреть только на разовые оценки и скорость, легко не заметить, что клиенты после общения с саппортом уходят в паузу или к конкурентам.
Для сектора b2c (business-to-consumer, или бизнес для потребителя) полезный инструмент — когортный анализ. Сравните удержание и LTV клиентов, которые обращались в поддержку и получили устойчивое решение, с теми, кто не обращался вовсе. Если «контактная» когорта живёт дольше и тратит больше, то поддержка — реальный драйвер роста, а не только «центр затрат». Если наоборот — поддержка незаметно ускоряет отток, и это повод менять процессы и обучение.
В b2b (business-to-business или бизнес для бизнеса) и b2g (business-to-governmen или бизнес для госсектора) при обслуживании постоянно действующих систем и сервисов приток и отток клиентов изменяются на единицы или десятки в течение года, и каждый случай успеха или провала разбирается отдельно, чтобы зафиксировать в базе знаний лучшие практики привлечения и разобрать причины ухода.
Revenue per Contact: саппорт как центр прибыли
При грамотной настройке процессов поддержка становится центром прибыли. Сотрудники, хорошо знающие продукт и контекст клиента, способны предложить не просто «ответ на вопрос», а более подходящее решение: другой тариф, дополнительный модуль, переход на годовую оплату или автоматизацию части процессов. Это не агрессивный upsell, а логичный следующий шаг, который снижает напряжение клиента и закрывает глубинную потребность.
Метрика Revenue per Contact показывает, какую выручку приносит один контакт поддержки — за счёт продлений, апгрейдов, допродаж. Важно не превращать её в «план по впариванию», а обучать сотрудников видеть, где дополнительные возможности продукта действительно снимают системную боль клиента.
Root Cause Analysis или докопаться до корней
Самый ценный «артефакт» поддержки для бизнеса — не количество закрытых тикетов, а инсайты о первопричинах обращений (корневых причинах — Root Cause). Повторяющиеся вопросы по одному и тому же шагу, частые ошибки в конкретном сценарии, регулярные жалобы на непонятные статусы — всё это материал для улучшения продукта, документации и онбординга.
Простая метрика: сколько идей и гипотез, собранных из обращений, дошли до реализации в продукте? Если эта цифра нулевая или близка к нулю, значит, поддержка живёт в режиме бесконечной пожарной команды и никак не влияет на снижение входящего потока. Когда же Root Cause-аналитика становится частью бизнес-процессов, общее количество обращений падает, а роль саппорта смещается от «латания дыр» к развитию сервиса.
Чему обучать команду поддержки
Чтобы важные метрики росли, мало поменять дашборды — нужно изменить профиль команды, систему нематериальной мотивации и, в конце концов, KPI.
Чтобы изменить профиль — если изначально он был выбран неверно — нужно учить специалистов. Курсы и тренажёры по этим компетенциям удобно создавать и обновлять на платформе управления знаниями и совместной работы Teamly.
Алгоритм простой:
-
Собираем базу знаний. Включаем в неё описание бизнес-процессов с показателями качества работы, методики и лучшие практики решения сложных задач и коммуникации со сложными клиентами, а также мотивационные статьи.
Например, это может быть статья о том, кто платит специалисту. Это не его непосредственный начальник, не директор или владелец компании. Это клиент — поэтому каждый клиент так важен. Не будет клиентов — не будет работы, не будет зарплаты.
Отдельно стоит написать статью о недопустимости «впаривания» допуслуг обманом — это лучший способ потерять клиента. Деньги, конечно, главное — но не «100 долларов прямо сейчас» а «сто тысяч долларов на горизонте в пять лет».
-
Формируем обучающий курс: выстраиваем цепочку из статей БЗ от общего к частному, от простого к сложному так, чтобы прочтя все статьи специалист проникся ценностями компании, стал бы «болеть душой» за каждого клиента.
Делаем контроль знаний: с помощью ИИ или в ручном режиме создаём тесты, ответить на которые помогут статьи курса. Тесты можно вставлять как после каждой статьи, так и после группы статей, объединённых одной темой. О том, как это сделать, подробнее писали в статье Как искусственный интеллект меняет корпоративное обучение: тест за одну минуту.
Эмпатия и активное слушание в переписке и на созвонах
Нужно учить сотрудников видеть за сообщением человека и контекст. Если запрос «Где кнопка оплаты?» часто решается ссылкой на инструкцию, то запрос «Я ничего не понимаю, мне завтра сдавать отчёт, у меня все горит» требует другой тактики: более подробного объяснения, скриншотов, иногда созвона или совместного прохода по интерфейсу. Курсы и разборы кейсов помогают тренировать умение уточнять, перефразировать и подтверждать понимание, чтобы снижать усилия клиента, а не просто отвечать «по скрипту».
Командная работа и передача инсайтов
Важно обучать не только общению с клиентом, но и правильной коммуникации внутрь компании. Допустим, после череды эскалаций дело доходит до разработки.
Формулировка «У клиента Х ошибка 156» мало полезна даже тимлиду. Гораздо ценнее: «Три клиента за неделю не нашли кнопку Х, все ожидали увидеть её на главном экране, предлагают добавить подсказку при первом входе». Такие шаблоны описания кейсов и идей можно оформить в базу знаний и курс в Teamly, чтобы новые сотрудники с первых дней видели стандарт нужного уровня аргументации.
Тайм-менеджмент: важное против срочного
Поддержка живёт в режиме постоянного «срочно», поэтому нужно учить людей отличать срочность от важности. Быстрый ответ в чате — важен, но не всегда важнее, чем оформление качественного отчёта с Root Cause по критичному багу. Обучающие модули могут включать разбор типичных ситуаций, матрицу приоритизации задач и упражнения по планированию смены: что делаем сразу, что копим, что требует глубокой работы без переключений.
Глубокое знание продукта
Без сильного продуктового фундамента поддержка обречена быть «переключателем» на другие отделы. Короткие регулярные обучения по новым фичам, изменениям тарифов, частым кейсам клиентов позволяют специалистам отвечать уверенно и не зависеть от единичных экспертов. В Teamly такие обучалки можно запускать в виде микро-курсов с примерами реальных диалогов, чек-листами и быстрыми тестами на закрепление.
Системное мышление и работа с метриками
Наконец, важно учить сотрудников смотреть на свою работу через призму бизнес-метрик. Не только «успел/не успел по SLA», а «снизил ли я усилие клиента», «какой инсайт из этого кейса можно вернуть в продукт», «как это скажется на удержании и выручке». Такой сдвиг мышления превращает поддержку из исполнителей по скриптам в партнёров бизнеса. Курсы по метрикам, примеры расчёта CES, Retention и Revenue per Contact, реальные истории из компании помогают заземлить эту связь. Кстати, на смену SLA всё чаще приходит XLA — а это уже качественно иной уровень.
XLA (Experience Level Agreement) — это соглашение об уровне опыта сотрудников и заказчика. Его задача — измерять не только «работает/не работает», а реальную продуктивность и удобство работы с ИТ-сервисами. И на XLA не выйти с метриками типа
Вместо заключения
В сервисных компаниях, в системных интеграторах отделы и службы поддержки — это не центры затрат, а центры доходов, основные производственные подразделения. Поэтому мерить их эффективность в отработанных тикетах — значит резать на суп курицу, несущую золотые яйца.
Как только вы перестаёте измерять только скорость и количество и переводите фокус на снижение усилий клиента, картина мира меняется для всех участников процесса, начиная от конечного пользователя и заканчивая руководителями компаний. А уж насколько меняется стиль работы поддержки — просто небо и земля.
В ходе подобных реформ важно не упустить документирование, превращая сотни и тысячи тикетов в концентрат — базу знаний. Это один из краеугольных камней эффективной работы поддержки в новой парадигме клиентоцентричности.
Автор: Vitaliy_Chesnokov
