Быстро — не равно хорошо: как оценить качество обслуживания клиентов
Блог Kaiten ·
Разбираемся, как руководителю выстроить систему контроля сервиса обслуживания
Обслуживание клиентов — это комплексный бизнес-процесс. В нем нужно учитывать более 10 метрик на разных уровнях обслуживания и постоянно улучшать работу клиентской поддержки. 
Как сделать так, чтобы время ответа специалиста занимало несколько минут, и клиентский вопрос был действительно решен, а не просто переведен в этап «Готово» — разбираемся в этой статье.
Читайте, какие показатели важно измерять для контроля качества сервиса и как их использовать для улучшения клиентского опыта и бизнес-процессов. 
Каждая компания, которая занимается обслуживанием клиентов, вырабатывает свои стандарты работы с пользователями:
Оценка качества обслуживания — это сверка соответствия реальной работы сотрудников со стандартами клиентского сервиса. 
Без стандартов обслуживания невозможно оценить работу сотрудников и привести к единому KPI .
Основные причины оценки: 
Выявление слабых мест процесса на раннем этапе . Регулярная оценка сервиса показывает сбои в системе, которые можно остановить до того, как они приведут к массовому оттоку клиентов.
Объективные показатели для дальнейших решений . Без оценки руководитель судит о качестве сервиса по единичным жалобам клиентов или ощущениям сотрудников. Оценка дает точные данные, которые показывают, где процесс выстроен на все сто, а где проседает.
Удержание клиентов и увеличение выручки. Качество сервиса связано с повторными покупками, что продлевает LTV клиента. Оценка позволяет увидеть конкретное место в бизнес-процессах обслуживания, которое приводит к повышению или снижению числа повторных заказов. 
Данные для объективной обратной связи сотрудникам. Реальные цифры показывают, какой сотрудник закрывает меньше обращений, с какими запросами у команды трудности. Цифры помогают дать точную обратную связь и разобрать причины падения показателей.  
Нельзя вывести идеальную формулу качественного сервиса до старта работа — это длительный процесс работы, связанный с постоянными улучшениями сервиса. И вывести стандарты можно только на практике. 
Пошаговый процесс разработки стандарта:
Есть 2 типа методов оценки качества сервиса:
Первые показывают масштаб проблемы, вторые — ее причину. 
Методы, которые дают измеримые цифры и позволяют сравнивать периоды, сотрудников, каналы коммуникации.
Способы узнать субъективное мнение клиента об обслуживании.
У процесса обслуживания клиентов есть 3 стороны: клиентский опыт, работа команды и предсказуемость процессов.  
Это субъективная оценка клиента от взаимодействия с сервисом. Здесь нужно смотреть не на результат работы сотрудника, а на впечатление клиента. 
Например, клиенту вернули деньги за товар за один день, что соответствует стандарту. Но в обратной связи покупатель отметил: «Пришлось трижды объяснять ситуацию разным операторам». Формально обращение закрыто успешно, но впечатление клиента — плохое.
Это операционные показатели самой команды поддержки — насколько качественно и быстро она выполняет свою работу.
Пример : оператор ответил клиенту через 30 секунд и перевел его обращение в статус «Закрыто» за 5 минут. Но после 10 минут клиент снова вернулся с той же жалобой. Быстро — не значит качественно. Сотрудник должен пересмотреть свой подход к обслуживанию. 
Это внутренняя система оценки работы команды — взгляд «сверху».
Оценка операционных процессов отвечает на вопросы:
Например, при прослушке отдельных диалогов все в порядке, но 30% обращений по одному и тому же вопросу передаются на вторую линию обслуживания. Возможно, у некоторых операторов нет доступа к нужным модулям CRM-системы , чтобы быстро закрыть вопрос. Проблема не в людях, а в процессе. 
Показатели, которые помогут оценить качество сервиса.
Чтобы проконтролировать качество сервиса, стоит вести учет заявок в одной системе. Разберем на примере сервиса Kaiten, как система управления заявками и задачами команды помогает в оценке обслуживания.
Service desk — это система, куда «падают» все заявки из разных источников. Без этого менеджеры не смогут отслеживать прогресс по всем обращениям и системно анализировать поток запросов. 
В Kaiten есть модуль Service desk, который собирает обращения клиентов из разных каналов — онлайн-формы, email, Telegram-бот — и превращает их в карточки на канбан-доске с этапами обработки заявок. 
Некоторые платформы предлагают автоматический контроль соблюдения SLA.
В Kaiten руководитель может заранее настроить соглашение об обработке заявок, которое будет динамически отображаться в карточках запросов, внутри которых специалисты видят:
Также Kaiten позволяет выбрать тип SLA в зависимости от типа заявки. Например, для обращений ключевых клиентов можно установить более короткие сроки, а для обычных — более длительные. Менеджер увидит их в карточке. Специалисту не нужно держать в голове стандарт и отслеживать самостоятельно, сколько прошло от старта работы над заявкой. 
После завершения определенного периода работы руководитель может увидеть статистику по соблюдению SLA разными сотрудниками и командой в целом. 
После решения обращения клиент может поставить оценку в том канале, через который он обратился – в Telegram-боте, письме или портале. Это готовая реализация CSAT: клиент оценивает конкретное обращение, и его оценка попадает в карточку и отчет.
Анализ разовых инцидентов, а не всей картины
Главная ошибка при сборе аналитики работы сервиса — смотреть на разовые случаи, а не системные показатели. 
Например, если CSAT упал на один день из-за сбоя в продукте — это не повод менять процессы. Но если CSAT ниже нормы третью неделю подряд — это уже основание для пересмотра работы специалистов.
Мышление «каждый низкий показатель = вина процесса»
Важно разделять человеческие ошибки и процессные. Чтобы выяснить, где ошибка — в работе конкретно человека или процессе — сравните показатели работы разных специалистов по одному и тому же процессу. Если они все находятся в равных условиях, но у одного из специалистов показатели ниже — это повод поговорить с человеком о его навыках или поставить на эту позицию другого сотрудника, но не менять процессы.
Аналитика уходит «в стол»
Нет смысла собирать цифры ради цифр. Оценка сервиса должна служить фундаментом для дальнейших изменений, которые поднимут показатели работы обслуживания. 
Главная цель оценки — использование данных для улучшения процессов.
Пересмотр процессов должен происходить по цепочке: оценка → анализ → изменение → повторная оценка. Регулярный проход по этому циклу делает оценку инструментом улучшения. Какие аспекты обслуживания может улучшить оценка:
Изменения скриптов и регламентов
Если низкие оценки о работе сервиса повторяются — проблема может лежать в скриптах и регламентах, по которым работают специалисты. 
Пример: клиенты отмечают, что при возврате товара им не предлагают альтернативу. Значит, в скрипт нужно добавить обязательную фразу-переход на альтернативное решение. Не нужно полагаться на инициативу оператора, важно выстроить одну систему для всех сотрудников.
Точечное развитие конкретных сотрудников
Если проблема характерна не для процесса в целом, а для отдельных людей — нужен разбор именно их диалогов и переписок с клиентами. 
Пример: у одного оператора стабильно ниже CSAT. При этом он технически верно закрывает все заявки. Можно разобрать именно его звонки и оценить, почему клиенты могут быть недовольны его работой. Затем проработать с ним выявленные моменты.
Изменения в инструментах и правах доступа
Оценка может подсветить длительный разбор обращений. Тогда важно погрузиться в процесс работы команды. Возможно, у специалистов нет шаблонов ответов под рукой, понятных инструкций  или автоматизации. 
Пример: специалистам нужно каждый раз вручную вносить данные клиента в договор. Решение — настроить автоматизацию проброса данных из карточки CRM в шаблон договора. 
Передача данных в другие отделы
Если корень низких показателей находится не в качестве сервиса, а в продукте, документации или смежном процессе, то задача поддержки донести проблему до нужного отдела, подкрепив ее цифрами. 
Пример: треть обращений связана с одной и той же путаницей в интерфейсе. Поддержка может донести эту информацию до отдела разработки, чтобы те пересмотрели UX-дизайн приложения.