Skip to content
← Operations Library

Auto repair operations

When the Repair Changes, Get Approval Before the Work Continues

Keep the revised estimate, the customer's decision, the work performed, and the invoice connected without slowing every job down.

Browse the complete Operations Library →
A vehicle brake assembly beside a workshop tablet with separate original and proposed work panels and an unused torque wrench
Conceptual illustration: discovering additional work and receiving approval for it are different events.
In this articleKeep the original agreement visibleFollow one proposed addition through the shopGive each supplemental item a complete recordLet software compare and people resolve uncertaintyMeasure the exceptions rather than just response speed

A vehicle is on the lift, the technician has found another problem, and the customer is not answering. The operational question is immediate: what can the shop do next? A clear supplemental-work process makes the proposed addition visible, records the customer's actual decision, and keeps unapproved work from slipping into the job simply because the vehicle is already apart.

That does not require replacing the shop management system. It requires keeping four records connected: what was estimated, what was authorized, what was performed, and what was billed. When they disagree, the adviser needs a specific exception to resolve, not another dashboard full of job totals.

Keep the original agreement visible

An inspection finding is not an authorization. A technician may identify a condition and recommend an additional task, but that recommendation should remain separate from the work the customer already accepted. Otherwise a later reader cannot tell whether the extra line was part of the original job or added afterward.

Preserve the original estimate and create an identifiable revision. Describe the additional parts and labor, their cost, the revised total, and any change to the expected completion plan. Explain the finding in language a customer can understand without overstating urgency or implying a diagnosis that the technician has not established.

The exact legal requirements depend on the shop's jurisdiction. For example, California's Bureau of Automotive Repair guidance describes preparing a revised work order, contacting the customer, and documenting additional authorization before extra repairs or charges proceed. The operational model here supports that kind of traceable decision; a local specialist should establish the rules that apply to a particular shop.

Follow one proposed addition through the shop

Consider an illustrative brake-service job, not a reported Adaptiv Stratum engagement. The customer has approved the original estimate. During inspection, the technician records an additional finding and photographs the relevant condition. The adviser creates a proposed addition referencing the existing repair order and the new estimate revision.

The shop management system remains the job's source of truth. A message sent to the customer contains the proposed work, the changed cost, and a way to ask questions. The message service records delivery separately from any reply. A delivered message establishes neither understanding nor acceptance.

Suppose the customer responds, "Call me first." The workflow leaves the addition awaiting a decision and alerts the adviser. It does not convert the response into an approval because the words sound cooperative. The adviser makes the call and records the decision using the shop's approved process, with the supporting communication linked to the same job.

Once the required approval record is complete, ordinary system rules can make the approved items available to the technician. If the customer declines the addition, the adviser records the declined scope and agrees the next step with the customer. Any question about safe completion, reassembly, or releasing the vehicle goes to the responsible technician and adviser rather than being improvised by a chatbot.

If the customer accepts only one of two proposed items, record that narrower decision. Do not mark the entire supplement approved. A later change to the accepted scope or price needs its own review under the shop's applicable rules; an earlier response should not silently authorize the new version.

At invoicing, a comparison flags an added item with no matching approval reference, or an approved item not reflected in the performed-work record. The adviser resolves the mismatch before presenting the final account. The useful outcome is an explainable job, not a higher count of automated messages.

Follow the changed repair The work order should show which proposed change reached which decision.
  1. Describe the additionIdentify the finding, proposed parts and labor, and revised estimate.
  2. Request a decisionPresent the changed scope and cost through the approved channel.
  3. Record the responseLink the customer's decision to that revision and those items.
  4. Reconcile the jobCompare authorized work, performed work, and the invoice.

Give each supplemental item a complete record

A practical approval register can begin with the information already available in the shop system:

  • Job and revision: repair order, vehicle reference, estimate revision, and the original approved scope.
  • Proposed addition: finding, supporting inspection evidence, parts and labor, additional cost, and revised total.
  • Customer communication: recipient, channel, message or call record, and the time the request was made.
  • Decision: the exact items accepted or declined, supporting evidence, and the adviser who verified the record.
  • Completion: release for work, performed-work reference, invoice line, and any unresolved difference.

Keep personal information and communications within the shop's authorized systems. The purpose is not to copy every conversation into several new tools. It is to make a reliable link from the decision back to the right revision.

Let software compare and people resolve uncertainty

A conventional database and workflow rule can prevent a proposed item from appearing as approved merely because someone edited an estimate. It can also require an approval reference before a particular work state changes. These are ordinary software controls, not tasks that need a language model.

AI may help turn technician notes into a draft explanation, identify differences between estimate versions, or flag an invoice line that appears inconsistent with recorded scope. A person checks those interpretations against the original records. An unclear inspection note stays unclear until the technician resolves it.

The assistant should not decide whether someone is entitled to authorize work, manufacture a missing response, or declare a communication legally sufficient. Nor should it change labor prices or add recommended work while preparing a message. Its output is a draft or a discrepancy for an adviser, not a new business authority.

Measure the exceptions rather than just response speed

Start with one repair category and review jobs that changed after inspection. Count additions awaiting a decision, cases with missing approval links, invoice mismatches, and instances where staff had to reconstruct an earlier conversation. Separate customer waiting time from internal delay so a faster message is not mistaken for a faster decision.

Ask an adviser who did not handle the job to reconstruct one completed example. Can they identify the original scope, the change, the customer's decision, and what was actually billed? If not, improve the record or handoff before expanding the automation. The strongest improvement may be a clearer estimate revision and a smaller number of ambiguous states, not a more persuasive virtual assistant.

Sources & further reading

Primary references checked October 19, 2026. Examples are illustrative, not reported client outcomes.

Review one repair that changed after inspection

Check whether a colleague could reconstruct the added work and its approval without asking the adviser to remember the conversation.

Explore structured modernization →