Когда пользователи наших мобильных почтовых клиентов обращаются в поддержку, в большинстве случаев они думают, что практически напрямую общаются с разработчиками. Это, конечно, не так. Сразу расставим точки над Ё: если бы тикеты от службы поддержки попадали к разработчикам в том виде, в каком они приходят от пользователей, то разработчики превратились бы в поддержку. Поэтому тикеты проходят через целый ряд «фильтров»: сначала три линии службы поддержки, затем передаются на экспертизу (решается, может ли это быть продуктовой проблемой и достаточно ли данных для её анализа), а потом попадают к тестировщикам на воспроизведение, по результатам которого ставят уже финальный таск в Jira для разработчиков. К слову, до экспертизы добираются считанные единицы тикетов, из которых к разработчикам в виде задач приходит в 2-5 раз меньше, в зависимости от проекта.
Какие мы собираем данные и какой путь проходят пользовательские обращения и отзывы, прежде чем попасть к разработчикам?
У мобильных приложений свои особенности использования и обновления. Чтобы не потерять доверие пользователей, нельзя просто ждать, когда они сами отправят отчёты о багах. Пользователи не любят этим заниматься — многие, столкнувшись с багом приложения, просто ругнутся и закроют его, или могут пожаловаться в соцсетях, оставить отзыв на маркете. Поэтому мы собираем обратную связь не только через встроенную в приложения форму обращения в поддержку или к разработчикам. Мы также автоматически мониторим отзывы в App Store и Google Play, сообщения и комментарии в соцсетях, и ещё собираем данные, отправленные через форму на Help Mail.Ru.
Обращения из мобильных приложений сопровождаются логами, крешдампами и прочей информацией, поэтому иногда разработчики всё-таки выступают в роли поддержки, т.к. саппорт не всегда может использовать эту информацию, чтобы решить проблему на стороне пользователя.
Путь тикета
Итак, пользователь в форме обратной связи в приложении нажал кнопку «Отправить отчёт». К этому моменту приложение уже сформировало список сведений об устройстве, полезных и необходимых для диагностики. Сюда входят модель гаджета, версия операционной системы, язык устройства, аппаратная комплектация и другие сведения. На примере приложения Почты Mail.Ru для Android:
Все эти данные вместе с текстом обращения уходят на один из служебных почтовых ящиков, в зависимости от конкретного приложения (Mail.Ru или myMail) и операционной системы (iOS или Android). При обращении через Help Mail.Ru всё происходит так же — сервис формирует письмо и отправляет на ящик поддержки.
Обратите внимание, что на экране отправки отчёта есть галочка «Прикрепить логи приложения». Если она поставлена, приложение перед отправкой заявки автоматически упакует записанные логи в .zip-архив и прикрепит этот файл к заявке.
Наша CRM-система забирает из ящика письмо со всеми данными, включая приложенные скриншоты и файлы логов, и автоматически формирует заявку в службу поддержки.
Также мы автоматически подтягиваем в CRM отзывы пользователей из Google Play: система с помощью открытого Google Play Developer API забирает отзывы вместе с полной информацией об устройствах, включая версию приложения, модель устройства, разрешение экрана, объём оперативной памяти и пр. А поскольку у App Store нет открытого API, то отзывы из этого магазина приложений мы обрабатываем в веб-интерфейсе для разработчиков.
Совершенству нет предела, поэтому в будущем планируем добавить в CRM-заявки функцию сбора информации о подписке пользователя на пуши. Будем брать данные прямо с push-сервера и выводить в интерфейсе тикетов. Это позволит автоматически получать информацию о настройках пуш-уведомлений в приложении, о настройках тихого режима и статусе включённости уведомлений для каждой почтовой папки, как на момент написания заявки, так и на текущий момент.
Созданная в CRM-системе заявка рассматривается специалистами службы поддержки. Если нужно, они запрашивают у пользователя недостающую информацию, например, сценарий воспроизведения проблемы или скриншоты. Затем заявку внутри CRM-системы перемещают в соответствующую очередь (папку) в зависимости от тематики проблемы:
- Авторизация.
- Прикрепление вложений.
- Просмотр вложений.
- Аватарки.
- Синхронизация.
- Уведомление.
- Чтение писем.
- и пр.
Если проблема носит технический характер и ранее не встречалась, то после получения всех необходимых подробностей от пользователя служба поддержки создаёт задачу в Jira. Делается это через Jira API буквально в один клик в интерфейсе CRM-системы: на основании очереди (папки) система ставит заявку в свой проект и автоматически переносит в Jira-задачу все данные из CRM-тикета, включая описание проблемы, историю переписки с пользователем и вложения. После чего система проставляет метки, на основе которых задачи на бордах Jira автоматически сортируются по компонентам.
Далее задача попадает в тестирование, откуда есть три исхода и три соответствующие Jira-кнопки в задаче:
- Тестировщику нужны дополнительные данные для локализации проблемы. Он пишет комментарий для службы поддержки, которая обращается к пользователю за информацией. Этот комментарий транслируется из Jira в CRM-тикет, и его видит только команда поддержки.
- Тестировщик ставит задачу на исправление. Он переводит задачу в статус ожидания фикса, и данные поступают разработчикам. При этом Jira требует от тестировщика ссылку на Jira-задачу; после её ввода задача транслируется в CRM-тикет, который видим только для команды поддержки.
- Тестировщик закрывает задачу по какой-либо причине (например, проблема уже была исправлена в последнем обновлении).
Если проблема не связана с ошибкой в приложении, то информация о ней и возможных способах решения возвращается в службу поддержки и пополняет базу знаний.
Какой профит?
Возможно, у кого-то возник вопрос: «Зачем так усложнять процедуру сбора и обработки пользовательских обращений?». Отвечаем — благодаря этому:
- Каждая проблема превращается в отдельную задачу со структурированной и понятной информацией. При этом служба поддержки, тестировщики и разработчики совместно работают над решением проблемы.
- Легко отслеживать исправления баг-тасков и ответы пользователям о том, что мы всё исправили.
В дальнейших планах:
- Автоматическое закрытие Jira-задач с отчётами и тикетов в CRM-системе после исправления бага. Возможно, добавим автоматический ответ пользователю о том, что баг исправлен.
- Счетчик пользовательских жалоб в баг-задачах: полуавтоматическое обновление количества жалоб на каждую проблему.
