Estimating on the RO vs a separate tool

Where the estimate gets built decides which record you can produce when somebody asks what was authorized. Built on the repair order, the approved price and the jobs the technician works from are the same object. Built in a separate tool, they are two objects held together by whoever did the copying.

Key takeaways

• The version the customer authorized is the one that has to be findable six weeks later.
• Every copy between systems is a chance for a price to change with nobody noticing.
• California law requires a written estimate and consent before the total goes past it.
• A parts list outside the ticket can drift from the parts that get ordered.

What does the copy step cost?

Drift, and it is quiet. The estimate the customer approved and the jobs on the ticket stop matching, and nobody finds out until the invoice.

What happens to the authorization trail?

It splits, and the law cares about that trail.

California Business and Professions Code section 9884.9 requires the repair dealer to "give to the customer a written estimated price for labor and parts necessary for a specific job." It goes on: "No charge shall be made for work done or parts supplied in excess of the estimated price ... without the oral or written consent of the customer that shall be obtained at some time after it is determined that the estimated or posted price is insufficient and before the work not estimated or posted is done."

Read that as a sequence of records. What was quoted, what the customer agreed to, when the shop found out it would run over, and what the customer said then. A shop that holds all four on one ticket answers a dispute in a minute. A shop holding two of them in an estimating tool and two in the ticket is reconstructing a story from memory.

Those records also have to outlive the job. Section 9884.11 requires a repair dealer to "maintain any records that are required by regulations adopted to carry out this chapter", and puts a term on it: "All of those records shall be maintained for at least three years." Six weeks is nothing against that clock. Keeping the trail on the ticket keeps it for as long as the ticket lives, and keeping half of it inside a second product keeps it for as long as somebody renews the subscription.

The invoice at the end of that sequence has its own rules. Section 9884.8 requires that "service work and parts shall be listed separately on the invoice, which shall also state separately the subtotal prices for service work and for parts, not including sales tax", and it requires the invoice to state whether a part was new, used, rebuilt or reconditioned. Every one of those fields has to survive the trip from wherever the estimate was written. A copy step is where they get lost, and the part-condition field is the first to go, because it is the one nobody retypes.

Which fields go missing in the copy?

Four fields go missing more than the rest, and they usually go in this order.

The part condition goes first. A reman alternator quoted in a side tool becomes an alternator on the ticket, because the person copying was looking at a price and a description, and the statute wants that field on the invoice.

The hours go second, and they go by rounding. A 1.7 in one system becomes 1.7 in the other most of the time. It becomes 2.0 when somebody is tidying up a total, and nothing anywhere records that a number was changed.

The markup goes third, and this one costs the most. Your matrix lives in the system that holds your pricing rules. A price typed in from outside gets whatever the person typing believed the markup was that day, and a shop can run for months on a number somebody half-remembered.

The wording goes fourth. What the customer approved reads one way and what appears on the invoice reads another, and now a customer with a question is comparing two documents that describe the same job in different words.

None of these show up as an error. That is the whole problem with them.

When is a separate tool defensible?

When the shop management system cannot represent the work at all. Fleet quoting with negotiated rates and long project builds are the usual cases, and both are quoting problems rather than repair estimating problems. Everyday inspection-to-estimate work does not need a second screen.

There is a second defensible case, and it is temporary. A shop mid-migration runs two systems on purpose for a while, and during that window the discipline is to name one of them as the record and stick to it. The failure is not running two systems. The failure is never deciding which one is true.

What happens to the parts order?

It goes wrong in a way that costs a bay.

When the parts list lives in the estimating tool and the order gets placed from the ticket, the two lists have to be reconciled by whoever is ordering. Miss a gasket and the technician finds out with the vehicle in pieces. Order against the old version of the estimate and you have parts on the shelf for work the customer declined.

Neither of those looks like a systems problem when it happens. It looks like somebody made a mistake, so the shop tightens up a process, and the same thing happens again six weeks later because the second list never went away.

Which record does the technician work from?

Whichever one is on the ticket, which is the argument in one sentence.

A technician does not open your estimating tool. They open the repair order, read the jobs on it and start work. If the approved estimate lives somewhere else, then what the technician performs and what the customer agreed to are two documents that were reconciled by hand, and any line that fell out of that reconciliation is either work done for free or work billed without consent.

What does a second screen cost the counter?

It costs attention, and it takes it at the worst possible moment.

An advisor pricing a job with a customer on hold is switching between the ticket, a labor lookup and supplier tabs already. Adding an estimating product makes that four contexts, and the one that gets dropped is whichever was least urgent thirty seconds ago. That is how a job gets priced correctly in one window and sent from the stale version in another.

There is a training cost underneath it too. Every new hire now has to learn two products and the rule about which one wins. That rule lives in somebody's head until the day they are on holiday, and then it lives nowhere.

Ask the advisors before you ask the vendor. The people who work the counter know exactly which screen they trust and which one they retype from, and their answer is usually more useful than a feature list.

Does the answer change for a multi-store group?

The principle holds and the practice gets harder.

Groups collect systems, usually through acquisition, so one store runs one product and another store runs something else. The temptation is to buy a single estimating tool that sits above all of them and gives the group one way of quoting. What that buys is consistency in the tool and two records at every store.

The better version keeps the estimate on the ticket in whatever system that store runs, and pushes the consistency into the pricing rules instead. Labor rate, markup and canned job wording can match across stores without the estimate leaving the ticket at any of them. Reporting is a reporting problem and it belongs above all this, not in the middle of it.

Which one does Mechanica do?

The repair order. The drafted jobs land on the same ticket the technician was already working, and the advisor reviews them where they already review estimates. When the ticket already carries jobs, only the missing work gets drafted. More on that in how an estimate gets priced and on the Tekmetric integration page.

What should a shop check?

Take one ticket from last week and count how many systems its price passed through between the inspection and the invoice. Then find where the customer's approval got recorded. If the answer to the second question is a different system than the answer to the first, that is the conversation to have.

Then run the same ticket the other way. Start from the invoice and work backwards. Can you produce the original estimate, the approval that followed it, and every change the customer agreed to along the way, without asking anybody what they remember? A shop that can do that in two minutes on a random ticket has one record. A shop that needs to open a second product and cross-reference has two, whatever the vendor called it.

Do this on a ticket that went sideways. The clean ones reconcile themselves. The value of a single record shows up on the job that changed twice, ran over, then finished with a customer unhappy about the number, because that is the ticket somebody will ask you about later.

The estimate turnaround checklist has the rest of the measurement, the glossary entry on canned jobs covers what should already be stored on the ticket, and the compare hub has the other trade-offs.