Как найти первопричину повторяющихся проблем клиентов

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

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

Начните с повторяющегося результата

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

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

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

Соберите единый набор доказательств

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

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

Отделите симптом от причины

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

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

Разделяйте причины на четыре группы:

1. Информация недоступна, устарела или двусмысленна.
2. В процессе нет владельца, состояния, разрешения или сигнала завершения.
3. Сам продукт или правило создает обращение.
4. Ответ ошибочен, неполон или непонятен клиенту.

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

Проверьте причину до исправления

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

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

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

Назначьте владельца корректирующего действия

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

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

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

Убедитесь что проблема исчезла

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

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

В общем inbox DripTell связанная история клиента, владелец, статус, заметки и следующее действие помогают восстановить реальный путь клиента. Но программное обеспечение не должно объявлять первопричину только по частоте.

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

Если хотите сравнить этот процесс с текущей очередью поддержки, обсудите его с командой DripTell.

Часто задаваемые вопросы

Что такое анализ первопричин в клиентском сервисе?

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

Сколько обращений нужно проверить?

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

Нужно ли указывать имена сотрудников?

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

Как проверить корректирующее действие?

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