М — мобильные приложения

Delta Marine

Существенно облегчили процесс релокации сотрудников

Крюинговое агентство “Delta Marine Crewing” работает с судовладельцами из Европы и Дальнего Востока, полностью управляя их экипажами.

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

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


Предпроектный анализ

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

Составили упрощенную схему, которая показала нам, что агент занимает значительную часть процесса.

Чтобы сократить время на бронирование, было предложено исключить из процесса тревел-агента, позволив менеджерам самим заполнять заявку и отправлять запросы на сервисы метапоиска билетов.

При общении с менеджерами выписал необходимые данные, которые обязательны для бронирования билетов:

— название судна;
— флаг судна;
— местоположение судна;
— дата смены экипажа;
— кол-во прилетающих в город местоположения судна;
— откуда прилетают;
— кол-во вылетающих из города местоположения судна;
— место назначения вылетающих.

Также были полезны ответы на вопросы:

Какова разница в днях между поиском рейсов и реальной релокацией персонала?
— От 4 недель до 1 дня. В среднем где-то за 14 дней до смены

Есть ли ограничения на количество вылетающих/прибывающих людей или количества одновременно забронированных рейсов?
— Нет, но приходится разделять запросы бронирование на вылет и прилет сотрудников.

Есть ли постоянные смены членов экипажей?
— Да, есть. Было бы неплохо обращаться в какой-нибудь архив или историю релокаций экипажей.

Составили схему ожидаемого результата бронирования

Так как менеджер часто находится в разъездах и имеет при себе корпоративный телефон (iPhone), приняли решение спроектировать мобильное приложение на iOS.

Проектирование

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

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

Заполнение данных о релокации

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

Заполнение данных о направлении

На этом экране пользователь вводит название аэропорта или города откуда (или куда) будет происходить релокация. Экран разделен на две части: верхняя – содержит данные о необходимых рейсов из текущей локции судна, нижняя – откуда сотрудников необходимо доставить.

Пользователь имеет возможность ввести как название конкретного аэропорта (данные подтягиваются сразу же через автокомплит), так и название города – в таком случае просто увеличивается количество результатов поиска.

Проверка введенных данных

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

Выдача результатов

Экран результатов содержит список доступных рейсов с указанием направления, времени перелета, количества пересадок, мест и ценой билета

Подтверждение выбора

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

Еще проще

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

В процессе теста узнали важную деталь – ни сотрудников судна, ни менеджеров, которые занимаются релокацией, совсем не интересует стомость билета и время отправки самолета, т.к. сама крюинговая компания готова покупать билеты любой стоимости (но только в эконом классе).

Это позволило нам совсем отказаться от экранов результатов поиска и перенести всю логику бронирования на бэкенд.

Также пользователям было предолжено отказаться от «пошагового» заполнения данных, разместив всё на одном экране. Это позволит избавится от экрана подтверждения и облегчит добавление и редактирование информации, т.к. сразу все данные будут перед глазами.

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

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

Наверх