Как анализировать причины повторных обращений

Повторные обращения – это не просто «еще одна заявка», за каждым из них стоит конкретная причина. Их понимание помогает исправлять процессы, улучшать инструкции и устранять системные ошибки, а не просто закрывать одни и те же заявки снова и снова.

Как правило, за повторными заявками стоят одни и те же причины:

Теперь, когда мы разобрали основные причины повторных обращений, становится понятно: просто закрывать заявки недостаточно. Чтобы снизить количество повторов, нужно системно разбирать каждое повторное обращение и искать его корень.
Здесь на помощь приходят специальные методы анализа. Среди них ключевое место занимает методика RCA, инструмент «5 почему» и диаграмма Исикавы. Поговорим про каждый более подробно.

RCA (Root Cause Analysis) – это методика поиска корневой причины проблемы. В контексте службы поддержки она используется не для того, чтобы быстрее закрыть заявку, а для того, чтобы понять, почему аналогичные обращения появляются снова и снова.

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

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

Рассмотрим пошаговое применение методики RCA.

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

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

На этом этапе фиксируем первую, внешне очевидную причину повторного обращения. Она еще не является корневой, но задает направление для дальнейшего анализа. Четкая фиксация очевидной причины помогает подготовить материал для более глубокого анализа методом «5 почему».

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

Пример цепочки:

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

На последнем этапе мы получаем корневую причину, которую можно исправить, чтобы повторения больше не происходили.

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

• обновить инструкции и базу знаний;
• внедрить автоматические напоминания о смене пароля;
• пересмотреть процесс онбординга и контроль доступа.

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

Важно понимать, что RCA не является разовой активностью. Это не отчет «для галочки» и не инструмент поиска виноватых. В саппорте RCA работает только тогда, когда используется регулярно и приводит к конкретным изменениям: обновлению инструкций, пересмотру процессов, внедрению автоматизации.

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

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

Сегодня этот метод используется не только в производстве, но и в IT, поддержке и управлении сервисом.

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

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

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

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

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

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

Рассмотрим каждый подробнее.

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

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

Примеры автоматизации:

• Автоматическая проверка данных при вводе: система сразу показывает ошибку и подсказывает правильный формат, не позволяя сохранить некорректные значения.

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

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

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

• Шаблонные сценарии для поддержки: типовые действия выполняются автоматически — меняется статус, назначается исполнитель, отправляются уведомления.

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

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

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

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

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

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

Это дает сразу несколько эффектов:

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

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

В связке с автоматизацией типовых ошибок база знаний даёт максимальный эффект. Автоматизация помогает предотвратить ошибку на уровне системы, а база знаний объясняет, что произошло и как действовать дальше.

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

Анализ причин повторных обращений помогает увидеть эти точки напряжения и перейти от «тушения пожаров» к системной работе. Методики RCA, диаграмма Исикавы и метод «5 почему» позволяют разобраться, где именно возникает сбой и почему он воспроизводится. А такие решения, как автоматизация типовых ошибок и база знаний, помогают не допускать повторов в будущем.

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