Создание кастомных автоматизаций при подключении Jira Service Desk по API

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

Сегодня делимся примерами кастомных автоматизаций, которые решают самые острые вопросы при внедрении Jira Service Desk (далее по тексту — JSD) по API.

Кастомные автоматизации
— Замена автора в задаче
      — Проверка срабатывания автоматизации замены автора
— Отправка уведомления пользователю о создании запроса
— Использование поля Request Participants
      — Почему потребовалось кастомизировать работу поля Request Participants
      — Как работает поле Request Participants
Формирование отчетности и учет SLA в работе над задачами
— Уведомления при нарушении SLA
Поддержка — непрерывный процесс

Кастомные автоматизации

Замена автора в задаче

Триггер: создание задачи.
Условие: проверка соответствия поля Автор заданному значению.
Результат: в зависимости от результата проверки условия — добавление общедоступного комментария к задаче / добавление клиента / добавление внутреннего комментария.

При подключении Jira Service Desk по API мы столкнулись с важным ограничением: все запросы могут поступать только по одному ID пользователя Jira. Например, это ID сотрудника техподдержки Даниила. Пользователи отправляют запросы и через API они поступают в Jira Service Desk от имени Даниила.

Отправка уведомлений о ходе обработки запроса или переписка с пользователем возможна, только если в поле Автор стоит автор запроса (его имейл), а не наш сотрудник Даниил. Необходимо было найти способ делать замену значения в поле Автор на имейл пользователя.

Самое простое и рутинное — вручную добавлять имейл в поле Автор. А так как мы не любим рутину, то сделали автоматизацию, которая меняет поле Автор на имейл клиента и отправляет ему все необходимые уведомления.

Проверка срабатывания автоматизации замены автора

Если имейла автора нет в клиентах Jira Service Desk, автоматизация не сработает. И чтобы наш сотрудник увидел это и исправил, настроили систему уведомлений с четким порядком действий:

• если автор не изменился — как самостоятельно исправить ошибку, чтобы для пользователя это было незаметно,
• блокировщик задачи, который не позволяет двигать ее по воркфлоу, пока поле Автор не будет изменено на корректное значение.

Хорошо отстроенная система предусматривает:
— возможность ошибки,
— уведомление об ошибке,
— и простой способ ее исправить.

Отправка уведомления пользователю о создании запроса

Без подключения через API эта задача легко решается встроенными уведомлениями в JSD.

В случае подключения через API, как мы уже отметили выше, запросы создаются только через один ID, поэтому если мы используем встроенные уведомления, то письмо о создании задачи придет нашему сотруднику Даниилу (чей ID мы использовали в API).

Поэтому нужно настраивать кастомную автоматизацию, которая отправит уведомление о создании запроса только при условии замены автора на корректный имейл.

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

Триггер: изменение поля Автор.
Условие: проверка соответствия статуса и поля Автор заданным значениям.
Результат: добавление общедоступного комментария к задаче.

Использование поля Request Participants

Мы используем это поле для согласования запросов и добавления других пользователей в копию запроса.

Триггер: изменение статуса задачи на Ожидает согласования или изменение значения в поле Request Participants.
Условие: по значению поля Request Participants или по статусу задачи.
Результат: отправляются имейлы участникам запроса или общедоступный комментарий, а также добавляется внутренний комментарий для сотрудника.
Проверка на ошибку: если условие автоматизации не соответствует ожидаемым значениям, добавляется внутренний комментарий для исполнителя об ошибке.

Почему потребовалось кастомизировать работу поля Request Participants

Если использовать для общения с пользователями Портал Jira Service Desk, часть автоматизаций не нужна. Но мы используем только имейл общение, так как не хотим перегружать клиентов сторонними сервисами. Это заставляет нас творчески подходить к организации рабочих процессов.

С полем Request Participants мы сделали две автоматизации, каждая отправляет разные сообщения — предупреждение, что пользователя добавили к запросу, или просьбу согласовать изменения. Автоматизации реагируют на разные комбинации статуса и поля Request Participants.

При обработке запроса запомнить два разных алгоритма действия для одного поля может быть сложно. Чтобы не перепутать действия, есть фиксированные подсказки.

Фиксированные подсказки подходят только для важных и/или сложных процессов. Мы старались, чтобы их не было много, и все процессы были просты и прозрачны.
Подсказки должны повышать эффективность и точность обработки запросов. И что не менее важно — сотрудник благодаря им не ошибается и не отвлекает вопросами своих коллег.

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

Как работает поле Request Participants

Напомним, что комментарии в запросе могут быть внутренними — их видят только сотрудники поддержки, и общедоступными — их видит автор (он же клиент), а также все, кто добавлен в поле Request Participants. Такой формат позволяет вести общение полностью через имейл, где в получателях письма могут быть несколько человек.

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

Формирование отчетности и учет SLA в работе над задачами

Руководство следит за количеством запросов и скоростью их обработки через встроенные отчеты в Jira Service Desk.

Уведомления при нарушении SLA

Триггер: нарушение порогового значения SLA по типу и заданному условию.
Результат: добавление внутреннего комментария к задаче.

Автоматизации должны быть настроены только на рабочее время. Мы не беспокоим сотрудников ночью или в выходные дни.

SLA настраивается чаще всего на скорость обработки запросов. У нас настроены SLA на следующие правила:

1. Сотрудник должен взять задачу в работу в течение 1 часа. Это значит, что с момента, когда задача появляется на доске, до момента, когда она переводится в статус В работе (In progress), должно пройти не больше часа.
   Если правило нарушено, автоматизация добавляет внутренний комментарий с упоминанием исполнителя и просьбой взять задачу в работу.
   Если прошло 2 часа, а задача все еще в статусе К выполнению (To do), внутренний комментарий призывает руководителя взять процесс под контроль — руководитель проверяет, почему запрос не в работе, в чем нужна помощь. Это правило SLA для нас самое главное.
2. Сотрудник должен закрыть запрос в течение 3 дней. Запас взят на возможное долгое время ответа от пользователей. Нарушение этого правила для нас не критично, но стараемся держать темп. Принцип уведомлений аналогичный п.1.

Поддержка — непрерывный процесс

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

Рекомендуем систематизировать запросы и сформировать однозначные и вежливые ответы. А также обратить внимание на частые вопросы от ваших сотрудников и зафиксировать ответы там, где их легко найти. Этим вы упростите работу всему отделу.

Остались вопросы — напишите нам!