0

Как служба техподдержки Atlassian настраивает SLA в Jira Service Desk

Как служба техподдержки Atlassian настраивает SLA в Jira Service Desk

Это запись из официального блога Atlassian. Компания «Маллит», платиновый партнер Atlassian , перевела ее для вас и публикует с разрешения производителя.

Оригинал доступен по ссылке.

Техподдержка Atlassian охватывает весь мир. Сложный набор правил и логики маршрутизации позволяет круглосуточно обслуживать 6 регионов, поддерживать с разными уровнями SLA 15 продуктов, развернутых как на серверах, так и в облаках. Но даже с такой комплексной системой маршрутизации, как наша, своевременное назначение правильного инженера на тикет в режиме круглосуточного поступления запросов может оказать сложной задачей.

Мы начали использовать соглашения об уровне обслуживании (SLA) в Jira Service Desk для улучшения этого процесса. И вот как мы это сделали.

Нахождение баланса между ключевыми метриками ответа на запрос

Каждому клиенту нужен быстрый отклик на запрос и решение проблемы в максимально короткий срок. Именно поэтому многие компании предлагают сегодня схему с принятием обязательств по первоначальному времени отклика (Initial Response Time, IRT) и круглосуточной поддержке (например, как в нашей сравнительной таблице). Тем не менее, мы также знаем, что измерение лишь времени отклика может привести к снижению качества. Тогда как единственное, что действительно заботит клиента — это полноценное разрешение его запроса. Вот почему организации с услугами техподдержки измеряют еще и общее время разрешения запроса (Overall Resolution Time, ORT).

Мы придерживаемся трех ключевых принципов для достижения качественного уровня ORT:

1.    Закрепление тикета за инженером в том же временном поясе, в котором находится обратившийся клиент.

2.    Закрепление тикета за инженером поддержки с необходимым уровнем знаний и навыков для решения по запросу.

3.    Поддержка закрепления обращения за определенным инженером на протяжении всего жизненного цикла тикета.

Недавно мы обнаружили, что можем делать это еще более эффективно, изменив наши обязательства по IRT на график обработки «9 на 5». Мы позволяем тикету какое-то время оставаться не приписанным к конкретному инженеру, если не успеваем в смену того же дня. Наша услуга «Премиальной поддержки» (Select Support) оптимизирует закрепления тикета путем подбора оптимального инженера. При этом мы не ставим во главу угла скорость ответа на запрос без возможности обеспечить корректное решение по обращению.

Переход на поддержку в рамках временного пояса клиента

Наше предложение поддержки по графику «9-на-5» на самом деле является глобальной услугой. Вместо простого «9-на-5» из одного офиса мы предлагаем «9-на-5» в целом часовом поясе.

Например, если вы находитесь в Сиднее (GMT + 11), вы получите поддержку часового пояса между 8:00 и 17:00 по местному времени. Точно так же, если вы находитесь в Западной Европе или в поясе центрального времени в США, вы получите поддержку в диапазоне от 8:00 до 17:00 в вашем местном часовом поясе.

Мы делаем это, чтобы улучшить качество поддержки, чтобы оптимизировать вероятность получения клиентами инженера в своем часовом поясе (что, как мы знаем, помогает быстрее решить запрос).

Например, предположим, что клиент открывает некритический по важности тикет к концу своего рабочего дня. С нашим предыдущим 24-часовым режимом поддержки, IRT-счетчик начнет отсчет в момент обращения.

Для тикетов третьего уровня, для которых действовал 8-часовой период обязательного ответа, такое время подачи в конце рабочего дня означало заведомо проигрышную ситуацию. Либо такой тикет попадал неправильной команде инженеров (расположенной не в том же регионе) либо ему приходилось дожидаться следующего дня с нарушением требований к показателю IRT.

Путем экспериментов и исследований мы установили, что клиентам в такой ситуации лучше дожидаться, пока инженер необходимого уровня компетенций в их регионе сможет начать работу по тикету. Таким образом, мы изменили наши обязательства по IRT, чтобы оптимизировать процесс. В рамках «Премиальной поддержки» (Select Suport) тикет назначается для правильного часового пояса, а часы IRT начинают отсчет относительно корректного региона.

Вот каким было главное открытие: если мы пропустили критическое окно, когда наш клиент доступен и готов отвечать — нам лучше подождать и назначить его тикет инженеру с правильными навыками в том же часовом поясе, чем просто обозначить быстрый ответ. Изменяя ожидания клиентов от первоначального времени отклика, мы улучшаем качество обработки на всем жизненном цикле тикета.

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

Конфигурация SLA

Вот как мы реализовали этот подход. Прежде всего, мы определили, в каких часовых поясах располагается большинство наших клиентов.

Поддержка 9-на-5. Рабочие часы покрытия сервиса включают в себя 8:00 – 17:00 для следующих часовых поясов: Тихоокеанский (UTC-8), Горный (UTC-7), Центральноамериканский (UTC-6), Североамериканский восточный (UTC-5), Западно-европейский (UTC+0), Центрально-европейский (UTC+1), Восточно-европейский (UTC+2), Московское время (UTC+3), Австралийский Западный Стандартный (UTC+8), Австралийский Центральный стандартный (UTC+9), Австралийский Восточный стандартный (UTC+10). Индия покрывается по 10:00 – 19:00 (UTC+5.5). Япония – 9:00 – 18:00 (с поддержкой японского языка). Тикеты передаются в офис согласно региону, в котором они были поданы.

После того, как мы определили часовые пояса, формирование SLA стало легко выполнимой задачей.

Автор: Джереми Ларгман