How We Know the Shop Software Is Right

Every shop system in the world will show you a dashboard. Jobs done this week, money collected, technician hours. The numbers are always neat, because a number on a screen is just a query that ran without throwing an error.

The real question is what the software does on the day the query is quietly wrong. Ours has been wrong. Five times in the last few months we found a figure that looked fine and was not, and each one is the reason we now trust the ones that are left.

A Paid Bill That Left the Job Open

Money reached the database three different ways. A service advisor recording a payment in the app. A customer paying by card from their own follow along page. And the historical import from the old system.

Only the first one closed the job. Pay by card and the bill settled while the work stayed open forever. Twenty jobs were sitting at the wrong status, nine thousand eight hundred and seventy five dollars between them, including one job for over five thousand marked complete and another still showing as scheduled weeks after it had been paid for.

The fix that mattered was not in the payment page. It was a rule in the database that fires no matter which door the money comes through, because the next way money arrives will be written by somebody who has not read that file. It will not close a cancelled job and it will not close anything on a part payment, and both of those were proven with a real part payment followed by the balance rather than assumed.

Six Hundred Finished Jobs With No Finish Date

A mobile shop settles most work at the curb. The job goes from estimate straight to paid and never passes through the status that stamps a completion date.

So six hundred and seventy two finished jobs had no day attached to them. They were done, they were paid, and they were invisible to any report that counts what got finished this week.

This is the failure that is hardest to catch, because nothing looks broken. The dashboard shows a smaller number and a smaller number is not an error. Somebody has to go looking for work that exists and is not being counted.

The Payroll Run That Accused Four People

Payroll filed every payment by the day it was paid rather than the period it covered. A catch up payment for an earlier week landed in the current window while the work it paid for sat outside it.

Four people read as overpaid. One of them by more than thirteen hundred dollars. Nobody was overpaid. Across all time every balance was either zero or money still owed.

The columns that record which period a payment covers had existed since the table was created. Nothing had ever read them. That is a normal kind of bug and a horrible one to ship, because the report is confidently telling an owner that a technician owes the shop money.

The Week the Assistant Went Quiet and Said Nothing

The AI features run on a paid account. The account ran out. The service started answering every request with an error about the balance, and four things stopped at once. The quote drafter, the repair manuals, the tool that reads a vehicle out of an incoming message, and the repair question box on the front page.

Nothing anywhere said so. The background job that reads new leads ran eight times in a row, once every five minutes, and reported success every time with the same note saying there were nineteen hundred left to read. The count never moved. It threw an error, so nothing got marked as read, so the same forty leads came back on the next pass forever.

The check that had been in place asked whether the key was configured. It was. The check now asks the second question, which is whether the model actually answers. One sentence in, twelve words back. That check costs almost nothing to run and it is the only reason this was found in a quiet week rather than in front of a room.

The Tests Read the Screen, Not the Query

This is the part that changed how the whole thing is built.

A test that runs the same query the page runs will agree with the page every time, including when both are wrong. So the tests now compare each tile on the summary screen against the page it takes you to when you click it, in every time window, and fail if the two disagree. A separate one refuses to pass if any paid bill anywhere has left a job open behind it.

Neither test knows anything about how the numbers are calculated. They only know that two things a shop owner can see with their own eyes have to match. Every bug above would have been caught on the day it shipped by one of those two rules.

Would the One Man Shop Hit This

The first outside shop on the system is a solo owner operator. He is the front desk and he is the technician, and he does not book anything, because there is nobody to book it for.

The guided setup walk required a scheduled job before it would continue. He wrote two jobs, priced one at fourteen hundred dollars, took ten photographs and did the work, and both jobs sat there with no approval on file, no bill and no payment, because the software was waiting for a step that his kind of shop never performs.

The walk starts at the estimate now, and the first step puts the approval form on screen so a yes spoken at the car can be recorded on the spot. The rule this left behind gets applied to every new feature. Anything that assumes the shop has separate people for separate jobs will not work for most of the shops that sign up.

What Any Shop Should Ask a Software Vendor

Three questions, and they are all answerable in a demo.

Ask what happens to the job when a customer pays from their own phone rather than at the counter. If the answer is a description of the payment screen rather than of the job record, the two are not connected and you will find out later.

Ask to see a report of work that was finished and is not being counted anywhere. A vendor who has never looked for that will not understand the question.

Ask what the system does when one of its own services stops responding. Silence is the wrong answer. A tool that only tells you it is working is a tool that will tell you it is working on the day it is not.

None of this makes software good. What makes it good is that when it is wrong, something in the building says so before a customer does.