Согласование дополнительных работ и запчастей в автосервисе

Механик снял колесо и увидел, что тормозной диск изношен сильнее, чем думали при приёмке. Дальше обычно начинается самое уязвимое место автосервиса: мастер звонит клиенту, клиент говорит «ну делайте», работу выполняют, а при выдаче автомобиля выясняется, что клиент «соглашался на три тысячи, а не на семь». Спор, скидка «чтобы не ругаться», испорченный отзыв.

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

Ниже — живая схема основного процесса: её можно масштабировать колесом мыши, перетаскивать и открыть на весь экран.

Паспорт процесса согласования дополнительных работ

Код: ODT_SV0026.

Владелец процесса: руководитель сервиса (директор СТО или начальник сервисного центра).

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

Область применения: автосервисы и дилерские сервисные центры, а также любые сервисные компании с заказ-нарядом, где объём работ меняется после приёмки (ремонт техники, оборудования, строительно-отделочные работы).

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

Термины: заказ-наряд (ЗН) — основной документ ремонта с первоначальной сметой; предложение дополнительных работ — отдельный документ со списком позиций (работы и запчасти), который клиент согласует построчно; версия предложения — зафиксированный снимок состава, цен и срока на момент отправки клиенту; инцидент — факт выполнения работы без согласия клиента, требующий решения руководителя.

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

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

1. Дополнительные работы оформляются отдельным предложением со своим жизненным циклом: черновик → проверка мастером → отправка клиенту → решение → передача в работу → документы.

2. Клиент решает построчно, а не по документу целиком: у каждой позиции своё решение («согласовано», «отказано», «не решено») и согласованное количество. Только так честно поддерживается ответ «делайте колодки, а диски — в следующий раз».

3. Любое изменение после отправки клиенту — новая версия, а не правка старой. Ранее согласованные позиции остаются в силе, изменившиеся согласуются заново.

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

5. Работа без согласования не «дорисовывается» задним числом, а становится инцидентом, который блокирует закрытие заказ-наряда до решения руководителя.

У заказ-наряда есть только два источника денег: первоначальная смета, согласованная при приёмке, и позиции предложений со статусом «согласовано». Всё остальное в стоимость не попадает — никогда.

SIPOC процесса согласования дополнительных работ

Структура процесса по модели SIPOC — поставщики, входы, процесс, выходы, потребители.

Подробнее о самой модели — в методике SIPOC-диаграмма.

Логика выполнения процесса согласования дополнительных работ

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

1. Механик фиксирует дефект. В заказ-наряде создаёт предложение дополнительных работ: описание, узел, фото или видео, источник (осмотр, диагностика, обращение клиента), признак критичности для безопасности. Система показывает, что уже согласовано в заказ-наряде, чтобы не задвоить позиции.

2. Формируется предложение. Механик добавляет работы (с нормо-часами) и запчасти с количеством, при необходимости — аналоги. Система считает прирост стоимости и срока, проверяет дубли, запрашивает у кладовщика наличие и резерв.

3. Мастер-приёмщик проверяет предложение. Сверяет цены, нормативы и срок. Если нужна корректировка — возвращает механику с комментарием; если всё верно — готовит к отправке.

4. Предложение уходит клиенту. Мастер нажимает «Отправить»: фиксируется версия (состав, цены, нормо-часы, срок), клиент получает ссылку по SMS, в мессенджер или на почту. После подтверждения доставки запускаются таймеры ожидания ответа.

5. Клиент принимает решение по каждой позиции: согласовать, отказать или уменьшить количество. Цену, состав и срок клиент изменить не может — только решить по предложенному.

6. Решение фиксируется. Канал (портал, телефон, лично, мессенджер, подпись), кто зафиксировал, когда клиент решил и когда это внесли в систему (два разных времени), чем подтверждено: SMS-код, аудиозапись, скан, скриншот.

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

8. Пересчитываются стоимость, срок и документы. Текущая стоимость = первоначальная смета + согласованные позиции. Новый срок учитывает нормативы работ и срок поставки запчастей, мастер его подтверждает. Приложение к заказ-наряду, счёт и акт обновляются новой редакцией, а не перезаписью.

Развилки: мастер вернул предложение механику; клиент согласовал частично; клиент отказался; клиент не ответил в срок; запчасти нет на складе; решение получено по телефону на сумму выше порога.

Событие завершения: согласованные работы выполнены и отражены в документах, либо предложение закрыто отказом, отменой или истечением срока ответа (ремонт по первоначальной смете продолжается).

Варианты потока

Подпроцесс: клиент согласовал только часть

Частичное согласование — самый частый и самый рискованный вариант. Каждая позиция получает собственное решение, к оплате идут только согласованные. Если клиент отказался от критичной позиции (например, от замены тормозных колодок), ремонт не блокируется, но система требует проинформировать клиента о рисках, получить отдельное подтверждение отказа и поставить в заказ-наряде отметку «выпуск с рисками». Если отказ делает согласованную работу технически невыполнимой, мастер согласует объём с руководителем и при необходимости выпускает новую версию предложения.

Нестандартные ситуации

Отдельная схема показывает, как процесс ведёт себя в ситуациях, которые в реальном сервисе случаются каждую неделю:

• Изменилась цена после согласования. Прямая правка запрещена: мастер выпускает новую версию, неизменившиеся позиции остаются согласованными, изменившиеся уходят клиенту на повторное решение с пометкой «было → стало».

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

• Работу начали без согласования. Отметка «выполнено» блокируется, оформляется инцидент; руководитель решает: за счёт сервиса, предъявить клиенту через новую версию с пометкой «согласование постфактум» или переделать.

• Клиент не отвечает. Напоминание, повтор, эскалация мастеру с задачей «позвонить клиенту», затем статус «срок ответа истёк»; ремонт продолжается по первоначальной смете.

• Согласие получено по телефону. Обязательны ФИО говорившего, телефон, время, сотрудник и решение по каждой позиции; выше порога суммы нужно дополнительное подтверждение (SMS-код, фото подписи или запись звонка), иначе решение помечается «согласовано с оговоркой» и попадает в отчёт руководителя.

• Клиент передумал. Если работы не начаты — новая версия, резервы снимаются, сумма пересчитывается. Если начаты — инцидент с фиксацией выполненного объёма и решением руководителя.

• Двое сотрудников правят одно предложение. Молчаливая перезапись запрещена: второй получает сравнение версий и выбирает, что оставить, с записью в журнал.

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

Роли и ответственность в процессе

Роли распределены по матрице RACI: R — выполняет, A — отвечает за результат, C — консультирует, I — информируется.

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

Как строить такую матрицу для своих процессов — в методике Матрица ответственности RACI.

Показатели и контроль процесса

Доля решений клиента с доказательством: ориентир — 100 %; решения «с оговоркой» разбираются руководителем еженедельно.

Работы без согласования: ориентир — 0 инцидентов; каждый инцидент разбирается по сотруднику и сумме.

Время от обнаружения дефекта до отправки клиенту: измеряется по каждому предложению; рост показателя означает, что предложения застревают на проверке у мастера или у склада.

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

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

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

Рекомендуемые таймеры ожидания ответа: напоминание через 30 минут, повтор через 2 часа, эскалация мастеру через 4 часа, истечение срока через 24 часа. Значения настраиваются под режим работы сервиса.

Ресурсы процесса

Люди: механики, мастера-приёмщики, кладовщик, кассир, руководитель сервиса.

ИТ-системы: учётная система заказ-нарядов с модулем предложений, справочник работ и нормо-часов, складской учёт, канал уведомлений клиенту (SMS, мессенджер, почта) с журналом доставки, по возможности — телефония с записью звонков.

Материальные ресурсы: планшет или смартфон механика для фото и видео дефекта в цеху.

Бюджет: рабочее время на фиксацию и проверку предложения, расходы на SMS-уведомления; основная окупаемость — меньше спорных скидок и отказов от оплаты при выдаче автомобиля.

Нормативная база

Регламенты: регламент приёмки автомобиля и оформления заказ-наряда, регламент согласования дополнительных работ (этот документ), положение о порогах телефонного согласования и таймерах ожидания.

Законодательство: Закон РФ «О защите прав потребителей» (статья 16, пункт 3) — исполнитель не вправе без согласия потребителя выполнять дополнительные работы за плату, а потребитель вправе отказаться от их оплаты. Правила оказания услуг (выполнения работ) по техническому обслуживанию и ремонту автомототранспортных средств, утверждённые постановлением Правительства РФ от 29 мая 2025 г. № 780, — о заказ-наряде, согласовании работ и документах при выдаче автомобиля.

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

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

Риски процесса и меры контроля

• Спор «я на это не соглашался». Мера: построчное решение с каналом, временем и доказательством, приложение к заказ-наряду с историей версий.

• Цена в счёте выше согласованной. Мера: цены фиксируются в версии при отправке, изменение — только новой версией с повторным согласованием изменившихся позиций.

• Механик начал работу до ответа клиента. Мера: блокировка отметки «выполнено», инцидент, решение руководителя, отчёт по инцидентам.

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

• Отказ от критичной работы оборачивается претензией после аварии. Мера: информирование о рисках по шаблону, подтверждение отказа, отметка «выпуск с рисками» в заказ-наряде и акте.

• Две правки одного предложения затирают друг друга. Мера: контроль версий при сохранении и окно сравнения.

Связи процесса

Предшествует: приёмка автомобиля и оформление заказ-наряда с первоначальной сметой.

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

Смежные: складской учёт и заказ запчастей у поставщиков; обработка претензий клиентов.

Методики, на которых построен процесс:

• SIPOC-диаграмма — границы, входы и выходы процесса.

• Матрица ответственности RACI — кто выполняет и кто отвечает за каждый шаг.

• Пока-ёкэ (Poka-Yoke) — защита от ошибок — блокировки вместо инструкций «не забудьте согласовать».

• Процессы от клиентского пути — предложение глазами клиента: понятно, сколько стоит и что будет, если отказаться.

• Система менеджмента качества ISO 9001 — управление документированной информацией и изменениями.

Типовые ошибки при согласовании дополнительных работ

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

• Согласовывать «пакетом». Клиент соглашается на часть, а в системе стоит «согласовано» на всё — отсюда спор при выдаче.

• Фиксировать телефонное согласие одной галочкой. Без ФИО говорившего, времени и сотрудника доказать решение клиента нельзя.

• Менять цену «внутри» уже отправленного предложения. Клиент видел одну сумму, в счёте другая — даже если разница объяснима.

• Не различать время решения клиента и время записи в систему. При разборе спора это ключевой вопрос: сначала сделали или сначала согласовали.

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

• Удалять ошибочные позиции. Любая позиция и любое решение должны оставаться в истории — удаление заменяется отменой с причиной.

Уровни зрелости процесса

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

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

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

Уровень 4 — управляемый: процесс измеряется — время ответа, конверсия предложений, инциденты, решения «с оговоркой»; руководитель еженедельно разбирает отчёт об изменениях стоимости.

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

Управление документом

Ответственный за актуализацию: руководитель сервиса.

Версия: 1.0.

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

Реализация процесса в OrgDevTools

Схемы процесса — в инструменте «Процессы»: основной процесс, частичное согласование и нестандартные ситуации открываются в BPMN-редакторе, их можно поправить под свой сервис — изменения сразу видны везде, куда схема вставлена.

Регламент и база знаний — этот документ копируется в базу знаний компании и становится источником для ИИ-советника: мастер или механик спрашивает «что делать, если клиент согласовал по телефону на 45 тысяч» и получает ответ по вашему регламенту.

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

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

Сама учётная система автосервиса (заказ-наряды, склад, касса) в OrgDevTools не заменяется: платформа хранит процесс, регламент, роли и схемы, а учёт остаётся в вашей отраслевой системе.

ИИ-автоматизация процесса

Часть шагов процесса могут выполнять ИИ-агенты — при этом решение по деньгам и по безопасности всегда остаётся за человеком.

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

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

Можно ли согласовать дополнительные работы устно?

Можно, но решение нужно зафиксировать: кто говорил, с какого номера, когда, кто из сотрудников принял решение и по каким позициям. Для крупных сумм — дополнительное подтверждение: SMS-код, фото подписи или запись звонка.

Что делать, если клиент не отвечает?

Напоминания по таймерам, затем задача мастеру позвонить. Если ответа нет — предложение закрывается как «решение не получено», а ремонт продолжается по первоначальной смете. Выполнять дополнительные работы «на всякий случай» нельзя.

Как быть, если цена запчасти изменилась после согласования?

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

Клиент отказался от замены тормозных колодок. Можно отдать машину?

Да, если клиент проинформирован о рисках и подтвердил отказ, а в заказ-наряде и акте стоит отметка «выпуск с рисками». Без подтверждения отказа передавать работу и выдавать автомобиль процесс не позволяет.

Механик уже выполнил работу без согласования. Что теперь?

Оформить инцидент: что сделано, кем, когда и почему. Руководитель решает — за счёт сервиса, предъявить клиенту с согласованием постфактум или переделать. До решения заказ-наряд не закрывается.

Подойдёт ли процесс не для автосервиса?

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