Как построить сайт дилера вокруг реальных автомобилей в наличии

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

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

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

Почему каталога моделей недостаточно дилеру

Каталог производителя хорошо знакомит с модельным рядом. Он показывает двигатели, комплектации, цвета, характеристики и рекомендованные цены.

Но покупатель дилера в какой-то момент задает другие вопросы:

• Есть ли такая машина сейчас

• В каком центре она находится

• Какого она цвета

• Сколько стоит конкретный экземпляр

• Свободна ли она или уже в резерве

• Какие близкие варианты доступны

Если сайт на этом месте заканчивается формой «Узнать наличие», связь между выбором покупателя и реальным складом обрывается.

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

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

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

Статья

Как быстрее продавать автомобили со склада дилера: данные, сайт и менеджеры

Модель и складской автомобиль живут с разной скоростью.

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

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

Такая структура дает бизнесу два независимых контура управления. Маркетинг работает с модельным рядом и содержанием страниц. Складские цены и статусы обновляются из системы, где дилер ведет реальные автомобили.

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

Кейс

Найди и закажи за полминуты: как мы переработали сайт

Редизайн сайта технического e-commerce: поиск вперёд, упрощённый каталог и карточка товара — чтобы профи-покупатель нашёл и заказал за 30 секунд

Какие данные нужны по каждой машине

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

Минимальный состав:

• VIN или внутренний идентификатор

• Код модели и комплектации

• Актуальная цена

• Цвет кузова и салона

• Дилерский центр

• Фактическое местонахождение

• Статус автомобиля

• Дата поступления

• Дополнительное оборудование

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

Статусы перед публикацией приводят к понятному набору. На сайте Volkswagen.by и сайтах региональных дилеров сведения поступали с реального склада, а исходные статусы приходили в необработанном виде. Для корректного отображения потребовалась отдельная таблица соответствий.

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

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

Как обновлять поступления, резервы и продажи

Разные поля требуют разной скорости обновления.

Характеристики модели, фотографии и описание меняются редко. Цена, резерв, продажа и местонахождение конкретного автомобиля могут измениться в течение дня.

Поэтому обмен удобно разделить:

• Полная синхронизация проверяет состав склада и все поля

• Быстрые изменения передают новый статус, цену или резерв между полными синхронизациями

• Ошибки обмена фиксируются отдельно

• После восстановления связи пропущенные изменения отправляются повторно

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

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

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

Что показывать на странице модели

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

Рядом с этим контентом стоит показывать реальное наличие:

• Доступные комплектации

• Конкретные автомобили

• Цвета

• Актуальные цены

• Дилерские центры

• Статусы наличия

На платформе Volkswagen.by и региональных сайтов страницы моделей и каталог существовали как отдельные сущности, а каталог работал с данными реального склада. Такой подход сохраняет стабильную страницу модели и одновременно дает путь к конкретному предложению.

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

Правила для моделей, комплектаций, фильтров и складских карточек отдельно разбирали в статье «SEO сайта автодилера».

Если нужной комплектации нет

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

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

После этого нужны понятные действия:

• Посмотреть близкие автомобили

• Оставить запрос на нужную версию

• Получить уведомление о поступлении, если такой сценарий поддерживается

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

Как работать с общим складом нескольких дилерских центров

До разработки нужно решить, что для группы считается общим складом.

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

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

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

Техническая архитектура здесь зависит от коммерческих правил. До запуска нужно определить:

• Может ли один центр показывать машины другого

• Можно ли продать автомобиль клиенту соседнего региона

• Кто получает заявку по такой машине

• Кто ведет сделку

• Как меняется статус при резерве

• Как исключается одновременная работа двух менеджеров с одним экземпляром

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

Как складская структура меняет заявку и работу менеджера

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

Вместе с заявкой стоит передавать:

• Модель

• Комплектацию

• VIN или внутренний идентификатор автомобиля

• Цена на момент обращения

• Дилерский центр

• Статус автомобиля

• Источник перехода

Тогда менеджер видит, что именно выбрал клиент, и начинает разговор с конкретного предложения.

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

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

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

Платформа e-commerce на Laravel» Nineseven

Готовая e-commerce-платформа на Laravel для быстрого запуска и роста

Что подготовить до разработки каталога автомобилей в наличии

До оценки проекта стоит собрать исходные правила по данным и продажам.

Нужно определить:

• Где хранится актуальный склад

• Какая система считается источником цены

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

• Какими кодами связаны модель и комплектация

• Какие статусы существуют в учетной системе

• Какие статусы увидит покупатель

• Как быстро обновляются цена, резерв и продажа

• Как учитывается дополнительное оборудование

• Как устроен общий склад нескольких центров

• Кто получает заявку по конкретной машине

• Что происходит с карточкой после продажи

• Что видит сайт при ошибке обмена

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

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