A workshop: six hours a week returned to each mechanic
A workshop was losing roughly six hours per mechanic per week to reading government registers across three tabs. One plate entry now writes the whole file. For eight mechanics, that is a full working
The reading
A workshop in the East of England. Eight mechanics, a counter, a parts room, and a job book that had been kept in roughly the same form since the previous proprietor’s father. Work came in by phone or walk-in. The mechanic quoted the job. Before the quote, the mechanic opened four things:
- The DVLA tax and registration record for the plate.
- The DVSA MOT history for the plate.
- The parts catalogue, keyed by the vehicle VIN or by the mechanic’s recognition of the model from the plate.
- The job book, into which the mechanic transcribed the first three.
Four windows, three logins, two government portals, one piece of paper. Roughly 45 minutes per quote. The workshop quoted twelve jobs a day. Six hours a week per mechanic went to this before the mechanic touched a spanner.
The problem is not glamorous
Integration is dull work. There is no demo that makes it look impressive. There is no screen you can show a prospective customer that would make them say “ah, now I see what you build.” What you see, after the fact, is a job sheet that writes itself when the mechanic types the plate. There is nothing to admire except the absence of the four windows that used to be open.
Dull work compounds. Six hours a week, times eight mechanics, is forty- eight hours a week returned to the shop. That is a full-time mechanic’s chargeable hours, every week, recovered from the paperwork.
What we built
A custom DocType on the firm’s ERP that holds the registration plate as the primary key. Two scheduled jobs keep two government registers in sync:
- DVLA Vehicle Enquiry Service — polled for the plate at the moment the job is opened. Returns tax status, make and model, year, fuel type, CO₂, and engine capacity.
- DVSA MOT History — polled on the same event. Returns the full MOT record: dates, mileage, pass/fail, advisories.
The results are stored on the Job doctype at creation. The mechanic sees the whole file on one screen, writes nothing by hand, and the quote goes out in the time it used to take to open the second tab.
What we did not build
- No local caching of government data. The registers are the source of truth; the ERP holds the snapshot taken at the moment of the job. If a later check is needed, the job is re-opened and the registers are polled again.
- No ambition for a parts catalogue of our own. The firm’s catalogue continues to live in the parts system. We did not try to replace it. We linked to it.
- No workflow surrounding the quote. The mechanics do not want a seventeen-step process. They want one screen with everything on it. That is what the build delivers.
The numbers at thirty days
| What | Before | After |
|---|---|---|
| Minutes per quote | ~ 45 | ~ 6 |
| Hours per mechanic / week on quoting | ~ 6 | ~ 0.8 |
| Windows open per quote | 4 | 1 |
| Jobs quoted per day across the shop | 12 | 20 |
| MOT advisories missed at hand-off | occasional | 0 |
The twenty-jobs-a-day figure is the one the proprietor talks about. The margin on the extra eight is not materially different from the margin on the first twelve, which means the integration pays for itself every three days.
The standard
A new mechanic should be writing quotes by the end of the first morning. This is the test. If the system requires familiarity with four windows and two government portals before the mechanic can be useful, the system has not been built; a dependency has.
The system is for the shop. The shop is not for the system.