# CRM для автосервиса: запись, заказ-наряд, статусы и повторные обращения

Редакция SGI24. Это проектная методика, а не описание внедрения в конкретном автосервисе. [О бюро](/company).

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

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

Разобрать CRM автосервиса

CRM и учётная программа решают разные задачи

В автосервисе словом CRM нередко называют любую программу. Это мешает сформулировать требования.

CRM ведёт отношения и коммуникации:

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

Учётный контур работает с заказ-нарядами, нормами, запчастями, складом, кассой, оплатами и финансовыми документами. Иногда обе части объединены в одном продукте. Иногда CRM, сайт и специализированная система связаны обменом. Важен не бренд программы, а отсутствие повторного ввода и расхождений.

Основные объекты системы

Одна карточка клиента недостаточна. В рабочей модели есть как минимум:

  • клиент;
  • автомобиль;
  • обращение;
  • запись;
  • визит;
  • результат осмотра;
  • согласование;
  • заказ-наряд;
  • работа;
  • запчасть;
  • рекомендация;
  • оплата.

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

Карточка клиента

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

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

Карточка автомобиля

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

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

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

Обращение и запись — не одно и то же

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

Маршрут может выглядеть так:

  1. Получено обращение.
  2. Уточнены автомобиль, задача и срочность.
  3. Определена услуга и требуемый ресурс.
  4. Предложено время.
  5. Клиент подтвердил запись.
  6. Отправлено напоминание.
  7. Автомобиль принят.

Разделение помогает видеть, где теряются клиенты: до подбора времени, после предложения слота или уже после подтверждения.

Онлайн-запись должна учитывать ресурсы

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

До запуска онлайн-записи нужно определить:

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

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

Приём автомобиля

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

Результатом приёмки становится понятная исходная задача. Формулировка «посмотреть машину» не помогает ни мастеру, ни клиенту. Нужно отделить заявленные симптомы, заказанные работы и согласие на диагностику.

Осмотр и согласование дополнительных работ

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

Система должна показать:

  • обнаруженную проблему;
  • предложенную работу;
  • необходимые детали;
  • стоимость или порядок расчёта;
  • влияние отказа или переноса;
  • статус согласования;
  • кто и когда подтвердил решение.

Клиенту можно отправить защищённую страницу или сообщение со ссылкой на предложение. Согласие через устный звонок тоже фиксируется сотрудником с датой и содержанием договорённости. Статус «отправлено» не равен статусу «согласовано».

Заказ-наряд и работы

Заказ-наряд создаётся после подтверждения состава работ по принятому в компании процессу. В нём должны совпадать автомобиль, клиент, перечень работ, детали, цены и согласованные изменения.

Работы полезно вести отдельными строками со статусами:

  • ожидает начала;
  • выполняется;
  • остановлена;
  • ждёт деталь;
  • ждёт согласование;
  • завершена;
  • принята контролёром.

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

Запчасти и склад

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

  • есть в наличии;
  • зарезервирована;
  • заказана;
  • ожидается;
  • получена;
  • установлена;
  • возвращена.

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

Оплата и выдача

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

Перед выдачей проверяют:

  • завершение согласованных работ;
  • контроль качества;
  • итоговый состав заказа;
  • оплату или условия расчёта;
  • рекомендации;
  • документы;
  • согласованный способ уведомления.

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

Статусы, понятные сотруднику и клиенту

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

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

Статус не должен меняться только ради красивого отчёта. Он отражает фактическое событие: приём состоялся, диагностика закончена, предложение подтверждено, деталь получена.

Повторные обращения без навязчивых рассылок

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

Для рекомендации фиксируют:

  • что предложено;
  • почему отложено;
  • ориентир по дате или пробегу;
  • кто отвечает за контакт;
  • результат напоминания.

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

Роли и доступ

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

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

Интеграции

Система автосервиса может быть связана с:

  • сайтом и онлайн-записью;
  • телефонией;
  • корпоративными мессенджерами;
  • учётной программой;
  • складом и каталогом запчастей;
  • кассой и оплатой;
  • сервисом уведомлений;
  • аналитикой.

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

Персональные данные и история автомобиля

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

До внедрения определяют:

  • обязательные данные для каждого этапа;
  • место хранения;
  • получателей;
  • сроки хранения;
  • права сотрудников;
  • порядок выгрузки и удаления;
  • действия при ошибочной отправке файла или сообщения.

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

Какие показатели нужны руководителю

Полезный отчёт строится по этапам:

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

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

Как принимать систему

До запуска следует пройти сквозные сценарии:

  1. Новый клиент записал один автомобиль через сайт.
  2. Существующий клиент обратился по второй машине.
  3. Запись перенесена и отменена.
  4. После осмотра предложены дополнительные работы.
  5. Клиент согласовал часть предложения.
  6. Работа остановлена до прихода детали.
  7. Оплата пришла из учётной системы.
  8. Рекомендация перенесена на будущую дату.
  9. Повторная форма не создала второго клиента и автомобиля.
  10. Внешняя система временно недоступна.

Приёмка проверяет не экран отдельно, а всю цепочку: запись, исполнение, документы, уведомление и отчёт.

Частые ошибки автоматизации автосервиса

  • Клиент и автомобиль объединены в одной записи.
  • Вопрос о цене сразу считается записью.
  • Онлайн-календарь не знает о постах и мастерах.
  • Дополнительные работы не имеют статуса согласования.
  • Детали и сроки копируются из личных переписок.
  • Все задержки скрыты под статусом «в работе».
  • Оплата отмечается вручную в двух системах.
  • Рекомендации не связаны с датой или пробегом.
  • Повторный звонок создаёт дубль.
  • Руководитель видит формы, но не приезды и закрытые визиты.

Что проверить до внедрения CRM

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

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

Обсудить CRM и автоматизацию автосервиса

В форме перечислите учётную программу, число постов и один ручной переход между записью и заказ-нарядом. Этого достаточно для проверки проектной модели.

Связанные материалы

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