Op codes: turning 'it is making a noise' into something bookable

An op code, short for operation code, is the smallest unit of work a service department can sell, schedule and invoice. Behind its description sit a labour time, a pricing method, the skill level and bay type the job needs, and the parts normally consumed. A shop's scheduler books op codes. It cannot book a sentence.

Which is why a free-text "tell us what is wrong" box breaks a booking flow. The scheduler needs a duration, a skill and a bay to hold time, and none of the 3 is derivable from "a noise when I brake". If the software will not translate, an advisor does — next morning, on the phone, which is how an online booking turns back into an inbound call.

What the code carries besides a name

Labour time has the most disputed provenance. Warranty work is generally allowed the manufacturer's published time; customer-pay work is priced from a commercial labour-time guide or the shop's own measured average, and the 2 rarely agree. Those hours are what the capacity model behind the calendar consumes, so an optimistic code oversells the day.

Diagnosis buys time; maintenance buys a known job

• Maintenance and defined repair codes. Scope is fixed before the vehicle arrives, so the duration holds and the total can be published — the only lines that belong in a booking flow showing prices.
• Diagnostic codes. They buy a block of technician time, commonly 0.5 to 1.5 hours, ending in a finding and an estimate. They do not buy a repair.
• Campaign, recall and warranty codes. The manufacturer sets scope and time, and eligibility attaches to the individual vehicle, not the model, so each needs a VIN-level check.

Who owns the list, and why it drifts

The list is maintained locally, by whoever has write access, and that is where drift starts: 3 codes for 1 oil service because 3 managers each added 1, dead codes nobody has sold in 2 years, times last reviewed when the model was current. Which codes apply at all depends on the exact build, so the menu must be filtered against the option data behind the vehicle record — engine, gearbox, drivetrain, factory options.

The mapping layer: customer words on one side, codes on the other

1. Rank last year's repair orders by op code frequency. The flow needs the head of that list, not the catalogue.
2. Write the phrasing in counter language. "Knocking over bumps" is a real query; "front suspension component inspection" is not.
3. Mark each mapping instant-confirm or needs-a-person. Anything whose duration depends on what is found is never instant-confirm.
4. Give unmatched input 1 review code, 1 owner, 1 response window. Log the raw text beside the chosen code and review monthly.

What the mapping layer has to refuse to do

It must not guess. A map that books its nearest match on low confidence produces a confirmed appointment for the wrong work, found by a technician at 9am with the customer gone. Nor can it lose the customer's own words: an update naming a job nobody recognises causes the call it was sent to prevent — the mechanism behind status texts that send and still produce calls.

A flow that takes free text and holds an hour has booked a conversation, not a job.

Downstream, the pricing method decides whether an estimate goes out without an advisor, and its invoice line is what a pay-by-link service flow shows. Upstream, the code is 1 of the fields a booking must capture. The mapping layer is bounded — a table, a confidence rule, a queue, a log — so it scopes as an MVP build. Filed under service booking and customer communication, part of our automotive work.

• service booking
• op codes
• shop scheduling
• dealership service