Какие данные о выборе клиента нужно передавать менеджеру вместе с заявкой
К моменту заявки сайт уже может знать о клиенте довольно много. Он выбрал конкретный автомобиль, сравнил комплектации, рассчитал кредит, оценил машину в трейд-ин или записался на тест-драйв.
Если в отдел продаж после этого приходит только имя и телефон, большая часть проделанной работы пропадает.
Менеджеру нужен не весь путь посетителя по сайту. Нужен контекст, который помогает продолжить именно эту сделку.
Для заявки на автомобиль это обычно сам автомобиль или выбранная конфигурация, цена и условия, которые видел клиент, дилерский центр и данные конкретного сценария: кредита, трейд-ин, тест-драйва или визита.
Почему имени и телефона уже недостаточно
Представим, что покупатель выбрал конкретный автомобиль, посчитал кредит с первоначальным взносом 1,2 млн рублей и отправил заявку прямо из карточки.
Менеджер получает:
Имя: Александр
Телефон: +7…
И начинает выяснять:
Какую машину смотрели? Какую комплектацию? Какой взнос планировали? Какой платеж получили?
Все эти ответы сайт уже знал в момент отправки формы.
Чем сложнее выбор до заявки, тем заметнее потеря. В конфигураторе человек может последовательно выбрать комплектацию, цвет, колеса, салон и опции, а менеджеру в итоге достанется только название модели.
Поэтому полезнее считать заявку не формой с контактами, а снимком выбора клиента в момент обращения.
Что стоит передавать почти в любой заявке
Универсального набора для всех форм нет. Заявка на конкретный автомобиль и запись на тест-драйв требуют разного контекста.
Но у большинства автомобильных сценариев есть основа:
-
Конкретный автомобиль или внутренний идентификатор
-
Модель и комплектация
-
Цена, которую видел клиент
-
Дилерский центр
-
Тип обращения
-
Источник обращения
Если человек выбирал не конкретную машину со склада, а собирал конфигурацию, вместо идентификатора автомобиля сохраняют результат этой сборки.
Особенно важна цена.
Сегодня машина стоит 4,2 млн рублей, через неделю цена изменилась. Менеджеру нужно понимать, с какой цифрой клиент отправлял заявку.
Поэтому вместе с ценой полезно хранить время расчета или обращения.
Кейс

Что добавлять в зависимости от сценария
Дальше состав заявки зависит от того, что человек делал на сайте.
Кредит
Если клиент рассчитал финансирование, менеджеру полезны:
-
Автомобиль
-
Цена на момент расчета
-
Первоначальный взнос
-
Срок
-
Выбранная программа
-
Рассчитанный платеж
-
Дата расчета
Сам платеж важно сохранить именно в том виде, в котором его видел клиент. Если условия программы изменятся завтра, новый расчет уже может дать другую цифру.
Трейд-ин
В обращении можно сохранить:
-
Выбранный новый автомобиль
-
Данные автомобиля клиента
-
Предварительную оценку
-
Сумму доплаты
-
Условия трейд-ин, участвовавшие в расчете
-
Параметры кредита, если клиент считал его вместе с обменом
Тогда менеджер видит обе машины как части одной сделки.
Тест-драйв или визит
Здесь важнее другое:
-
Автомобиль или модель
-
Выбранный дилерский центр
-
Дата
-
Время
-
Дополнительные пожелания, если они собирались в форме
Не нужно заставлять каждую форму передавать одинаковый набор только ради порядка в таблице.
Что передавать о комплектации и конфигурации
Если клиент собрал машину в конфигураторе, одной строки «Volkswagen Tiguan» мало.
Полезно сохранить сам результат:
-
Комплектацию
-
Двигатель и привод
-
Цвет
-
Колеса
-
Салон
-
Выбранные пакеты и опции
-
Итоговую стоимость
В конфигураторе автомобилей Volkswagen собранная конфигурация сохранялась системой и могла быть восстановлена по уникальному коду.
Это удобный принцип и для заявки.
Менеджеру необязательно показывать двадцать технических полей в карточке обращения. Он может получить основные параметры и ссылку на сохраненную конфигурацию, где машина открывается ровно в том виде, в котором ее собрал клиент.
Какие данные о поведении действительно нужны менеджеру
Здесь легко переборщить.
CRM не должна превращаться в копию системы веб-аналитики со списком всех страниц, кликов и фильтров.
Полезны только действия, которые помогают понять сам выбор.
Допустим, клиент явно сравнивал две комплектации перед заявкой. Это может быть полезно менеджеру:
Сравнивал: Comfort и Premium
Выбрал: Premium
Или перед обращением рассматривал две конкретные машины из наличия. Тогда можно сохранить эти альтернативы.
Но сам по себе пятый просмотр карточки ничего надежно не говорит о готовности к покупке. То же самое с историей фильтров: ее можно изучать в аналитике, но превращать каждое действие в подсказку продавцу без проверки пользы не стоит.
Простое правило здесь работает лучше всего:
Если информация меняет следующее действие менеджера, ее можно передать в заявку. Если нужна только для анализа поведения, ей место в системе аналитики.
Как сохранять источник обращения
Источник нужен уже не столько продавцу, сколько маршрутизации и последующей аналитике.
Вместе с обращением можно сохранять данные, по которым дилер ведет свою атрибуцию:
-
Рекламный источник
-
Кампанию
-
Страницу или сценарий, из которого отправлена заявка
-
Дилерский центр
-
Тип обращения
Конкретный набор зависит от того, как у дилера устроена аналитика.
Не стоит пытаться решить внутри формы вопрос всей атрибуции клиента. Первый источник, последний источник, повторные визиты и цепочка рекламных касаний относятся уже к аналитической модели.
Для заявки достаточно сохранить идентификаторы, по которым обращение потом можно связать с нужными данными.
Откуда брать значения для заявки
У каждого важного поля должен быть понятный источник.
Автомобиль и его статус приходят из системы, где ведется склад. Цена берется из того источника, который отвечает за цену. Результат кредитного расчета сохраняется в самом расчете. Время тест-драйва приходит из формы записи.
Для изменчивых значений полезно различать текущее состояние и то, что видел клиент.
Допустим, после отправки формы цена автомобиля изменилась.
Менеджеру нужны обе вещи:
-
Какой автомобиль выбрал клиент
-
Какую цену сайт показал ему при обращении
Поэтому в заявку сохраняют снимок важных условий на момент отправки, а не надеются восстановить их позже по текущей карточке.
Как распределять заявки между менеджерами
Контекст обращения может влиять и на маршрут заявки.
Если человек выбрал конкретный автомобиль, известен центр, где машина находится.
Если записался на тест-драйв, известна площадка и время.
Если отправил расчет с трейд-ин, к работе может подключаться соответствующее направление.
Поэтому часть полей используется не только для разговора менеджера, но и для автоматического распределения обращения.
Правила здесь определяет сам дилер:
-
По дилерскому центру
-
По бренду
-
По типу обращения
-
По конкретному автомобилю
-
По направлению продаж
Сайт должен передавать данные, которых достаточно для выбранного правила.
Что должен увидеть менеджер при открытии обращения
Карточку обращения лучше строить от задачи сотрудника, а не от структуры интеграции.
Сначала короткое резюме:
Автомобиль: Geely Monjaro, Flagship
Цена при обращении: 4 249 000 ₽
Центр: Боровая
Обращение: кредит
Первоначальный взнос: 1 200 000 ₽
Срок: 36 месяцев
Платеж в расчете: 98 400 ₽
Ниже уже можно хранить дополнительные сведения и технические идентификаторы.
Менеджеру не нужно расшифровывать машинные коды и искать нужное значение среди двадцати полей. Главный контекст должен считываться за несколько секунд.
Что делать, если CRM не принимает нужные поля
Иногда ограничение находится не на сайте.
Система отдела продаж может не позволять быстро добавить новую структуру данных.
Тогда есть несколько временных вариантов:
-
Использовать доступные дополнительные поля
-
Передавать короткое структурированное описание в примечании
-
Сохранять результат расчета или конфигурации отдельно и передавать ссылку
Последний вариант особенно полезен для сложных конфигураторов и калькуляторов: карточка обращения остается короткой, а полный результат можно открыть отдельно.
Но такой обходной путь не стоит выдавать за идеальную архитектуру. Структурированные поля удобнее для маршрутизации, поиска и отчетов.
Как проверить, что заявка дошла целиком
Интеграция считается рабочей не тогда, когда CRM получила телефон клиента, а когда вместе с ним дошел нужный контекст.
При запуске стоит проверить основные сценарии:
-
Заявка на конкретный автомобиль
-
Кредитный расчет
-
Трейд-ин
-
Запись на тест-драйв
-
Конфигурация автомобиля
Для каждого смотрят, какие данные отправил сайт и что в итоге увидел менеджер.
Если передача не удалась, обращение нельзя просто потерять.
В проекте «Абамет» сайт обменивался данными с «1С» и Microsoft Dynamics. Для сбоев сделали очередь сообщений: при ошибке событие сохранялось, а отправка повторялась.
Для дилерского сайта важен сам принцип: сбой интеграции должен оставлять след, а заявка должна сохраняться для повторной передачи.
В постоянном контроле достаточно следить за вещами, которые действительно означают потерю данных:
-
Заявки, которые не дошли до системы продаж
-
Обращения без идентификатора автомобиля там, где он должен быть
-
Кредитные заявки без сохраненного расчета
-
Заявки на тест-драйв без выбранного центра или времени

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


