О проекте
Монополия – логистическая платформа, которая обьединяет участников рынка автомобильной логистики в цифровой среде с помощью сервисов и технологий. Участники разделены на роли, каждая роль закрывает свою бизнес-потребность.
Задача
Глобально задача состоит в том, что бы увеличить вывозимость грузов в кабинете перевозчика, посредством завлечения пользователя в череду цепочек в взятия груза, используя механику решения простой транспортной задачи, через пользовательский интерфейс, имея ограничения в отсутствии функции бронирования
Пояснение
Перевозчик часто приходит на платформу, для поиска заявки в одно плечо (т.е откуда он выехал, из пункта отправления в пункт прибытия, туда он и возвращается). Это обусловлено некоторым количеством факторов одни из и самые частые:
1) Знакомый маршрут — знакомая дорога, привычные места стоянки и заправки, безопасность, удобство.
2) Популярность направления — место последней разгрузки не должно создавать проблем с новой погрузкой на пути к дому. Т.к простой обходится дорого, пустой пробег удваивает расход.
3) Финансовый — бизнес строится на амортизации транспорта, ресурса водителя. Это должно быть выгодно.
Процесс
Описание
У пользователя в момент подбора заказа есть ключевые разделы и точки соприкосновения с интерфейсом. Фактически это рабочий инструмет, который закрывает полностью весь бизнес-портебности перевозчика
Интерфейс кабинета перевозчика представляет из себя флоу взятия заявки:
— Общий грид — фильтры и карточки заявок на вывоз груза (как карточки товара основная информация о заявке и цена)
— Заявка — она делится на просмотровую версию (информация о заказе, маршрут, цена) и версию оформительскую, где перевозчик выбирает договор (опционально) вид оплаты и назначает подвижной состав (машина, водитель, прицеп)
— Успех — Экран успешного успеха (говорим, что заявка оформлена). Далее редиректим в мои перевозки или на поиск новых грузов
Гипотеза 1
Анализируем точки соприкосновения пользователя и интерфейса в прямом сценарии .Важно соблюсти баланс, для того, что бы ничего не мешало пользователю закрыть главную потребность — акцептовать заявку.
Дополнительные карточки — Предполагаем, что если будем показывать дополнительные карточки с грузами обратного направления, это не только увеличит конверсию, но и увеличит количество непрерывных заказов у перевозчиков
Тезисы
Идея кажется отличной и простой, но после начинаем рассуждать и приходим к целой пачке минусов:
— А что если грузов в обратном направлении не будет? Что будем показывать?
— А что если цена предложенных заявок не устроит?
— А что если обратный рейс не будет попадать во вменяемый временной интервал, показывать ближайшие?
— А если ближайшие рейсы не в интервале, показывать то, что географически дальше?
— А что если грузов в обратном направлении не будет? Что будем показывать?
— А что если цена предложенных заявок не устроит?
— А что если обратный рейс не будет попадать во вменяемый временной интервал, показывать ближайшие?
— А если ближайшие рейсы не в интервале, показывать то, что географически дальше?
Заключение
Идея кажется отличной и простой, но после начинаем рассуждать и приходим к целой пачке минусов:
— А что если грузов в обратном направлении не будет? Что будем показывать?
— А что если цена предложенных заявок не устроит?
— А что если обратный рейс не будет попадать во вменяемый временной интервал, показывать ближайшие?
— А если ближайшие рейсы не в интервале, показывать то, что географически дальше?
— А что если грузов в обратном направлении не будет? Что будем показывать?
— А что если цена предложенных заявок не устроит?
— А что если обратный рейс не будет попадать во вменяемый временной интервал, показывать ближайшие?
— А если ближайшие рейсы не в интервале, показывать то, что географически дальше?
Гипотеза 2
Через модалку после акцепта — Предлагаем вовлечь пользователя в цепочку оформления рейсов. До успешного успеха, предлагаем обратный рейс, если он есть, уводим его во флоу акцепта.
Тезисы
Гипотеза с выводом модального окна в случае если есть подходящие заявки кажется не плохой, но снова приходим к тому, что колличество нужных рейсов попадающих под узкую выборку параметров ограничивающих выбор географически или по временному интервалу могут стать не столь примечательными и очевидными для пользователя.
Заключение
Фиксируемся на том, что выдача слишком маленькая, пользователю ничего не мешает проспидранить этот шаг и пойти искать груз переключая параметры фильров на странице главного грида.
Фиксируемся на этой мысли и идём делать ещё заход.
Гипотеза 3
Решаем пойти на крайне дерзский и экстримальный шаг. Просто в конце акцепта на экране успешного успеха вешаем кнопку «Подобрать обратный рейс»
Тезисы
Делаем вывод, что у нас уже есть инструмент для отличной выдачи подходящих параметров которые работают по уже готовому и удоваримому алгоритму подбора подходящего рейса: — это основной грид с заявками, в котором просто будут проброшены фильтры в которых первая точка начала рейса — это конечная точка маршрута нужной заявки. Фиксируемся на дате +12 часов (входные данные).
Заключение
Вся выдача будет формироваться исходя из тех заявок которые в данный момент есть на платформе, оставляем за пользователем возможность самому дофильтровывать нужные параметры, и ориентироваться по выдаче. С минимальными по тайм-ту-маркет параметром (фактически добавить кнопку) вовлекаем пользователя в цепочку поиска обратного рейса посредством ридеректа в выдачу с предаполненными фильтрами.
Итоги
Зафиналили макеты с командой. Оценили, реализовали, протестировали, раскатали на прод, обвешали событиями, ждём результатов. Дополнительно добавили кноку в карточке акцептованной заявки в Моих перевозках
— За квартал — количество вывезенных грузов увеличилось на 40%.
— В денежном эквиваленте, данная фича увеличила прибыль на 12 мнл.руб.
— На 48% увеличилось количество заказов, когда перевозчик идёт искать обратный рейс сразу после оформления заявки
— В 68% случаев перевозчик после того как заявка находится в процессе выполнения приходил в Мои перевозки (для того что бы начать искать обратный рейс) находил заявку и акцептовал ее.
Контакты