История ремонта на СТО часто распадается между бумажным заказом-нарядом, фотографиями в телефоне мастера, перепиской администратора и бухгалтерской оплатой. При следующем визите видно, что клиент когда-то был, но непонятно, с какой жалобой приехал, что обнаружили, какие работы согласовали и какую деталь установили.
Полезная история — это не длинное текстовое поле «комментарий». Она состоит из связанных событий и объектов: клиент, автомобиль, визит, состояние при приёмке, диагностика, версии сметы, работы, запчасти, исполнители, оплата, гарантия и рекомендации. Тогда данные можно использовать в следующем ремонте, а не только хранить в архиве.
Что должно принадлежать одному автомобилю
Карточка автомобиля объединяет все визиты, но каждый ремонт остаётся отдельным заказом-нарядом. Это позволяет видеть общую хронологию и одновременно не смешивать причины, согласования и деньги разных обращений.
| Объект | Какие данные хранит | Зачем нужен в истории |
|---|---|---|
| Клиент | Контакты, условия связи и несколько автомобилей | Понимание, с кем согласовывали решение |
| Автомобиль | VIN, модель, модификация, пробег и признаки | Точная привязка всех визитов |
| Визит | Дата, жалоба, запись, приёмка и ответственный | Причина появления автомобиля на СТО |
| Заказ-наряд | Диагностика, работы, детали, цены и статусы | Операционный и финансовый результат |
| Материалы | Фото, замеры, документы и комментарии | Подтверждение состояния и выполненных действий |
| Рекомендации | Что отложено, на какой срок или пробег | Основа следующего обращения |
История начинается с приёмки
До ремонта фиксируются пробег, уровень топлива при необходимости, комплектность, видимые повреждения и жалоба клиента его словами. Фотографии должны прикрепляться к конкретному визиту, а не оставаться в общей галерее телефона. Это помогает отличить исходное состояние от результата работ.
Если автомобиль передаётся с дополнительным оборудованием или ценными предметами, их наличие отмечается по утверждённому правилу СТО. Фиксация должна быть разумной: цель не создать сотни фотографий, а сохранить факты, которые влияют на ремонт, ответственность и выдачу.
Диагностика и согласование не должны перезаписывать друг друга
Первичная смета может измениться после разборки или дополнительной проверки. Если система хранит только последнее значение, невозможно понять, что клиент видел и почему итоговая сумма стала другой. Каждая значимая версия должна иметь дату, состав и статус.
| Событие | Что сохраняется | Почему важно |
|---|---|---|
| Первичный запрос | Жалоба и ожидаемый результат | Не подменять слова клиента выводом мастера |
| Диагностика | Обнаруженные причины, замеры и вывод | Показать основание предложения |
| Смета | Конкретные работы, детали, цены и срок | Зафиксировать предмет согласования |
| Согласование | Принятые и отклонённые позиции, время и канал | Не начинать неподтверждённые работы |
| Изменение | Новая версия и причина корректировки | Объяснить отличие от первоначальной суммы |
| Завершение | Фактически выполненное и установленное | Сопоставить план с результатом |
Установленная деталь должна оставаться в истории
В заказе-наряде сохраняются производитель, артикул, количество, источник, цена и при необходимости серийный или партийный признак. Деталь связывается с работой, для которой использована. Если позицию подбирали по VIN, сохраняется исходная OEM-позиция и выбранный крос или аналог.
При гарантийном обращении сотрудник видит, когда и на каком пробеге деталь установили, кто выполнил работу и какие условия действовали. Без этой связи приходится искать накладные, сообщения и память мастера.
Фиксируйте фактическое выполнение
Согласованная работа и выполненная работа — не одно и то же. Мастер отмечает начало и завершение, фактический результат, использованные материалы и выявленные дополнительные обстоятельства. Невыполненная позиция не должна автоматически попадать в акт как завершённая.
Фотографии после работы полезны там, где результат невозможно показать клиенту при выдаче: скрытый узел, очищенная поверхность, проложенный кабель или установленная внутри деталь. Они прикладываются к операции, а не заменяют описание.
Жизненный цикл данных ремонта
| Этап | Кто добавляет данные | Что получает следующий участник |
|---|---|---|
| Запись | Администратор | Клиента, автомобиль, жалобу и время |
| Приёмка | Приёмщик | Пробег, состояние, комплектность и фото |
| Диагностика | Мастер | Причину, замеры и необходимые действия |
| Согласование | Менеджер | Подтверждённые работы, детали и лимиты |
| Исполнение | Мастер и склад | Факт работ и выданные запчасти |
| Выдача | Приёмщик и касса | Оплату, результат, гарантию и рекомендации |
| Следующий визит | Любой ответственный | Полный проверяемый контекст |
Рекомендации должны возвращаться в работу
Если клиент отложил замену, рекомендация получает описание, приоритет, ориентировочный срок или пробег. При следующей записи система показывает её, но сотрудник проверяет актуальность. Это полезнее, чем свободная заметка, которую никто не откроет.
Как внедрить без лишней бюрократии
Определите обязательный минимум для каждого этапа и не заставляйте сотрудников дублировать данные. Поля должны появляться в момент, когда информация реально возникает. Проведите один заказ от записи до повторного визита и проверьте, можно ли восстановить ход ремонта без звонков участникам.
Готовая модель представлена в решении Business Reactor для СТО. VIN-подбор связывает автомобиль с OEM-позициями, а AutoParts сохраняет выбранные детали, кроссы и аналоги в товарном контуре.
История ремонта становится ценностью, когда помогает принять следующее решение. Связанные события дают СТО контекст, ускоряют повторное обслуживание и позволяют объяснить, что происходило с автомобилем на каждом этапе.
