📊 Метрики и фрод: зачем всё это и при чём тут саппорт
В субботу немного погорим про работу. Я знаю, что часть из вас не всегда понимает, о чём я пишу, но потерпите ещё чуть-чуть. Сегодня про метрики, но сразу оговорюсь: метрики ради отчётности никому не нужны (ну почти). Смысла считать всё подряд нет. Лучше меньше, но регулярно и с ясной целью. Я разделяю метрики на два уровня: must-have то, что стоит внедрять в первую очередь, и nice-to-have то, что даст объёмную картинку, когда база уже отстроена.
✅**** Must-have: Время первого ответа (FRT) Все привыкли к “мгновенным” реакциям, особенно в мессенджерах. Но важно отделять бота от живого оператора. Отправка автоответа — это не реакция. Считать стоит и то, и другое, отдельно по каждому каналу. Люди не ждут в Telegram так же, как ждут на email.
CSAT (Customer Satisfaction Score) Это клиентская оценка после ответа саппорта. И чаще всего она не про саппорт. Она про баги, задержки, сбитые процессы, неудобный UX, недоступный функционал. Клиент просто выплёскивает эмоцию и ставит “1” и нам всё равно отвечать нужно спокойно, точно и с эмпатией: иногда это единственное, что мы можем сделать. И да, оценку важно смотреть не по одной штуке, а в динамике. Отклонение в 0.2 вниз по неделе важнее, чем единичка от раздражённого пользователя.
Количество тикетов и сегментация Без разбивки по каналам, темам и причинам — это просто цифра. Если вы каждый день закрываете 150 тикетов про один и тот же баг, это не означает, что вы “молодцы, обрабатываете много”, это означает, что никто не устранил корень. Саппорт — это не канал “ответить”, а место, где видно, что не работает. Сегментация нужна не для галочки, а чтобы не тратить ресурсы на одно и то же.
FCR (First Contact Resolution) Процент обращений, которые решаются с первого касания. Один из самых важных показателей, потому что отражает не только квалификацию саппорта, но и зрелость процессов. Если FCR падает, почти всегда причина в размытых зонах ответственности, неполных базах, плохом доступе к информации или невозможности действительно помочь. Я считаю, это важнее, чем NPS. Как минимум потому что повторное обращение - это деньги.
Проверка качества Проводить рандомно, по низким оценкам клиентам, по жалобам, по новым релизам и т.д. Но суть не в “поставить оценку”, а в том, чтобы выявить ошибки: в понимании продукта, в тоне, в оформлении, в логике. Кто-то даёт слишком сухие ответы, кто-то запутался в релизе, кто-то просто эмоционально выгорел и это видно в каждой строчке.
🧠 Nice-to-have: если база уже есть, идём глубже CSI / CES / NPS CSAT — это про конкретный диалог. CSI — про общее впечатление от сервиса. CES — про то, насколько легко клиенту было решить вопрос. NPS — порекомендует ли он вас. Вводить сразу всё не нужно, но хотя бы понимать разницу важно. Эти показатели помогают смотреть на работу саппорта не как на “операционный отдел”, а как на часть клиентского пути.
SLA по типам кейсов Один SLA на весь саппорт — это профанация. Вопрос “не пришла выплата” и “у вас логотип странный” не имеют одинакового веса. Важно не просто “выполнить за 4 часа”, а правильно выставить приоритеты.
Churn и удержание Сопоставляйте обращения с последующими действиями. Кто уходит после общения с поддержкой? Что там было? Кто отвечал? Были ли задержки, ошибки, конфликты? В этом слое данных чаще всего прячутся самые неприятные знания, которые не видно в метриках на поверхности.
🕵️♀️ Контроль фрода
Про фрод тоже хочется сказать отдельно. Потому что в голове у многих — это только про “воруют деньги”. На деле, фрод — это любое поведение, которое нарушает систему. Со стороны клиента или изнутри. И начинается всё не с хищений, а с мелочей: кто-то постоянно получает “исключение из правил”, кому-то “случайно” одобрили заявку без всех данных, кто-то из агентов слил инструкции другу.
🧩 В итоге Метрики — это просто инструмент. Они не решают проблемы, но помогают понять, где именно что-то пошло не так. Дальше всё зависит от того, смотришь ли ты в них регулярно и умеешь ли делать из этого выводы.
