Как вычеркнуть из рабочего процесса однообразные задачи и улучшить жизнь всему отделу техподдержки: от исполнителя до руководителя.
На примерах рассказываем, как получилось уйти от большого количества рутины, и нашему сотруднику техподдержки стало максимально просто.
Стандартные автоматизации
— Изменение исполнителя по типу запроса или задачи
— Создание комментария при изменении поля в задаче
— Автоматическое создание задачи
— Проверка заполнения полей
— Автоматическое изменение статуса задачи
— Получена новая информация от пользователя
— Клиент не отвечает на сообщения
— Проверка наличия вложений в задаче
Всегда есть место для улучшений
На все однотипные области удержания внимания сотрудников мы сделали ряд автоматизаций, где старались учесть такие моменты как:
- Пользоваться сервисом должно быть легко и клиентам, и сотрудникам.
- Техподдержка должна быть интуитивно понятна.
- Короткий срок обучения новых сотрудников.
- Работа над задачей происходит только в карточке Jira без переходов в сторонние сервисы.
- Максимально эффективное общение между пользователями и сотрудниками поддержки, и многое др.
При внедрении Jira Service Desk (далее по тексту — JSD) и создании автоматизаций у нас было строгое ограничение: коммуникация с пользователями должна быть только через имейл. В рамках поддержки пользователь должен получить письма о том, что:
- запрос создан,
- взяли запрос в работу,
- отправили на согласование,
- добавили пользователей в копию запроса,
- обработали задачу и перевели в статус Готово (Done).
Стандартные автоматизации
Изменение исполнителя по типу запроса или задачи
Триггер: создание задачи.
Условие: if-else по типу запроса.
Результат: назначение сотрудника исполнителем.
Это первое, что рекомендуем настроить при внедрении Jira Service Desk, чтобы избежать создание тасков на доске только для одного сотрудника. Правило автоматизации можно найти в библиотеке Jira.
Мы настроили эту автоматизацию в зависимости от типа запроса. Есть также интересные варианты с распределением задач, например, в зависимости от загруженности сотрудников. Рекомендуем ознакомиться с готовыми шаблонами от Jira.
Создание комментария при изменении поля в задаче
Триггер: изменение значения поля.
Условие: соответствие значения поля заданному значению.
Результат: добавление комментария к задаче.
У каждой организации есть постоянно обновляемый регламент по поддержке сервиса, расписанный не на один десяток страниц — что отвечать, к кому обращаться по разным вопросам, как обрабатывать запросы и т.д. Есть разные способы быстрого доступа к такой информации: организовать wiki, красиво залить все в Confluence (есть специальный раздел в JSD — База знаний) или выбрать другой удобный способ.
Постоянно обращаться к регламенту неудобно, особенно когда это мелкие и/или редкие вопросы, которые сложно запомнить — это могут быть и критически важные, и стандартные описания, которые удобно иметь под рукой.
Мы придерживаемся мнения, что ум должен быть свободен от ненужных фактов. И если по регулярному вопросу можно скопировать-вставить или, еще лучше, автоматизировать, — так и поступаем.
Для каждого типа запроса есть частые вопросы, решение которых строго регламентировано, поэтому мы добавили возможность получить подсказку через поле в задаче.
Сотрудник выбирает из выпадающего списка нужную тему, и в задаче появляется комментарий с процессом обработки запроса, шаблонами ответов и необходимыми ссылками, контактами.
Подсказки помогают и в крайних ситуациях. Если сотрудники поддержки недоступны, и обрабатывать запросы нужно руководителю или сотруднику другого подразделения, которые могли не делать этого месяцами.
В теле подсказки прописали автотекст для ответа клиенту, который можно просто скопировать и Ответить клиенту.
Поддержка не должна придумывать ответы. На любой запрос, в каком бы тоне он ни был, всегда должен быть вежливый и корректный ответ. Поэтому четкие формулировки на все возможные запросы — залог спокойствия пользователя и сотрудника. Написали грубо? Без лишних раздумываний и принятия на личный счет — копируем шаблон ответа и отправляем.
Сотрудник не должен отвлекать других расспросами на простые вещи — искать ссылки на регламенты, базы данных, инструкции. Ответы на простые вопросы должны быть доступны просто по вызову кнопки, и эти подсказки должны быть понятны.
Автоматическое создание задачи
Использовали такой тип автоматизации для отложенного создания задачи.
Триггер: запланированная периодичность.
Условие: JQL-фильтр по типу запроса, полю, исполнителю и др.
Результат: создание новой задачи с линком на текущую задачу.
Нашим регламентом любое действие, связанное с изменением существующих данных в сервисе, должно быть зафиксировано в Jira Service Desk.
У нас есть тип запроса, где нужно временно удалить данные из сервиса и в определенную дату вернуть их. Для таких случаев мы настроили автоматическое отложенное создание запросов.
Автоматическое создание задач происходит при ряде условий. Например, связанная задача завершена и в ней заполнено поле Когда создать новую задачу (или в нашем случае Когда вернуть объект?).
При создании автоматизаций не перегружайте их условиями. Удерживайте баланс между тем, чтобы задачи не создавались просто так, и тем, чтобы сотрудник не заполнял больше 1-2 полей.
В зависимости от того, когда нужно сделать связанную задачу, есть 2 способа автоматизации:
- Если связанную задачу нужно сделать в тот же день — триггером создания задачи будет переход родительской задачи в статус Готово (Done).
- Если связанную задачу нужно делать через какое-то время — автоматизация должна запускаться в заданную дату. Такой способ позволяет не нарушать SLA и формирует актуальную очередь запросов.
В нашей поддержке мы сделали автоматизацию по времени, в которой правило регулярно ищет задачи с условиями:
- по типу запроса,
- по кастомному полю,
- по соответствию даты в кастомном поле.
На примере это происходит так — каждый будний день в 9:00 утра правило ищет задачи по условиям:
- тип запроса — Удалить объект,
- причина удаления — Временно удалить,
- дата в поле Когда вернуть объект? — сегодня.
И как только находит совпадение — создает новую задачу со ссылкой на связанный запрос.
Проверка заполнения полей
В некоторых типах запросов критически важно заполнять какие-либо поля. Сотрудник может забывать это сделать даже после однократного напоминания. Например, к некоторым запросам может возникнуть необходимость вернуться спустя какое-то время.
В нашем случае сотрудник может забыть выставить дату, в которую должна быть создана связанная задача. Следовательно, задача не будет создана, и пользовательский запрос не выполнен корректно.
Для таких случаев мы выставили двукратную проверку заполнения — ежедневная и еженедельная.
Триггер: изменение статуса задачи на Готово (Done).
Условие: JQL-условие по типу запроса и дополнительное условие на наличие вложения в задаче.
Результат: добавление комментария к задаче с упоминанием исполнителя.
Если сотрудник забыл выставить дату, то ему придет уведомление об этом сразу после перехода задачи в статус Готово (Done). И если в суматохе не увидел уведомление — в течение недели придет повторный комментарий ему и руководителю проекта.
Автоматическое изменение статуса задачи
Применяем в нескольких случаях.
Получена новая информация от пользователя
Триггер: добавление комментария.
Условие: комментарий от клиента.
Результат: изменение статуса задачи.
Иногда мы не можем обработать запрос, пока не получим дополнительную информацию от пользователя. На этом этапе задача получает статус Ожидает согласования или Ожидает ответа клиента. Сотрудник сделал все, что от него требовалось. Далее запрос не будет обработан, пока не придет ответ.
Как только придет ответ от любого пользователя — автора или Request Participants, то статус автоматически меняется на Ожидает ответа поддержки. Теперь запрос можно брать в работу.
Для удобства настроили специальный вид (view settings), где сотрудник видит задачи только в статусе Ожидает ответа поддержки.
Запросы, где нужно ответить пользователю, всегда в приоритете, так как мы соблюдаем внутренние стандарты SLA.
Клиент не отвечает на сообщения
Триггер: запланированная периодичность с JQL-фильтром.
Результат: изменение статуса задачи.
Если в запросе мы ждем информацию от автора или Request Participants, то автоматизация на следующий день отправляет напоминание о необходимости дать ответ поддержке. И еще через день проверит, пришел ли ответ. Если ответ так и не поступил — задача автоматически переводится в статус Готово (Done).
Проверка наличия вложений в задаче
Мы использовали такой тип автоматизации для задач, где нужно отслеживать визуальное изменение в сервисе, и сотрудник всегда должен загружать скрин перед закрытием задачи.
Триггер: изменение статуса задачи на Готово (Done).
Условие: JQL-условие по типу запроса и дополнительное условие на наличие вложения в задаче.
Результат: добавление комментария к задаче с упоминанием исполнителя.
В сервисе могут храниться уникальные данные, и любое изменение, удаление или восстановление таких данных следует подкреплять — для истории и последующих действий — скриншотами от сотрудника поддержки.
В помощь сотруднику мы настроили автоматизацию, которая отправляет в Комментарии задачи уведомление, если скриншоты не загружены.
В зависимости от процессов мы используем разные способы контроля. Наличие вложения в задаче не является обязательным, — это рекомендация, которая упрощает работу.
В случае же критически важного процесса такая форма контроля не подойдет, и нужно использовать, например, блокирование задачи, если обязательное условие не выполнено.
Всегда есть место для улучшений
Мы рассказали про основные автоматизации, которые внедрили в своем сервисе. В следующей статье расскажем про кастомные автоматизации, которые помогают в обработке запросов, если вы подключаете Jira Service Desk по API.
Попробуйте наши рекомендации по настройке автоматизаций, а если нужна помощь — напишите нам!
