← Все статьи

CRM для автосервиса vs учётная система: в чём разница и что нужно СТО

27 августа 2026 · 10 мин чтения · для владельца

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

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

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

Откуда взялась путаница в терминах

Слово CRM (Customer Relationship Management, управление отношениями с клиентом) пришло из продаж — из мира, где сделка длинная, менеджеров много, а главный дефицит — внимание к лиду. Задача классической CRM: не потерять обращение, провести его по этапам и удержать клиента после сделки.

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

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

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

Что делает CRM: воронка, клиент, коммуникация

CRM отвечает на вопросы про людей и про поток обращений. Её сильные стороны в автосервисе выглядят так:

• Фиксация всех обращений. Звонок, заявка с сайта, сообщение в мессенджере — всё попадает в одно место и получает ответственного. Без этого часть входящих просто теряется: позвонили в обед, приёмщик был на выдаче, перезвонить забыли.
• Воронка по этапам. Обращение → расчёт → запись → визит. Видно, где обрывается: например, из двадцати расчётов до записи доходят четыре, и это повод разбираться с ценами или со скриптом разговора.
• Напоминания и повторные продажи. ТО через 10 000 км, сезонная замена резины, окончание гарантии на работу. CRM умеет сама поднять клиента в нужный момент и поставить задачу «позвонить».
• История коммуникаций. Записи разговоров, переписка, кто что обещал. При споре «мне говорили другую цену» это единственное, на что можно опереться.
• Рассылки и сегменты. «Все, кто был больше года назад», «владельцы дизелей», «клиенты, которым отказали по цене» — и адресное предложение по сегменту.
• Аналитика источников. Сколько обращений дал Яндекс, сколько — 2ГИС, сколько пришло по рекомендации. Без этого рекламный бюджет тратится вслепую.

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

Что делает учётная система: заказ-наряд, склад, деньги

Учётная система отвечает на вопросы про работу и про деньги. Её объекты — не «сделка», а конкретные документы и операции:

• Приёмка и заказ-наряд. Автомобиль, пробег, состояние, перечень работ с нормо-часами и исполнителями, перечень запчастей с артикулами и ценами, задатки, итог.
• Склад. Заказ поставщику, оприходование прихода, списание в заказ, остатки, неликвиды. Подробно этот контур разбирали в статье про склад запчастей.
• Касса и смены. Приём оплаты наличными и картой, разбивка смешанной оплаты, инкассация, сверка в конце дня — то, о чём была отдельная статья.
• Зарплата мастеров. Начисление по факту закрытых работ: по цене, по нормо-часу или по проценту, с отчётом за период.
• Документы. Акт приёмки, заказ-наряд, акт выполненных работ, счёт, договор — с реквизитами сервиса и клиента, готовые к печати и подписи.
• Финансовый результат. Выручка, себестоимость, валовая маржа, чистая прибыль — то, ради чего всё остальное и ведётся. Разбор по слагаемым — в статье про отчёт по прибыли.

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

Сравнение по задачам

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

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

Где проходит настоящая граница

Граница не в списке функций, а в объекте, вокруг которого построена база данных. Это важно, потому что функции можно дописать, а объект — почти нет.

В CRM центральная сущность — сделка. У неё есть сумма, этап, ответственный и клиент. Всё остальное — поля и комментарии. Когда в такую систему пытаются вписать заказ-наряд, он становится текстовым описанием: «замена ГРМ, ремень + ролики, 14 500». Ни себестоимости, ни списания со склада, ни начисления мастеру. Формально сделка есть, экономики — нет.

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

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

Четыре сценария, где разница видна

1. Клиент звонит и спрашивает цену

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

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

2. Машина приехала, работы добавились по ходу

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

В CRM сумма сделки меняется с 14 500 на 21 800. Что именно изменилось и сколько на этом заработано — известно только тому, кто менял.

3. Конец месяца, считаем зарплату

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

CRM в этот момент бесполезна: в ней нет ни исполнителей по строкам, ни нормо-часов. Зарплата считается в Excel по тетрадке, со всеми известными последствиями — спорами, ошибками и вечером, потраченным владельцем.

4. Клиент не приезжал полтора года

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

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

Что происходит, когда систем две

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

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

Разрыв в самом ценном месте. Главный отчёт, ради которого затевается автоматизация, — «сколько мы заработали на клиентах из такого-то источника». Он требует данных из обеих систем: источник обращения из CRM, маржу из учёта. Если систем две и они не связаны, отчёт собирается руками в Excel — то есть не собирается.

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

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

Как это устроено в АвтоСервисОнлайн

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

• Клиент — самостоятельная сущность, а не поле в заказе. Физлицо, юрлицо или ИП со своими реквизитами и условиями оплаты (разбирали в статье про типы клиентов). К клиенту привязаны автомобили, к автомобилям — заказы.
• История не рвётся. Сменился госномер или владелец — машина в базе остаётся той же, вся история обслуживания на месте. Ключ — VIN, а не номер.
• Статусы заказа — «новый», «ждём заказчика», «ждём запчастей», «выполняется», «выполнен», «отказ» — дают ту самую воронку по машинам, которые уже в работе. Видно, где встал поток и сколько подъёмников заняты ожиданием.
• Уведомления клиенту и сотрудникам уходят в Telegram: запчасть пришла, машина готова, требуется согласование дополнительных работ. Это закрывает основную часть «коммуникации», ради которой обычно и покупают CRM.
• Экономика считается в тех же данных. Себестоимость работ и запчастей, маржа по заказу, зарплата мастеров, касса, отчёт по прибыли — всё из строк заказ-наряда, без экспорта и сведения вручную.
• Печатные документы формируются из карточки: акт приёмки, заказ-наряд, акт выполненных работ, счёт. Реквизиты подставляются автоматически.

Чего в системе намеренно нет — интеграции с телефонией, записи разговоров и почтовых рассылок по сегментам. Это честная граница: сервису на 3–8 постов такие инструменты обычно не окупаются, а их наличие в прайсе поднимает цену для всех. Если поток входящих действительно требует call-центра, правильнее поставить рядом специализированную CRM и связать её с учётом по клиенту, чем платить за полурабочую телефонию внутри учётной программы. Сравнение того, что входит в тарифы, — на странице цен.

Три мифа, из-за которых выбирают не то

Миф первый: «Нам главное — не терять клиентов, значит нужна CRM». Звучит логично, но клиентов сервис теряет не столько на этапе звонка, сколько на этапе выдачи: обещали в четверг — отдали во вторник; назвали 18 000 — выставили 26 000; поставили не ту запчасть, потому что подбирали по описанию. Всё перечисленное лечится учётом, а не воронкой. Работа с обращениями имеет смысл тогда, когда внутри сервиса уже порядок: иначе CRM аккуратно приведёт больше людей туда, где их снова разочаруют.

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

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

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

Чек-лист: восемь вопросов поставщику

Что спрашивать на демонстрации, чтобы за час понять, что вам показывают на самом деле:

1. Покажите заказ-наряд со строками работ и запчастей. Если работы вводятся текстом в одно поле — это CRM, экономики не будет.
2. Где видно себестоимость заказа и маржу по нему? Не выручку, а именно маржу. Если ответ «выгружается в Excel» — считайте, что её нет.
3. Как запчасть попадает со склада в заказ и что происходит с остатком? Должно быть списание, а не «уменьшили число руками».
4. Покажите расчёт зарплаты мастера за месяц. Должны быть тарифы по строкам и отчёт за период.
5. Что происходит, когда клиент меняет госномер или продаёт машину? История должна остаться целой.
6. Как выглядит печатный акт приёмки? Попросите распечатать при вас, с вашими реквизитами.
7. Есть ли учёт входящих обращений и напоминаний? И честно оцените, нужен ли он вам при текущем потоке.
8. Что будет с данными, если мы уйдём? Выгрузка клиентов, машин, заказов и остатков в читаемом формате — обязательное условие.

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

Как выбрать под свой размер

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

• 1–3 поста, входящих 10–20 в неделю. Нужна учётная система. Клиентская база в ней же. CRM отдельно — деньги на ветер: воронку из пятнадцати звонков приёмщик держит в голове, а вот склад и зарплату в голове не удержишь.
• 4–8 постов, входящих 30–80 в неделю. Учётная система с клиентским контуром и уведомлениями. Это точка, где потери от «забыли перезвонить» становятся заметны, но выделенного человека на звонках ещё нет.
• Больше 8 постов или несколько точек. Здесь уже осмысленна связка: учётная система как основа плюс CRM для отдела продаж, связанные по клиенту. Но связывать нужно осознанно, с ответом на вопрос «какой отчёт мы хотим получить на выходе».
• Кузовной ремонт со страховыми. Отдельный случай: приоритет у документооборота и калькуляций, а не у воронки. Учёт и документооборот здесь решают всё.

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

Итог

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

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

Практический порядок действий для сервиса на 3–8 постов: сначала учёт, внутри него клиентская база и уведомления, отдельная CRM — только когда поток входящих перерастёт возможности приёмщика. Так не приходится платить дважды и переносить данные из системы, которая изначально была не про то.

Попробовать АвтоСервисОнлайн бесплатно 14 дней