Анализ обращений в техподдержку

Когда использовать

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

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

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

Что нужно для старта

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

Как провести

1. Рамка

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

2. Выборка

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

3. Словарь тегов

   Продакт, дизайнер и технический лидер независимо разметили одни и те же 50 обращений, сравнили результат и поправили категории. Так в GOV.UK получился общий словарь. Удобно держать два вида тегов. Первый отвечает «где» и привязан к функции или экрану. Второй отвечает «что» и различает вопрос, просьбу, ошибку и неудобство.

4. Разметка

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

5. Разговор с поддержкой

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

6. Привязка к сценарию

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

7. Гипотезы и проверка

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

8. Регулярность

   Динамику по темам удобно смотреть раз в месяц. Словарь устаревает вместе с продуктом, поэтому теги пересматривайте на ретроспективах и убирайте те, по которым нечего делать. В GOV.UK ручной обзор делали раз в две недели, потом перешли на ежемесячный автоматический отчёт и отчёты для команд раз в два-три месяца.

Результат

Сводка по темам. По каждой теме видно число обращений, место в продукте, пару цитат и решение. Такой документ можно положить на стол продакту и обсуждать порядок работ.

Типичные ошибки

• Выборка как «все пользователи»

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

• Теги, по которым нечего делать

  Часть тегов в GOV.UK оказалась неприменимой на практике, и их убрали. Каждый тег должен вести к решению или к вопросу для исследования.

• Устаревший словарь

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

• Обращения считают рутиной поддержки

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

• Все проблемы приписывают интерфейсу

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

Кто использует

Государственная цифровая служба Великобритании разобрала обращения по четырём продуктам платформы GOV.UK, среди них сервисы уведомлений и платежей. Сначала три человека размечали по 50 обращений, потом теги перенесли в систему поддержки. По итогам нашли пробелы на страницах продуктов и в документации, исправили их, а спорные пути проверили юзабилити-тестами. Подробности в блоге GOV.UK.

В Контуре обращения используют для быстрых исследований. Люди пишут в момент высшей мотивации, поэтому тикеты хорошо показывают критичные ошибки и массовые трудности. Обращения сопоставляют с метриками и доской запросов, как в примере с избранным выше. Разбор есть в статье на Хабре.