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

Выходит, если тикет высоко оценен КК, мы помогли пользователю? Не всегда.

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

Если пользователь потребовал вернуть деньги немедленно, а сделать это можно только через три недели, самый вежливый тон и корректные объяснения не спасут ситуации. Больше того: пользователь может потребовать чего-то невозможного (например, бесплатно выдать ему самую дорогую подписку) или остаться недовольным любой перепиской, потому что утром от него ушла жена и весь день он будет расстроен. Это значит, что тикет может быть идеальным со стороны контроля качества, но клиент всё равно думает, что мы — бесполезные дураки и помочь не можем.

Это противоречие возникает, потому что проверки тикетов замеряют внутреннее качество — то, насколько поддержка сама считает, что она хорошо отработала. Рассмотрим на примере обращения:

😠: Я ошибся тарифом, оплатил годовой. Верните деньги немедленно, мне пельмени купить не на что.
💌: Здравствуйте, Александр! Понимаю, что вы ошиблись, оформляю возврат. Мы не можем вернуть деньги мгновенно, потому что это зависит от вашего банка: это займёт до 21 рабочего дня. Как только деньги поступят — сразу уведомим.
😠: Три недели?! А вы там зачем сидите? Мне из-за вас оставаться без денег?
💌: Увы, провести возврат денег на карточку сейчас невозможно технически. Сроки возврата зависят от работы банковских систем. Мы напишем вам, как только деньги вернутся на счёт. Могу ли я ещё чем-то вам помочь, например, разобраться с тарифами на месяц?

Такая разность точек зрения обусловлена тем, что внутреннее качество измеряет соблюдение процессов поддержки, а внешнее качество — то, что чувствует пользователь:

Зачем нужны проверки, если пользователю на них плевать

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

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

Так как мы не первые, кто осознал это противоречие, в мировой практике качество услуг принято измерять двумя способами.

В 2023 году Zendesk выкатил бенчмарк IQS — 88%. Это среднее значение по области. На самом деле, у IQS нет нормы, потому что каждая компания устанавливает целевое значение в зависимости от своих целей и ценностей.

Чтобы IQS не был таким однобоким и не превращался в погоню за галочками в чек-листе, можно добавить к его рассчёту других ключевых показателей, которые вы считаете важными. Например, к соответствию стандартам поддержки (IQ), которое мы уже умеем рассчитывать, можно добавить среднее время первого ответа (AFRT) и оценку пользователем диалога (CSAT).

Каждый показатель оценивается отдельно, и их оценки выражаются в процентах или в виде десятичных дробей от 0 до 1, формула будет такой:



Пример расчёта:

1. Внутреннее качество, соответствие чеклисту (IQ) = 90% или 0,90
2. Достижение целевой метрики по скорости первого ответа (AFRT) = 75% или 0,75
3. Оценка диалога пользователем (CSAT) = 65% или 0,65

Это рассчёт IQS команды с учётом не только чек-листа, но и скорости ответа, и мнения клиента. Результат частично отражает и внешнее, и внутреннее качество. Но для оценки работы глазами клиента можно пойти по другой методологии.

Поскольку нормальный человек подвиснет от вопроса «Численно оцените разрыв между тем, что ждали, и тем, что получили?», придумали опросник RATER с пятью шкалами измерений. Клиент оценивает каждый пункт дважды: «что я получил» (P) и «как я хотел» (E):

Ищем общий результат и делим на пять измерений:



Клиент ещё не в аду, но уже близок:

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

Скорее всего, в вашей поддержке уже используют SERVQUAL, просто никто это так не называет. В конце диалога с саппортом можно оценить работу поддержки, и туда добавляют пару вопросов вроде «Вам ответили быстро?» или «Специалист был компетентен?». И не нужна руководителям толстая учёная книжка о качестве услуг из прошлого века, чтобы всё исправить.

Требования из RATER часто включают во внутренние чек-листы. Если вы задавались вопросом, почему вам запрещают писать «вернусь через пару минут», и возвращаться через час — это потому что ещё сорок лет назад учёные поняли, что людей это бесит.

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

Надёжность (Reliability) — «сделали то, что сказали», это про исполнение обещаний. Обещали перезвонить через час и перезвонили. Сказали, что деньги вернутся через три дня — вернулись.

А «решили проблему» — это про результат. Проблема может не решиться, даже если саппорт сделал всё, что обещал (например, передал разработчикам, а они забили). Клиенту всё равно, кто виноват, — ему решение сейчас нужно.

Поэтому для оценки того, насколько мы молодцы, придумали ещё и метрики — CSAT, CES, NPS. Но CSAT врёт, CES не защищает от дураков, NPS заставили повышать уборщиц. Об этом в следующей статье.