Почему клиенты возвращаются c одним и тем же вопросом и как это исправить

Клиент может несколько раз обращаться в поддержку с одной и той же проблемой, а в отчётах это будет выглядеть как три успешно закрытые заявки. Разбираемся, как находить причины повторных обращений с помощью FCR и метода «5 почему».

Во вторник клиент пишет: «Не могу войти в личный кабинет». Оператор отвечает за восемь минут, отправляет инструкцию по восстановлению пароля и закрывает заявку. В четверг тот же клиент пишет снова — с той же формулировкой. Другой оператор отвечает за шесть минут, отправляет ту же инструкцию, закрывает заявку. В понедельник — третье письмо, уже с раздражением: «Вы вообще читаете, что я пишу?»

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

Это и есть повторное обращение. Дорогое оно не потому, что оператор потратил лишние четырнадцать минут. Дорогое оно потому, что отчётность его не видит.

Есть метрика, которая как раз и отделяет одно от другого, — FCR, First Contact Resolution: доля обращений, решённых с первого раза, без перевода на другого специалиста и без повторного контакта. Изначально её считали для телефонных линий, но сейчас, когда одна и та же поддержка отвечает в чате, мессенджере, почте и через форму на сайте, речь идёт о первом контакте в любом канале.

Базовая формула проста:

За месяц пришло 1 000 обращений, 750 решили сразу — FCR 75%.

Ловушка в слове «решили». Если считать решённым всё, что оператор закрыл, то у клиента из первого абзаца FCR будет 100%. Поэтому уточнённая формула вычитает переоткрытые заявки:

Из тех же 750 «решённых» 40 клиент открыл заново в течение 24–48 часов — и честный FCR уже 71%, а не 75%. Четыре процентных пункта разницы — это не погрешность, это те самые клиенты, которые пишут второй раз.

Окно в 24–48 часов — не догма, а рабочий стандарт: заявку не включают в FCR, пока оно не прошло. Если вы закрываете обращение и тут же засчитываете его в «решённые», у вас в отчёте не FCR, а скорость закрытия.

Для ориентира — отраслевые исследования: FCR от 80% считается мировым эталоном, но достигают его лишь около 5% контакт-центров; 70–79% — хороший уровень для большинства сервисов; ниже 70% — сигнал, что чинить надо процессы, а не отдельных операторов. Цифры стоит воспринимать именно как ориентир: в ИТ-поддержке, где половина вопросов уходит на вторую линию, объективный FCR ниже, чем у интернет-магазина с типовыми запросами, и это не приговор команде.

Две компании с одинаковой поддержкой получат разный FCR, если по-разному ответят на несколько вопросов. Их нужно зафиксировать до того, как строить первый отчёт:

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

За каждым повторным обращением стоит одна из нескольких типовых причин, и они почти никогда про «плохого оператора».

Формальное решение. Ответ закрыл часть проблемы или один сценарий из трёх. Оператор не ошибся — он просто не дочитал.

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

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

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

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

Потерянные заявки и неудобные каналы. Письмо утонуло в общей почте, чат закрылся, никто не перезвонил. Клиент пишет повторно не потому, что ему не помогли, а потому, что ему не ответили. Часть клиентов открывает обращение сразу в двух-трёх каналах, «чтобы быстрее», — и одна проблема превращается в три заявки.

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

Статистика поддержки обычно отвечает на вопрос «сколько»: сколько заявок, за сколько ответили, какой процент в срок. На вопрос «почему одно и то же возвращается» она не отвечает. Для этого есть метод, который в сервисе применяют реже, чем стоило бы, — RCA, анализ корневой причины. Смысл в том, чтобы сместить задачу поддержки с «быстро ответить» на «сделать так, чтобы больше не спрашивали».

Как это выглядит на практике, по шагам:

Шаг 1. Соберите выборку. Не все заявки за год, а повторные обращения по одной теме за последние несколько недель: «восстановление доступа», «ошибка в отчёте», «не приходит уведомление». Нужны закономерности, а не единичные случаи.

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

Шаг 3. Зафиксируйте очевидную причину. «Клиент снова забыл пароль». Это ещё не корневая причина, а точка входа.

Шаг 4. Спросите «почему» столько раз, сколько нужно. Метод «5 почему» придумали в Toyota для разбора брака на производстве, и он без изменений работает в поддержке. Цепочка из источника:

Почему пользователь снова забыл пароль? → Нет напоминаний о смене пароля. Почему нет напоминаний? → Процесс этого не предусматривает. Почему процесс не предусматривает? → Нет регламента периодической проверки доступа.

Три «почему» — и оказалось, что причина повторных обращений «не могу войти» не в клиенте и не в операторе, а в отсутствии регламента, о котором поддержка даже не знала. Пяти вопросов обычно хватает, иногда достаточно трёх.

Шаг 5. Определите меры. Конкретные и проверяемые: обновить инструкцию, включить автоматическое напоминание, пересмотреть процесс выдачи доступов.

Шаг 6. Внедрите и посчитайте. Стало ли меньше повторов по этой теме через месяц? Если нет — разбор проводится заново с новыми данными.

Шаг 7. Сделайте это регулярным. RCA не работает как разовый отчёт и не работает как поиск виноватых. Работает только как привычка: раз в неделю или две брать самую частую тему повторов и разбирать её до корня.

Когда причин у одной темы много и они путаются, помогает второй инструмент — диаграмма Исикавы, она же «рыбья кость». Проблема — «клиенты повторно обращаются по восстановлению доступа» — становится головой рыбы, боковые кости — категориями причин: процессы, инструменты, люди, информация. На каждую кость команда выписывает факты: устаревшая инструкция, нет напоминания пользователю, история теряется при передаче, поиск по базе знаний не находит статью по слову «войти».

Главная польза диаграммы — она не даёт остановиться на первом объяснении. В поддержке оно почти всегда одно: «пользователь не умеет» или «не прочитал инструкцию». Диаграмма заставляет спросить, почему не умеет, — и выясняется, что интерфейс запутан, а инструкция написана два релиза назад.

Разбор бесполезен, если после него не меняется процесс. Четыре направления, которые закрывают большинство основных причин.

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

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

Обучение — на реальных повторных обращениях. Не на абстрактном курсе по продукту, а на разборе заявок. Отдельно учат двум вещам: задавать уточняющие вопросы до ответа и закрывать разговор вопросом «мы решили вашу проблему полностью?». Этот вопрос — самый дешёвый способ поднять FCR: он превращает «закрыто оператором» в «подтверждено клиентом».

Убрать конфликт в метриках. Требование решать 80% вопросов с первого раза не уживается с лимитом десять минут на обращение. Оператор, зажатый между двумя показателями, выберет тот, за который ругают сильнее, — и это будет скорость. Прежде чем требовать FCR, решите, что важнее: формальная скорость или полное решение, даже если оно потребует передачи специалисту.

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

Не с внедрения метрики. Возьмите заявки за последний месяц и найдите пять клиентов, которые писали чаще всех. Прочитайте их переписку целиком. Скорее всего, за пятью клиентами обнаружится две-три темы, и по каждой из них три вопроса «почему» приведут не к оператору, а к инструкции, процессу или кнопке в продукте. Это и будет ваш первый список корневых причин — без диаграмм и без нового отчёта.

Считать повторные оборащения автоматически умеет любой нормальный сервис-деск — наш Админ24 в том числе: заявки собираются из всех каналов в одну очередь, история переписки не теряется при передаче между исполнителями, а по категориям видно, какие темы возвращаются чаще всего. Но инструмент здесь вторичен. Разница между поддержкой, где число повторных обращений снижается, и поддержкой, где они растут, — не в отчёте, а в том, читает ли кто-то раз в неделю переписку и спрашивает ли «почему» больше одного раза.

Как у вас засчитывается, что заявка решена — по статусу оператора или по подтверждению клиента? И считаете ли вы эскалацию на вторую линию провалом первого контакта? Интересно сравнить, у кого какие договорённости, — особенно там, где поддержка техническая и половина заявок объективно не решается на первой линии.