Нужна ли CRM автосервису: запись и возврат клиента

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

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

Пройдите по цепочке ниже и отметьте, где информация фиксируется системой, а где держится на человеке. Каждый шаг «на человеке» — это место, где процесс рвётся, когда одновременно звонят три клиента и подъезжает эвакуатор.

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

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

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

Второе — запись на пост как бронь ресурса, а не заметка в календаре. Здесь помогает опыт из соседней отрасли: для сети из 5 банных комплексов в Санкт-Петербурге мы сделали на коробочном Bitrix24 «шахматку» бронирования — внутреннее приложение, где администратор видит занятость кабинок по времени и ставит брони. Это не кейс автосервиса, и мы не выдаём его за отраслевой, но механика идентична: ограниченное число ресурсов, время как основная ось и конфликт броней, который система обязана не допустить. Подъёмник, пост развал-схождения и мастер нужной специализации ведут себя ровно так же, как кабинка с расписанием.

Дальше на эту основу навешивается всё остальное — то, что закрывается настройкой, а не силой воли администратора.

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

Главное правило связки: у каждой сущности есть ровно одна система-хозяин. Остатки, закупочные цены и себестоимость — хозяин учётная программа. Обращения, запись, коммуникация и история договорённостей — хозяин CRM. Всё остальное синхронизируется в одну сторону, а не в обе. Двух источников правды не бывает: бывает один источник и его копия, которая всегда чуть-чуть устарела. Как только остаток по складу можно править в двух местах, начинается расхождение — где-то поменяли прайс, где-то не выгрузили, где-то поправили руками «только на этот раз». Через месяц администратор называет клиенту цену из CRM, а на складе позиции нет, и после второго такого случая сотрудники перестают верить обеим системам сразу.

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

Звонок остаётся главным каналом записи в сервисе, и именно он хуже всего переживает пиковую нагрузку. В восемь утра администратор принимает машины, оформляет наряды и одновременно должен отвечать на телефон. Физически это несовместимо, поэтому часть звонков просто не берут — и разбора по ним никогда не происходит, потому что журнал вызовов АТС и записи в тетради живут в разных мирах.

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

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

Про телефонию мы говорим со стороны практики: у нас в проде работает собственная АТС на Asterisk — правда, это личная инфраструктура для звонков через 1 московский номер UIS из-за границы, с параллельным дозвоном на 2 софтфона. Это не кейс автосервиса, и выдавать его за отраслевой опыт мы не будем. Полезен из него другой вывод: на своём сервере события звонка описываются руками — маршрутизация, передача начала и завершения разговора в CRM, ссылка на запись. Для сервиса с нестандартной схемой приёма это тот уровень гибкости, которого не даёт коробочный коннектор.

Возврат клиента в сервис — это не рассылка «мы соскучились», а работа с двумя списками. Первый — автомобили, у которых подходит срок планового обслуживания. Второй — работы, которые клиенту уже предлагали, а он отложил. Оба списка система собирает сама, если история по автомобилю в неё попадает. Без CRM их можно собрать вручную по нарядам, но никто этого не делает: это отдельная работа на несколько дней.

Плановое ТО считается по двум правилам сразу, потому что каждое по отдельности врёт. По дате: прошёл год с последнего обслуживания. По прогнозу пробега: на прошлом визите зафиксировано столько-то километров, интервал обслуживания известен, среднесуточный пробег оценивается по разнице между двумя последними визитами. Сработать должно то правило, которое наступит раньше. Здесь честная оговорка: пробег между визитами система не знает, она его оценивает — у клиента могла смениться работа, а машина могла полгода простоять. Поэтому напоминание формулируется как повод связаться и уточнить, а не как утверждение «вам пора».

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

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

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

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

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

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