Как построить цифровую экосистему для аренды автомобилей

Компания OILA работает в сегменте аренды автомобилей с правом выкупа, кредитования, рассрочки и продажи транспорта. Среди ее клиентов — частные лица, корпоративные автопарки, сервисы доставки и индивидуальные предприниматели. География присутствия компании — Санкт-Петербург, Москва и Крым.

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

Шаг 1. Спроектировать единый цифровой контур

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

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

Шаг 2. Автоматизировать каталог автомобилей

Один из наиболее уязвимых участков — каталог автомобилей. До старта проекта он велся в Excel, что делало процесс обновления долгим и повышало риск ошибок. Из-за этого пользователи могли видеть неполные или неактуальные данные, а сотрудники тратили ресурсы на постоянную ручную актуализацию информации.

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

Шаг 3. Перевести бронирование в онлайн

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

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

Шаг 4. Разработать мобильное приложение

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

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

Шаг 5. Создать личные кабинеты для частных и корпоративных клиентов

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

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

Шаг 6. Добавить калькулятор расчета условий сделки

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

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

Шаг 7. Упростить внутреннюю работу команды клиента

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

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

Шаг 8. Выстроить поэтапную разработку

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

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