Как тикеты в саппорт превращаются в тикеты в Jira

в 12:24, , рубрики: jira, Блог компании Mail.Ru Group, поддержка, разработка мобильных приложений, саппорт, тикеты, Управление продуктом

Как тикеты в саппорт превращаются в тикеты в Jira - 1

Когда пользователи наших мобильных почтовых клиентов обращаются в поддержку, в большинстве случаев они думают, что практически напрямую общаются с разработчиками. Это, конечно, не так. Сразу расставим точки над Ё: если бы тикеты от службы поддержки попадали к разработчикам в том виде, в каком они приходят от пользователей, то разработчики превратились бы в поддержку. Поэтому тикеты проходят через целый ряд «фильтров»: сначала три линии службы поддержки, затем передаются на экспертизу (решается, может ли это быть продуктовой проблемой и достаточно ли данных для её анализа), а потом попадают к тестировщикам на воспроизведение, по результатам которого ставят уже финальный таск в Jira для разработчиков. К слову, до экспертизы добираются считанные единицы тикетов, из которых к разработчикам в виде задач приходит в 2-5 раз меньше, в зависимости от проекта.

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

У мобильных приложений свои особенности использования и обновления. Чтобы не потерять доверие пользователей, нельзя просто ждать, когда они сами отправят отчёты о багах. Пользователи не любят этим заниматься — многие, столкнувшись с багом приложения, просто ругнутся и закроют его, или могут пожаловаться в соцсетях, оставить отзыв на маркете. Поэтому мы собираем обратную связь не только через встроенную в приложения форму обращения в поддержку или к разработчикам. Мы также автоматически мониторим отзывы в App Store и Google Play, сообщения и комментарии в соцсетях, и ещё собираем данные, отправленные через форму на Help Mail.Ru.

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

Путь тикета

Итак, пользователь в форме обратной связи в приложении нажал кнопку «Отправить отчёт». К этому моменту приложение уже сформировало список сведений об устройстве, полезных и необходимых для диагностики. Сюда входят модель гаджета, версия операционной системы, язык устройства, аппаратная комплектация и другие сведения. На примере приложения Почты Mail.Ru для Android:

Как тикеты в саппорт превращаются в тикеты в Jira - 2

Все эти данные вместе с текстом обращения уходят на один из служебных почтовых ящиков, в зависимости от конкретного приложения (Mail.Ru или myMail) и операционной системы (iOS или Android). При обращении через Help Mail.Ru всё происходит так же — сервис формирует письмо и отправляет на ящик поддержки.

Обратите внимание, что на экране отправки отчёта есть галочка «Прикрепить логи приложения». Если она поставлена, приложение перед отправкой заявки автоматически упакует записанные логи в .zip-архив и прикрепит этот файл к заявке.

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

Как тикеты в саппорт превращаются в тикеты в Jira - 3

Также мы автоматически подтягиваем в 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-системе после исправления бага. Возможно, добавим автоматический ответ пользователю о том, что баг исправлен.
  • Счетчик пользовательских жалоб в баг-задачах: полуавтоматическое обновление количества жалоб на каждую проблему.

Автор: vict0rant

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js