В предыдущей статье мы рассказали о стандартных автоматизациях, применение которых исключает рутину и однообразность в действиях сотрудников поддержки, помогает сконцентрироваться на качестве и скорости выполнения задач, и делают чище сам процесс техподдержки.
Сегодня делимся примерами кастомных автоматизаций, которые решают самые острые вопросы при внедрении Jira Service Desk (далее по тексту — JSD) по API.
Кастомные автоматизации
— Замена автора в задаче
— Проверка срабатывания автоматизации замены автора
— Отправка уведомления пользователю о создании запроса
— Использование поля Request Participants
— Почему потребовалось кастомизировать работу поля Request Participants
— Как работает поле Request Participants
Формирование отчетности и учет SLA в работе над задачами
— Уведомления при нарушении SLA
Поддержка — непрерывный процесс
Кастомные автоматизации
Замена автора в задаче
Триггер: создание задачи.
Условие: проверка соответствия поля Автор заданному значению.
Результат: в зависимости от результата проверки условия — добавление общедоступного комментария к задаче / добавление клиента / добавление внутреннего комментария.
При подключении Jira Service Desk по API мы столкнулись с важным ограничением: все запросы могут поступать только по одному ID пользователя Jira. Например, это ID сотрудника техподдержки Даниила. Пользователи отправляют запросы и через API они поступают в Jira Service Desk от имени Даниила.
Отправка уведомлений о ходе обработки запроса или переписка с пользователем возможна, только если в поле Автор стоит автор запроса (его имейл), а не наш сотрудник Даниил. Необходимо было найти способ делать замену значения в поле Автор на имейл пользователя.
Самое простое и рутинное — вручную добавлять имейл в поле Автор. А так как мы не любим рутину, то сделали автоматизацию, которая меняет поле Автор на имейл клиента и отправляет ему все необходимые уведомления.
2 — сработала автоматизация по замене автора в задаче,
3 — почта клиента, по которой происходит подстановка автора,
4 — проверка срабатывания (блокировка) автоматизации.
Проверка срабатывания автоматизации замены автора
Если имейла автора нет в клиентах 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 часа. Это значит, что с момента, когда задача появляется на доске, до момента, когда она переводится в статус В работе (In progress), должно пройти не больше часа.
Если правило нарушено, автоматизация добавляет внутренний комментарий с упоминанием исполнителя и просьбой взять задачу в работу.
Если прошло 2 часа, а задача все еще в статусе К выполнению (To do), внутренний комментарий призывает руководителя взять процесс под контроль — руководитель проверяет, почему запрос не в работе, в чем нужна помощь. Это правило SLA для нас самое главное. - Сотрудник должен закрыть запрос в течение 3 дней. Запас взят на возможное долгое время ответа от пользователей. Нарушение этого правила для нас не критично, но стараемся держать темп. Принцип уведомлений аналогичный п.1.
Поддержка — непрерывный процесс
Хорошо отстроить систему поддержки получится не сразу. Внедрение новых фич, изменение внутренних правил и другие события способствуют пересмотру текущих процессов. Мы постоянно работаем над улучшением поддержки и регламентов обработки запросов.
Рекомендуем систематизировать запросы и сформировать однозначные и вежливые ответы. А также обратить внимание на частые вопросы от ваших сотрудников и зафиксировать ответы там, где их легко найти. Этим вы упростите работу всему отделу.
Остались вопросы — напишите нам!
