company_banner

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



    Когда пользователи наших мобильных почтовых клиентов обращаются в поддержку, в большинстве случаев они думают, что практически напрямую общаются с разработчиками. Это, конечно, не так. Сразу расставим точки над Ё: если бы тикеты от службы поддержки попадали к разработчикам в том виде, в каком они приходят от пользователей, то разработчики превратились бы в поддержку. Поэтому тикеты проходят через целый ряд «фильтров»: сначала три линии службы поддержки, затем передаются на экспертизу (решается, может ли это быть продуктовой проблемой и достаточно ли данных для её анализа), а потом попадают к тестировщикам на воспроизведение, по результатам которого ставят уже финальный таск в 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-системе после исправления бага. Возможно, добавим автоматический ответ пользователю о том, что баг исправлен.
    • Счетчик пользовательских жалоб в баг-задачах: полуавтоматическое обновление количества жалоб на каждую проблему.
    • +26
    • 5,3k
    • 7

    Mail.Ru Group

    782,08

    Строим Интернет

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

        А что за текст заблюрен на скриншоте?

          0
          Какие-либо персональные данные.
            0

            Вот именно.
            А как там обстоит дело с хранением персональных данных?

        0
        Расскажите, как вы работаете с бэклогом тикетов из техподдержки.
        Если баг воспроизводится и тестировщик ставит задачу, но сам баг редкий / некритичный / по другой причине не приоритетный, то как определяется, когда (если) задача берётся в работу?
        Кто «грумит» этот бэклог? Продуктовый менеджер? На основе каких данных?
        Или просто фиксированный объём человекочасов в каждом релизе фиксируется для исправления багов из бэклога саппорта?

        Как правило, самая сложная в решении проблема — не рассортировать таски, а выделить ресурсы (особенно если не всё соответствует стратегическим планам компании) — интересно почитать, как вы решаете именно эту проблему
          0
          Полуавтоматизированная приоритезация + SLA.

          Каждый багрепорт перед погрузкой в трекер оценивается по ряду факторов:
          • Вероятность встречи пользователя и этого бага. Оценивается по сложности сценария и длине пути пользователя для достижения проблемы.
          • Потенциальная массовость. Например, если проблема воспроизводится только на iPad Mini под iOS 10, то это плохо. Но не так плохо, как если бы баг проявлялся на всех устройствах.
          • Затронутый компонент приложения. Любая функция должна работать, но чтение писем всё таки важнее, чем смена аватарки.
          • Влияние проблемы на компонент. Оценивается деструктивное действие: ухудшает работу с функцией или блокирует её работу.

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

          Критические и Блокирующие баги покрыты внутренним SLA, по ним билд с исправлением обязан быть в течение 1 и 3 суток соответственно.
          Стандартные по приоритету багрепорты падают в общий бэклог, но могут двигаться в нём без очереди после появления нескольких пользовательских жалоб, требований от магазинов приложений или других факторов, повышающих критичность.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое