Дизайн клиентского портала и его интеграции с CRM-системой для ЛУКОЙЛа — одной из крупнейших нефтяных компаний России. Я был единственным дизайнером на проекте и вёл его от первых вайрфреймов до релиза в продакшен.
Год
2025
Клиент
Lukoil
О Проекте
ЛУКОЙЛ — вертикально интегрированная нефтяная компания с собственными НПЗ и большой сбытовой сетью: тысячи АЗС и десятки нефтебаз, присутствие в нескольких десятках стран. За оптовыми и корпоративными продажами нефтепродуктов стоит большой поток B2B-сделок, который раньше вёлся в основном вручную через менеджеров.
Lukoil B2B Trade — внутренний проект: онлайн-портал, через который корпоративные клиенты работают с поставками напрямую. Они оформляют заказы и разнарядки, отслеживают статусы сделок, обмениваются документами и общаются со своим менеджером. До портала вся эта работа шла через менеджеров вручную: звонки, почта, таблицы.
Портал — это клиентская витрина поверх большой внутренней CRM (ЭлКом). Почти каждый экран опирается на данные из CRM и должен оставаться с ней синхронным в реальном времени: каталог, договоры, цены, остатки объёмов, статусы заказов и разнарядок.
Отрасль накладывает свою специфику. Здесь нет «положил в корзину и оплатил». Есть несколько типов клиентов (НХ, НП, СУГ), разные базисы поставки, привязка цен к конкретной сделке, дополнительные сущности вроде разнарядок и доверенностей на грузополучателя, и жёсткие правила доступа на уровне договоров.
Моя роль: единственный продуктовый/UI-дизайнер. Команда: разработка, системные аналитики, проектные менеджеры со стороны исполнителя и заказчика. Статус: в продакшене, клиенты пользуются.
Проблема
Заказчик пришёл с объёмным документом функциональных требований: десять разделов, от регистрации и управления доступом до финансовой сверки, документооборота и сервисного сопровождения. Требования описывали, что система должна уметь, но не как это должно выглядеть и работать для клиента.
Основные сложности:
Высокая связанность с CRM. Портал почти ничего не хранит сам. Каталог, договоры, цены, статусы, остатки приходят из ЭлКом. Интерфейс нужно было строить так, чтобы он честно отражал состояние системы и не вводил клиента в заблуждение, когда данные ещё не подгрузились или сделка в промежуточном статусе.
Сложная доменная модель. Заказы, разнарядки, договоры (активные и завершённые), индекс благонадёжности, статусные модели под разные категории клиентов. Всё это нужно было уложить в понятный неподготовленному пользователю интерфейс.
Жёсткие правила доступа. Видимость каталога зависит от действующего договора. Клиент без действующих договоров может загружать документы, но не оформлять заказы. Заблокированный клиент не может войти вовсе. Эти состояния нужно было спроектировать явно, а не оставлять на «пустой экран».
Длинные процессы с черновиками. Подача заявки на сотрудничество, загрузка пакета документов на договор, формирование разнарядки — это многошаговые сценарии, которые клиент должен мочь прервать и вернуться к ним позже.
Решение
Я разбил систему на крупные смысловые области и проектировал её по разделам, сверяясь с требованиями и аналитиками на каждом шаге.
Вход в систему и онбординг. Спроектировал путь от заявки на сотрудничество до активного личного кабинета: форма заявки с автозаполнением по ИНН, загрузка подтверждающих документов, обработка дублей, активация по письму со сменой временного пароля. Каждое состояние клиента (потенциальный, без договора, активный, заблокированный, отказано) получило понятное отражение в интерфейсе.
Сделки и разнарядки — ядро портала. Сценарии создания заказа и разнарядки с выбором действующего договора, отображением цен по ценовому приложению, стоимости транспортировки и остатков объёмов. Сделал повторное оформление и копирование прошлых заказов, потому что закупки здесь регулярные и однотипные. Статусы заказов и разнарядок синхронизируются с CRM и показываются клиенту в его модели понятий.
Каталог и договоры. Иерархия каталога, в которой видимость разделов зависит от договора клиента. Фильтры и сортировки с сохранением состояния между сессиями. Списки активных и завершённых договоров с понятным запретом выбирать неактивные.
Документы и финансы. Единая форма загрузки пакетов документов с обязательными и необязательными типами, сохранением черновиков и отправкой позже. Загрузка доверенностей с привязкой к разнарядке. Отображение файла сверки взаиморасчётов.
Сервис. Формы обращений и претензий с привязкой к заказу, вложениями и сквозными статусами. Раздел справочной информации, уведомления, анкетирование.
Платформа. Десктопная браузерная версия. Это внутренний инструмент для работы со сделками, основной сценарий это работа за компьютером, поэтому адаптив под мобильные в рамках проекта не делался.
Рабочий процесс
Старт — с переданного документа требований. Дальше вайрфреймы и первые черновики, обсуждение общей логики. Затем работа по разделам: проектирование, сверка с аналитиками и разработкой, уточнение пограничных состояний, доведение до макетов в продакшен-готовности. Постоянная коммуникация с большой кросс-функциональной командой, чтобы дизайн ложился на реальные возможности интеграции и бизнес-процессы CRM.
Что сделано
Полный UX/UI клиентского портала: от онбординга до сервисного сопровождения, все десять функциональных областей.
Проектирование сложных многошаговых сценариев с черновиками: заявка на сотрудничество, пакетная загрузка документов, формирование разнарядок.
Интерфейсы, синхронные с CRM: каталог, договоры, цены, остатки, статусы заказов и разнарядок.
Система состояний доступа клиента, проработанная явно на уровне интерфейса.
Логотип проекта.
Работа единственным дизайнером в большой команде разработки, аналитики и проектного менеджмента.
Результат: портал запущен в продакшен, клиенты компании работают в нём с реальными сделками.