Если обращения клиентов в техподдержку редки, то контроль реакции на заявки не представляет сложности — все на виду. Ситуация меняется, когда заявок становится много. Пропорционально звонкам и сообщениям растет нагрузка на персонал: сохранять эффективность взаимодействия в нон-стоп режиме становится непростой задачей. И тут нам потребовалось объединить Jira на разных серверах, чтобы решить эту задачу.

Проблема

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

Задача была сформулирована так: создать и автоматизировать единую рабочую среду, связав заявки из первой и второй линии техподдержки с тикетами разработчиков на третьей линии.

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

• первый — с тикетницей для первой и второй линии (Service Desk);
• второй — с Jira для разработчиков.

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

С точки зрения стабильности и безопасности IT-инфраструктуры разделение систем — это грамотный подход: так легче управлять правами доступа, настраивать VPN и фаерволы, делать бэкапы, обновлять и восстанавливать базы после аварий. 

В стандартном виде эшелон поддержки состоит из трех линий:

1. Первая — решает типовые задачи, поддерживает прямой контакт с клиентом, классифицирует и распределяет запросы по исполнителям.
2. Вторая — обладает более глубокими правами и компетенциями, подключается при эскалации проблемы. Специалисты принимают тикеты от первой линии, проводят диагностику. Если возможно, решают задачу, фиксируя результат и закрывая заявку, если нет, делегируют на следующий уровень.
3. Третья — квалифицированные разработчики. Сюда передаются особо сложные и масштабные инциденты, здесь проводится их диагностика, анализ и поиск решений.  

В нашем случае инженеры на третьей линии были вынуждены вручную создавать задачи в Jira, а затем также, «руками» изменять их статус. 

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

Решение

В процессе сбора интеграционных спецификаций нами были сформулированы следующие требования к проекту:

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

Для, того чтобы объединить Jira на разных серверах было решено использовать веб-хуки.

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

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

Этапы настройки

Автоматизация, отправляющая запрос из Service Desk в Jira разработчиков.

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

Устройство связи (панель разработчиков Service Desk): события, на основании которых Jira переносит задачу в статус проверки.

Автоматизация про перенос в чек (работает как приемник). 

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

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

Обратите внимание: механика взаимодействия полностью построена на базе инструментов Jira. Отсутствие необходимости в придумывании «костылей» с написанием кода, значительно сократило время и стоимость разработки.

Результат

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

Преимущества интеграции:

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

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

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

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