Обработка тикета с ДТП для беспилотных такси

Задача

Спроектировать сценарий отработки тикета с ДТП для инженеров сервиса мониторинга беспилотных такси

Аудитория. Джобы пользователей

Т‑Банк запускает новый продукт на рынок — беспилотное такси. Пользователи сервиса — инженеры центра. Сервис помогает отслеживать состояние автомобилей, выявлять проблемы и быстро реагировать на инциденты.

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

Процесс

Сначала — дискавери. Изучила, чем обычно занимается сотрудник центра мониторинга, какие задачи решает в течение рабочего дня.

Чем занимается сотрудник центра мониторинга и какие задачи решает в течение дня

Узнала, как технически устроены сервисы мониторинга беспилотных машин:

За каждым сотрудником закрепляется определённое количество машин, обычно 20–30
Функционал пользователей разделён по ролям: линейные инженеры следят за машинами, руководители центров управляют списками сотрудников и автомобилей, контролируют оплату штрафов, изучают отчётность
Данные об автомобиле обновляются каждые 5 секунд: они передают информацию о местоположении, уровне заряда батареи, текущем статусе (в поездке / свободен / на зарядке / вне сервиса), наличии ошибок и технических неисправностей
В сервис интегрированы GPS/ГЛОНАСС‑трекинг и карты: в будущем можно подключить платёжную систему для оплаты штрафов, интегрировать подробную телематику для авто

Джоба задачи с обработкой критичного тикета получилась такой:

Джоба: как инженер центра мониторинга я хочу видеть варианты решения критичных тикетов, чтобы оперативно подключаться к решению ситуации и избежать ошибок

Следующий этап — референсы решений. Изучила прямых и косвенных конкурентов, поресёрчила паттерны, которые можно использовать в нашем сервисе.

Референсы: интерфейсы мониторинга автопарка, карточки заказов и функциональные возможности конкурентов

Дальше можно детализировать user flow.

Кейс: система фиксирует возможное столкновение или поступает тикет от службы поддержки

Пользователь открывает главный экран мониторинга
Открывает тикет с критичным приоритетом «Обнаружено столкновение»
Пытается связаться с пассажиром
Если пассажир не отвечает или ему требуется помощь — вызывает скорую. Если с пассажиром всё хорошо — меняет машину заказа
Отправляет на место инженера быстрого реагирования: он изучает повреждения машины, вызывает соответствующие службы и контролирует ситуацию на месте
Закрепляет критичный тикет в общем списке, чтобы продолжать его отслеживать
Когда ситуация разрешена — закрывает тикет

Первая версия экранов

Первая версия: экран общего мониторинга и карточка автомобиля

При проектировании такого высоконагруженного интерфейса важно было как можно быстрее получить обратную связь от пользователя — поэтому я пошла за мнением своих друзей и провела UX‑тестирование:

UX-тестирование: вопросы респондентам, подтверждённые и неподтверждённые гипотезы и выводы

Часть гипотез не подтвердилась. Вторую версию я проработала с учётом полученной обратной связи.

Результат

Итоговый сценарий обработки критичного тикета: от открытия тикета до его закрытия

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

Чтобы отследить эффективность сервиса, я бы предложила замерять:

Time to Value: сколько времени проходит от старта (логин в сервисе) до получения «первой ценности» (например, решение тикета)
Activation/First Value: как быстро новичок совершил первое полезное действие
Time to Resolution: среднее или медианное время от создания тикета до решения
First Call Resolution: доля кейсов, решённых с первого раза, без повторных звонков и обращений

Выводы

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