CRM для автосалона: лиды, тест-драйвы и сделки

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

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

Каналы и повторные обращения одного покупателя

У автосалона обычно много входов: звонки по номеру из рекламы, заявки с сайта и досок объявлений, переписка в мессенджерах, визиты «с улицы», обращения через сервис. Первая задача CRM - чтобы каждое обращение попало в систему с источником сделки и ответственным, а не осталось в личном телефоне менеджера. Для этого телефония, формы и мессенджеры подключаются к CRM, а правила записи обращений фиксируются заранее. Что телефония передаёт в карточку автоматически, а что менеджер вносит сам, мы разбирали в статье об интеграции телефонии с amoCRM.

Вторая задача специфична для автомобильной продажи: один и тот же покупатель обращается несколько раз. Например, покупатель сначала оставил заявку на кроссовер на сайте, через два дня позвонил по объявлению о конкретной машине, потом написал в мессенджер с вопросом о трейд-ине. Если каждое обращение порождает новую сделку и новый менеджер берёт её себе, получается три «лида», три менеджера и ни одного внятного следующего шага. А в отчёте по рекламе - три источника вместо одного покупателя.

Решение строится из трёх частей:

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

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

Покупатель, обращение и автомобиль: какие объекты нужны

Типичная ошибка - пытаться уместить всё в одну карточку сделки: покупателя, автомобиль из наличия, оцениваемую машину по трейд-ину, кредитную заявку и выдачу. Удобнее сначала договориться, какие объекты есть в продаже и кто за каждый отвечает.

• Покупатель - контакт с телефонами, мессенджерами, историей обращений. Один человек - одна запись.
• Сделка (интерес) - конкретное намерение купить: модель или автомобиль, срок, способ оплаты, ответственный менеджер, этап.
• Автомобиль из наличия - объект учётной системы с VIN, комплектацией, статусом и ценой. В CRM он попадает как ссылка или справочная запись, а не как поле, которое менеджер заполняет руками.
• Автомобиль покупателя для трейд-ина - отдельный объект со своей оценкой, а не строка в комментарии.
• Визит и тест-драйв - запланированные события с датой, временем, ответственным и фактом: состоялось или нет.

Обе популярные CRM позволяют выстроить такую модель, но разными средствами. В amoCRM есть дополнительные поля разных типов для сделок и контактов и каталоги (списки): до десяти в аккаунте, а элемент каталога можно привязать к сделке. В Битрикс24 для отдельных объектов есть смарт-процессы - свои элементы CRM с полями, стадиями, правами и связями с другими элементами; они доступны не на всех тарифах. Условия меняются - перед работой сверяйте со справкой разработчика.

Когда общей CRM достаточно, а когда нужен дилерский контур

CRM автосалона не работает в вакууме. Рядом почти всегда есть учётная система: отраслевая дилерская (её часто называют DMS) или учётная конфигурация на базе 1С. Например, у 1С-Рарус есть отраслевое решение «Альфа-Авто» для автосалона, сервиса и запчастей, а к нему - дополнение для управления взаимоотношениями с клиентами, которое работает в составе этой системы, а не отдельно. Значит, в отраслевой системе CRM уже может быть, и вторая система нужна не всегда.

Практическое правило: если продажи уже ведутся в CRM-модуле отраслевой системы и менеджеры им пользуются, сначала стоит наладить процесс там. Общая CRM оправдана, когда входящий поток большой и разнородный, нужны мессенджеры, телефония и связь с рекламой, а работа с обращениями в учётной системе неудобна. Тогда CRM отвечает за путь покупателя до согласования условий, учётная система - за автомобиль и документы, а между ними проектируется обмен. Готового коннектора к конкретной дилерской системе может не быть: перед проектом проверяют, какие данные, в какую сторону и как часто должны передаваться, кто владелец каждого поля и что происходит при сбое связи. С чего начинать такой обмен, разобрано в статье о сквозном обмене данными между CRM и учётной системой.

Приглашение, подтверждение, визит и тест-драйв

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

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

Чтобы этапы были проверяемыми, у каждого нужен критерий перехода - событие, которое можно подтвердить, а не ощущение менеджера.

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

Автомобиль, интерес покупателя и резерв

Самое чувствительное место - связь сделки с конкретной машиной. Типичный сбой выглядит так: менеджер договорился о визите на конкретный автомобиль, а к моменту приезда покупателя его уже продали или зарезервировали для другого клиента. Хуже, когда два менеджера отметили «резерв» на один VIN, потому что поле в CRM ни с чем не связано.

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

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

Трейд-ин и кредит: связанные задачи, а не ступени воронки

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

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

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

Как считать визиты, тест-драйвы и выдачи

Отчёт «сколько звонков дала реклама» для автосалона почти бесполезен. Звонок ещё не покупатель: важно, сколько из обращений дошли до визита, сколько визитов закончились тест-драйвом с понятным следующим шагом и сколько сделок дошли до выдачи. Так воронка продаж показывает не активность, а движение покупателей. Для каждого показателя заранее определяют числитель, знаменатель и период - иначе два руководителя посчитают одну и ту же конверсию по-разному.

Отраслевых норм по этим конверсиям мы не приводим: они сильно зависят от марки, цены, доли наличия и сезона, и сравнивать стоит салон с самим собой по периодам. Учитывайте и цикл сделки: покупатель, обратившийся в конце месяца, может приехать только в следующем, поэтому сравнивать периоды надёжнее по когортам обращений, а не по календарю событий. Факт выдачи берётся из учётной системы, а не из этапа CRM. Как собрать такие показатели в регулярный обзор, описано в статье о метриках продаж для руководителя, а связь с рекламой - в материале о сквозной аналитике.

amoCRM или Битрикс24 для автосалона

Победителя «вообще» здесь нет: выбор зависит от процесса, команды и интеграций. amoCRM удобна, когда главное - поток обращений из звонков, сайта и мессенджеров и быстрый старт отдела продаж; автомобиль и трейд-ин в ней описываются полями и каталогами. Битрикс24 удобнее, когда нужны отдельные объекты со своими стадиями и правами, например учёт автомобилей на обмен как смарт-процесс, и когда в той же системе живут задачи и согласования других отделов. В обоих случаях интеграцию с учётной системой проектируют отдельно. Модели оплаты тоже разные: amoCRM считает лицензии по пользователям, Битрикс24 - пакетом пользователей, а приложения Маркетплейса, REST API и вебхуки у него подключаются по отдельной подписке. Часть решений, в том числе обмен с 1С, доступна и без неё, в зависимости от тарифа. Подробнее - на странице «amoCRM или Битрикс24» и в услугах по внедрению amoCRM и Битрикс24.

Пилот: как проверить схему до запуска на весь салон

Запускать всё сразу рискованно. Надёжнее взять один поток обращений, например заявки по одной модели или одной группе менеджеров, и проверить на нём базовую цепочку: обращение, визит, тест-драйв, предложение, передача на оформление. Обмен с учётной системой на пилоте можно вести вручную по тому же правилу, что и в автоматическом варианте.

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

Купить CRM и внедрить под процесс салона - не одно и то же

Купить лицензию и добавить в карточку поля «модель», «VIN» и «трейд-ин» можно за день. Но это ещё не внедрение. Пока не решено, кто владеет данными об автомобиле, как склеиваются повторные обращения и что считается фактом визита, CRM станет ещё одним местом, куда менеджеры записывают что-то после разговора. Сначала процесс, потом настройка: разобрать, как покупатель реально проходит путь от рекламы до выдачи, выбрать ближайший уровень, который даст управляемость, и только затем автоматизировать. Для многих салонов ближайший шаг - не обмен с дилерской системой, а простое правило: каждое обращение в CRM, у каждого визита есть факт, у каждого резерва есть подтверждение. Логику уровней мы описали в методике.

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

Частые вопросы

Вывод

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

Источники

• amoCRM для разработчиков: дополнительные поля
• amoCRM для разработчиков: каталоги (списки)
• amoCRM для разработчиков: контроль дублей
• Справка Битрикс24: смарт-процессы в CRM
• 1С-Рарус: «Альфа-Авто», редакция 6
• 1С-Рарус: дополнение «Управление взаимоотношениями с клиентами» к «Альфа-Авто Корп», редакция 6
• Битрикс24: тарифы и модель оплаты
• Справка Битрикс24: подписка «Битрикс24 Маркетплейс»