База знаний Практический материал

Архитектура сайтов дилерских групп: бренды, техника, запчасти, сервис и распределение заявок

Дилерский сайт объединяет несколько разных сценариев: выбор техники, сервис, запчасти и обращения в отдел продаж. Разбираем, как проектировать такую архитектуру на основе реальных проектов Меркури РУС.

О материале
  1. Практическая статья
  2. Mercury RUS
  3. Обновлено: 10.08.2026

Дилерский сайт объединяет несколько разных сценариев: выбор техники, сервис, запчасти и обращения в отдел продаж. Разбираем, как проектировать такую архитектуру на основе реальных проектов Меркури РУС.


Сайт дилерской компании быстро перестаёт быть просто страницей о компании. В проектах Меркури РУС для дилеров коммерческой техники на одном цифровом ресурсе пересекаются несколько самостоятельных задач: выбор новой или подержанной техники, изучение конкретных моделей, запись на сервис, поиск запчастей, консультация и отправка заявки в отдел продаж.


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


Один дилерский сайт — несколько разных сценариев


В проектах для «РязаньСкан» и «ВолгаАвтоТрейд» структура сайта строилась вокруг трёх крупных направлений: продажа техники, сервисное обслуживание и запчасти. Для каждого из них нужен свой путь пользователя.


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


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


Мультибрендовая структура: от марки к конкретной модели


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


В проекте «ВолгаАвтоТрейд» каталог предусматривал фильтрацию по маркам, моделям, годам выпуска и состоянию автомобиля — новый или с пробегом. Карточки моделей включали технические характеристики, фотографии и видеообзоры. Отдельно был предусмотрен калькулятор лизинговых условий.


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


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


Техника, сервис и запчасти — самостоятельные маршруты


В проектах Меркури РУС эти направления отличаются не только контентом, но и функциональностью.


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


Запчасти также могут формировать отдельный сценарий. В этом же проекте был предусмотрен поиск по VIN-коду или названию, фотографии и описания деталей и возможность оформить заказ онлайн. В проекте «РязаньСкан» раздел запчастей также включал онлайн-заказ.


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


Заявка должна проектироваться вместе с процессом продаж


Форма на сайте — не самостоятельный элемент интерфейса. Она связывает пользовательский сценарий с работой менеджера.


В проекте для официального дилера КАМАЗ «Волготехснаб» логика обработки обращений проектировалась непосредственно под отдел продаж. Заявки фиксировались одновременно в нескольких каналах: в электронной почте, Telegram и CRM-системе.


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


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


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


Корпоративный B2B-сценарий тоже требует отдельного внимания


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


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


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


От одного сайта к цифровому контуру дилерской группы


Структура проектов группы «РязаньСкан» показывает ещё один возможный уровень развития.


В Portfolio зафиксированы сайт группы компаний «РязаньСкан» для Рязани и Тулы, самостоятельный сервисный ресурс, а также отдельные сайты официального дилера Sitrak для «РязаньСкан» и «ТулаСкан».


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


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


Что определить до начала проектирования


На основе этих проектов можно сформировать практический список вопросов, которые стоит решить до начала дизайна и разработки.



  1. Какие бренды и группы техники нужно представить. Определить, как пользователь будет переходить от общего предложения к марке, модели и конкретному автомобилю.

  2. Какие аудитории приходят на сайт. Корпоративный покупатель, клиент сервиса и пользователь, ищущий запчасти, решают разные задачи.

  3. Как будет устроен каталог. Определить параметры фильтрации, состав карточки модели, фотографии, видео, технические характеристики и необходимые расчётные инструменты.

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

  5. Как пользователь работает с запчастями. Нужен ли поиск по VIN или названию, какие данные показываются по позиции и можно ли оформить заказ онлайн.

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

  7. Какие интерактивные инструменты действительно нужны. Калькуляторы, формы, онлайн-консультации, чаты и запись на сервис должны продолжать конкретный пользовательский сценарий.

  8. Как сайт работает на разных устройствах. Мобильную адаптацию нужно учитывать уже при проектировании структуры и интерфейса.

  9. Нужны ли связи с внутренними системами. В проекте для дистрибьютора Sitrak была зафиксирована интеграция с внутренними системами компании для оперативного обновления информации. Состав систем и механизмы обмена определяются отдельно для конкретного проекта.


Вывод


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


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


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


Проекты, использованные в материале