Как превратить обращения в поддержку в продуктовые вопросы

Категория по задаче и шагу

Категория "другое" плохо помогает продуктовой команде. Я предлагаю фиксировать сценарий, шаг, ожидание и препятствие: не нашёл подтверждение, не смог изменить время, не понял условие оплаты. Один запрос может содержать несколько проблем, поэтому границы классификации нужно согласовать.

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

Сопоставимые числа обращений

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

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

Как разметить вопрос о статусе

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

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

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

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

Проверка причины и результата

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

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

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

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