Привет, Хабр! Сегодня хочу поделиться с вами опытом, как мы повышаем качество сервиса вычислительного оборудования наших клиентов и оптимизируем работу команд Центра компетенций по сервису в КРОК. Ранее я уже писала про автоматизацию работы со складом ЗИП. А сегодня будет нестандартная история, когда решение, придуманное для удобства клиентов, затем раскатывается на сотрудников компании.
В новой статье поделюсь, как мы в направлении создали и внедрили клиентский портал для работы с заявками на обслуживание и ремонт оборудования – прозрачный, удобный и быстрый. Расскажу, как выдерживать нужный уровень SLA с максимальным удобством и вовлечением заказчиков, организовывать комфортную и эффективную работу поддержки и еще про разные фишки нового решения.
Сначала с заявками все работали в обычной Jira
Представьте службу поддержки любой крупной сервисной компании. Примерно так у нас все и работает — процесс приема и обработки заявок на обслуживание или ремонт оборудования в целом стандартный:
Заказчик отправляет email или создает заявку в Jira — нам поступает запрос со статусом new. Его подхватывает круглосуточная первая линия, а дальше смотрим серийный номер: бьется или не бьется, на поддержке или нет, дополняем заявку информацией и передаем профильным инженерам.
Подключается инженер. При необходимости он проводит дополнительную диагностику, заказывает запчасти и двигает заявку дальше из одного статуса в другой: в работе, ожидает доставки и т. д.
Когда работы завершены, заказчику уходит уведомление с просьбой оценить работу. Для него на этом путь заканчивается, а для нас может продолжаться.
Инженеры сдают непотребовавшиеся запчасти на склад, тестируют железо и анализируют причины инцидента. После мы отправляем заявку на закрытие со стороны инженера.
Наконец первая линия оценивает работу инженера и закрывает запрос окончательно. Дальше – архив: мы храним всю информацию о заявках как минимум на протяжении трех лет.
По данным за 2023 год, у нас было 10 607 сервисных заявок: неисправностей, подразумевающих замену или ремонт оборудования, запросы на обслуживание и профилактику, консультационные вопросы. Это 2 652 заявки в квартал, 884 в месяц, 204 в неделю, в среднем 29 заявок в день и 0,02 в минуту.
Львиная доля из них поступала через клиентский портал на базе Jira Service Desk, на который мы перешли в 2021 году с HPSM, устаревшего legacy-решения, работающего только на десктопе и с проблемным процессом обновления. Jira вобрала в себя массу процессов внутри компании. В ней ведутся все проекты, инженеры не распыляются на 10 сервисов по заказу-отправке запчастей и решению заявки, а клиенты могут за всем этим наблюдать. И все бы хорошо, но к Jira тоже стали копиться вопросики.
Компании и инженерам удобно, а заказчикам не очень
Через Jira Service Desk заказчики создавали заявки, видели их историю, статус и исполнителя, комментировали ход работ и подключали новых участников процесса. Получалось функционально, но не всегда удобно. Все чаще возникали вопросы к информативности заявок и корректности отображения полей, но самой острой проблемой стал вопрос разграничения доступа.
У внутреннего портала Jira есть особенность: там видны все проекты, которые ведет КРОК. Они доступны всем заказчикам, и это плохо. Никакой конфиденциальной информации клиент не увидел бы, но он мог создать заявку в чужом проекте, кликнув не туда, и остаться в полной уверенности, что все окей и поддержка скоро со всем разберется. А там другое направление, другой департамент, который не в курсе, что происходит. И вроде никто не виноват. Но на то, чтобы во всем разобраться, уходило дополнительное время, а ведь SLA может быть жестким.
Кроме того, Jira недоступна в периоды обслуживания, при перевнедрениях и обновлениях. А это важно: мы оказываем поддержку 24/7 и клиент рассчитывает на то, что портал будет доступен в любое время.
Задумались о разработке отдельного клиентского решения
Итак, мы нуждались в новой витрине для клиентов, где они будут менеджерить заявки. Нужно было вывести туда больше полезной информации и таким образом снять частые вопросы о:
статусе заявок;
частоте обращений;
SLA и сроках оказания услуг;
общем числе заявок по различным типам оборудования и по договору в целом.
Еще хотелось дать заказчикам больше самостоятельности — сделать так, чтобы они могли сразу заполнить форму, выбрать тип инцидента, указать приоритет, описать, что случилось и добавить участников запроса при необходимости.
Коробочный Jira Service Desk кастомизировать довольно сложно, особенно так, чтобы на выходе получить приемлемое юзабилити. Трудозатраты на что-то красивое и удобное были бы огромные, так что мы решили написать новый фронтэнд с нуля. Этому способствовала и наша постоянная практика развития клиентского сервиса, на который выделяются ресурсы и есть отдельная команда фронтенд-разработки специально для задач компании — развивать и подстраивать внутренние системы под новые процессы.
Что хотели сделать и как поменять
Для начала все приоритизировали и взяли в работу только пункты наивысшего приоритета, чтобы успеть реализовать MVP, сделанный по всем правилам. Составили таблицу с функциями, которые хотим перенести в новый портал – что добавить, какие баги закрыть. Основной задачей стала разработка нового, более доступного и дружелюбного, интерфейса для работы заказчиков с заявками.
Нам нужно было сохранить функциональность старого портала плюс закрыть упомянутые выше вопросы: нежелательную доступность всех проектов компании, невозможность выводить дополнительные информационные поля для клиента о его заявке (договор, серийный номер или SLA, описание решения и другие).
Мы это сделали, сохранив все, что удобно работало и раньше. Создали настройку, которая по API обращается к самой Jira и работает с теми же самыми заявками. Не нужно создавать дополнительно никаких сущностей — все это просто визуально красивое отображение тех же заявок, с которыми привыкли работать инженеры, и для которых уже выстроен бизнес-процесс.
Как все организовано, что и как пришлось допилить
У Jira открытый API, и с его помощью безо всяких прослоек портал получает данные из Jira и наоборот, может записывать их в Jira, создавая запросы или добавляя комментарии.
Однако, для реализации всех наших хотелок этого было мало. В итоге мы пользуемся базовыми возможностями этого интерфейса, вроде регистрации, авторизации, создания запросов, а перед этим обрабатываем заявки на бэкенде нового портала. Бэкенд написан на Java (Spring Boot), фронт — с использованием HTML, TypeScript, Angular.
Например, на новом портале мы доработали кнопки для удобного перехода по бизнес-процессам. С их помощью заказчик может отменить свою заявку, оценить, если она уже решена, или привлечь внимание, если проблема стала острее, а если что-то пошло не так — эскалировать. Вроде бы простая вещь, но стандартный API не дает извне переходить по бизнес-процессу, пришлось писать под них свою логику.
Самым большим вызовом было заставить портал работать быстро и отзывчиво. На первый взгляд это кажется не особо сложной задачей, но как только мы сменили логику на ролевую, отличную от стандартной Jira, началась боль. Еще и JQL поиск работал медленнее, чем нужно, а Java API для Jira Service Desk очень ограничен в функциональности. Пришлось делать все с нуля и думать над оптимизацией SQL-запросов. Кроме того, чтобы добиться нужной скорости, пришлось бодаться с многопоточностью.
Еще из интересного с технической точки зрения можно выделить реализацию переводов. Так как функциональность Java API для Jira Service Desk ограничена, пришлось разбираться в структуре таблиц БД для переводов, чтобы доставать актуальные переводы для различных полей. Кроме того, пришлось подкрутить туда Google Guava, чтобы кэшировать уже найденные переводы и не тратить дополнительное время на их поиск.
Впрочем, у Jira в роли бэкенда есть и преимущества. Она удобна тем, что внутри все кастомизируется. У нас получилось сделать так, что для добавления новой кнопки или поля на клиентский портал не нужно лезть на фронт. Все настраивается в Jira и подтягивается из проекта. В результате наши менеджеры из разных подразделений могут настраивать функциональность своих разделов клиентского портала через привычный интерфейс.
Тесты и подготовка к запуску
Все это пришлось делать очень оперативно. Хотя обновление клиентского портала назревало давно, у нас было довольно ограниченное время на запуск и внедрение. Подготовили кликабельные макеты, тестировали, выбирая варианты списков, форм запроса — к UI отнеслись ответственно с точки зрения разработки новой системы. Автотесты написаны на Java 11, используется сборщик Maven. Фреймворк написания тестов — TestNG, также используется Selenium WebDriver. Автотесты проходят по функционалу клиентского портала в UI. Сейчас покрыто примерно 75% от всех регрессионных тестов на клиентском портале.
UX-тестирование проводили на сотрудниках КРОК, не относящихся к сервисным подразделениям. Компания большая, и можно пойти к условным бухгалтерам и собрать с них непредвзятое мнение.
Про особенности переезда
Сперва про переезд рассказали не всем: за пару месяцев до запуска выбрали активных авторов заявок и написали им письма с предложением протестировать новый клиентский портал. При этом оговорили, что старый сервис тоже работает, и все ссылки пока ведут на него. Фидбэк собирали через простую форму с возможностью выставить оценку и написать отзыв.
Так пользователи подсветили немало проблемных мест:
«Старые кейсы не сохраняются. Хочу посмотреть, что и как делали: скрины, логи, рекомендации. Ситуации, бывает, повторяются, а кейса нет уже на портале»
«Когда в Jira по почте отвечают на кейс, статус не меняется, он висит в статусе ожидания клиента. При этом непонятно – будто ждут действий, а по факту кейс в работе у инженера»
«Есть ограничения по загрузке. При загрузке больших логов инженер отдельно присылает ссылку для выгрузки. А хорошо, если бы это было в рамках заявки – что-то можно в саму заявку кинуть, а большой файл выгрузить по ссылке в заявке в облачный диск минуя инженера»
Постепенно и с учетом обратной связи стали переводить на новый портал и другие проекты, менять ссылки в письмах авторам и участникам запросов. По ним первым делом мы ввели пользователей в новый портал. А следующим этапом на старом портале Jira поставили баннер, что здесь скоро ничего не будет — переезжаем.
Клиенты до последнего пытались пользоваться старым порталом — сила привычки. Были ситуации, когда они приходили к сервис-менеджеру и просили сделать как было, потому что непривычно.
Мы не стали дожидаться, пока все привыкнут — закрыли наш старый портал, когда убедились, что собрали и учли всю конструктивную критику. Жесткий шаг, но некий процент пользователей всегда будет держаться за старое и привычное. И проще рубануть с плеча, чем неопределенно долго поддерживать две версии приложения.
Главные фишки и профиты клиентского портала
Впрочем, сложности того стоили. Теперь портал обеспечивает полное и своевременное информирование клиента. В интерфейсе детально отражается все, что происходит с заявкой.
Так, например, раньше портал оповещал клиента о том, что запчасть отправлена. Теперь же в интерфейс выводятся стадии доставки. В планах интеграции с курьерскими службами и отслеживание отправления.
У заказчика появилась возможность эскалировать заявку, привлечь к ней внимание или отменить.
Клиенты говорили, что не пользуются комментариями, потому что неудобно. Теперь вся история комментариев выводится в интерфейс. Есть вложения и выгрузки: можно выбрать необходимые поля, посмотреть все заявки своей организации и выгрузить их. Раньше это было возможно только по запросу через сервис-менеджеров службы поддержки. А сейчас заказчики могут делать это сами в пару кликов.
Появилась возможность развивать и кастомизировать функциональность портала — добавлять фишки, которых в старой версии service desk не было и быть не могло. Например, индикаторы-отметки для нового контента.
Результаты тестирования и планы на будущее
Еще на этапе проектирования мы понимали, что нужно будет собирать метрики по ключевым функциям системы: количество людей, начавших, но не закончивших регистрацию, недописанные заявки и не дошедшие до конверсии заказчики, которые решили сразу звонить на первую линию поддержки. Все это мы сохраняем, ведем и отслеживаем. Месяц спустя после внедрения мы сделали отчет и поняли, что создание запроса работает плохо.
Заказчики не спешат создавать заявки на новом портале, а в основном пользуются просмотром и комментированием уже созданных. Мы увеличили скорость обработки заявки после создания, посмотрели в сторону добавления полей, убрали баги, которые нам присылали через форму обратной связи.
Буквально на днях мы запустили мобильную версию портала и планируем открытие личного кабинета заказчика. Помимо мелочей вроде смены имени там будут доступны и пакетные действия, например, можно будет поменять контакты во всех связанных заявках компании. Это еще одно пожелание, которое мы получили через обратную связь. Оно особенно актуально для тех клиентов, которые локализуются в России и вынуждены менять почтовый домен, или, например, основательно перестраивают корпоративную телефонию. Вроде бы незначительная фича, но экономит много времени, ведь иначе пришлось бы перерегистрировать все аккаунты компании на портале.
Мы уже закрыли весь пул блокирующих и критических требований и пришли к тому, что разрабатываем фичи для удобства. В результате, по подсчетам нашего Центра компетенций по сервису, количество заявок от внешних пользователей стало расти: сразу после запуска, за период с января до середины февраля 2023-го, мы получили 80 заявок, а за тот же период с начала 2024 года уже 1 тысячу. Если в прошлом году 63% пользователей было довольно порталом, то к началу 2024 года этот показатель вырос до 74%. Оценки по отдельным аспектам клиентского опыта и в целом по порталу — положительные.
Более того, некоторые подразделения КРОК попросили развернуть аналогичные порталы для их нужд, чтобы создавать в них внутренние заявки на поддержку или заводить в Jira другие задачи. Созданный для клиентов сервис стал распространяться внутри компании — логичное развитие наших идей: постепенно автоматизировать, оптимизировать и улучшать сервисное обслуживание. Именно из таких, на первый взгляд незначительных мелочей, как клиентский портал, складывается положительный клиентский опыт.
Почитать еще про слагаемые сервиса КРОК:
Это база. Как прокачиваются сервисные инженеры КРОК
24 часа с дежурными инженерами КРОК: выживаем, как можем
Горы ЗИП. Почему наш склад ломится от оборудования и причем здесь ушедшие вендоры
