FCR: что это такое, как считать и как повысить

FCR (First Contact Resolution) — решение с первого обращения, или с первого контакта. Метрика помогает понять, может ли поддержка решить вопрос сразу.

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

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

Показатель равен доле обращений, решённых с первого контакта, среди всех обращений, которые вы включили в расчёт:

Например, за месяц поддержка обработала 400 обращений. Из них 280 решили с первого контакта, без повторного обращения по той же проблеме. Значит, FCR = 280 / 400 × 100 % = 70 %.

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

Решением с первого контакта можно считать разное, поэтому критерий нужно выбрать до расчёта. Например:

• вопрос решён за первый разговор или первым ответом;
• вопрос решён без передачи на другую линию;
• клиент не обратился повторно по той же проблеме в течение установленного периода.

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

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

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

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

Обычно за низким показателем стоит одна из пяти причин:

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

Первые четыре способа отвечают на причины выше, пятый помогает найти новые:

1. Сделайте базу знаний доступной. Сохраняйте проверенные решения экспертов, чтобы ими могла пользоваться вся команда.
2. Собирайте данные сразу. Используйте формы и шаблоны, которые помогают получить описание ошибки, версию продукта и необходимые параметры.
3. Расширьте полномочия первой линии. Разрешите специалистам самостоятельно решать типовые вопросы по установленным правилам.
4. Настройте маршрутизацию. Направляйте сложные обращения сразу нужной группе.
5. Анализируйте повторные обращения. Ищите причины: неполный ответ, неверное решение или отсутствие подходящей статьи в базе знаний.

Даже правильная формула даёт неверный результат, если ошибиться в данных или методике:

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

Инженер быстрее решает типовой вопрос, когда проверенное решение доступно прямо в процессе работы.

В методологии KCS (Knowledge-Centered Service) специалисты используют существующие статьи и дополняют базу новыми решениями по мере обработки обращений. Так знания не остаются у отдельных экспертов, а становятся доступными всей команде.

В Swarmica база знаний встроена в хелпдеск. Инженер может найти статью и использовать её при работе с обращением, а если решения нет — подготовить черновик новой статьи. В отчётах видно, какие статьи чаще всего связывают с обращениями, а рядом — оценку качества статьи (AQI) и FCR. Для своих срезов есть конструктор отчётов.