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

06 июня 2022

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

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

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

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

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

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

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

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

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

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

Автоматизация помогает решить проблему при внедрении Jira service desk по API
1 — задача создана от имени Даниила,
2 — сработала автоматизация по замене автора в задаче,
3 — почта клиента, по которой происходит подстановка автора,
4 — проверка срабатывания (блокировка) автоматизации.

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

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

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

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

Automation в Jira Service Desk: Внутренний комментарий и инструкция для пользователя
Инструкция для сотрудника, если поле Автор не изменилось.

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

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

Service Desk API. В jira service desk есть стартовый пакет автоматически направляемых уведомлений. По желанию их можно отключить и настроить автоматизацию на отправку сообщений с любым текстом. Или оставить стандартное уведомление с его триггером отправки.
Под каждый проект можно настроить стандартные и кастомные уведомления.

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

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

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

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

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

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

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

Jira Service Desk имеет ряд встроенных уведомлений. Отключив некоторые, позволяет нам настроить собственные автоматизации.
Встроенные автоматизации в Настройках проекта в разделе Уведомления клиентов (Customer notifications), где используется поле Request Participants.

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

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

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

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

Процессы service desk. Настройка автоматизаций для регламентированных подсказок в Jira
Закрепленные подсказки, доступные во всех тасках службы поддержки.

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

Service desk по API. В карточке задачи отображается исходящие и входящие сообщения в виде комментариев
Автоматические уведомления для сотрудника и клиентов сервиса.
Jira service desk по API направляет письма клиентам в привычный им почтовый сервис
Уведомления в почте у пользователя и Request Participants о добавлении в копию запроса.

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

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

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

Двойное использование поля в Jira service desk
Пока в поле Request Participants есть пользователи, они будут видеть у себя в почте всю переписку по запросу и также могут сами в ней участвовать.
Управление обращениями service desk. Кастомное поле для текста автосообщения клиенту
Поле автоответа для согласующей стороны с возможностью вручную изменить шаблон.
Автоматизация в Jira направляет почтовое сообщение для списка указанных лиц в поле согласования информации
Письмо для согласования в почте у Request Participants.

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

Все направленные письма для клиента отображены в карточке задачи в Jira
Сотрудник может убедиться, что автоматизация сработала и пользователь в Request Participants получил всю необходимую информацию.

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

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

Отчеты в Jira по задачам формируют наглядное представление о проделанной работе сотрудника
В Jira Service Desk много встроенных отчетов, например, динамика созданных и решенных запросов.

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

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

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

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

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

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

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

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

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

Автор статьи
Виктория Уварова

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

Наши клиенты

WBTech - Клиенты - МТС
WBTech - Клиенты - Высшая Школа Экономики
WBTech - Клиенты - Лента
WBTech - Клиенты - Верный
WBTech - Клиенты - Рамблер
WBTech - Клиенты - Совкомбанк
WBTech - Клиенты - Билайн
WBTech - Клиенты - Леруа Мерлен
WBTech - Клиенты - Ульяна Сергеенко
WBTech - Клиенты - Правительство Москвы
ИП Гришанин Кирилл Олегович
ИНН 774313842609
Коворкинг Starthub
Б. Новодмитровская ул., 36, стр. 12, вход 6, Москва, Россия, 127015
Коворкинг Wework
Ahad Ha'am 54, Tel Aviv-Yafo, Израиль