Somewhere in most established operations there is a system nobody talks about. It was paid for. There was training. For about a month everybody used it. Now the office runs on a spreadsheet again, the guys on site are back to WhatsApp, and the licence renews quietly every year because cancelling it would mean admitting it.
That is not a story about bad software. It is almost always one of four things, and every one of them is visible in the first three weeks if you know to look.
1. It was slower than the thing it replaced
This is the big one, and it is nearly always about the field.
A technician standing at a switchboard with gloves on has two options for recording what he just did. He can photograph it and send it to a group chat, which takes eleven seconds. Or he can open an app, wait for it to load, find the job, tap through four screens, and fill in a form designed by somebody who has never held a multimeter.
He will send the photo. Every time. Not because he is difficult, but because he is trying to finish the job and get to the next one.
Any system that is slower at the moment of capture than the informal habit it replaces will lose to that habit. The office side can be flawless and it will still lose, because the office side runs on data the field never entered.
What to check before you buy: ask to see the phone version, doing a real job, on a bad connection. Not the tablet demo in a boardroom. Count the taps between opening the app and the job being done. If it is more than a handful, your team already knows how this ends.
2. It made everyone learn a new language
The system calls it an “asset”. Your yard has always called it a machine. It calls it a “work order”. Your job cards have said job card since 1998. It insists a job has stages called New, In Progress and Closed, when yours have always been Booked, Out, Back, and Checked.
Every one of those mismatches is small. Together they mean that using the system requires translating, all day, and translation is friction. People route around friction.
The fix is not training. Training teaches people the translation. The fix is that the software should have used your words in the first place.
What to check before you buy: ask whether your stages, your terminology and your fields can be changed, and whether that costs extra. If the answer involves a developer or a change request, you are going to be translating forever.
3. Nothing depended on it
The system was introduced alongside the old way rather than instead of it. Job cards still came back on paper. The invoice run still worked off the spreadsheet. The Monday meeting still used the whiteboard.
If the business keeps functioning perfectly well when nobody enters anything, then entering things is optional, and optional work does not happen when a yard is busy.
A system starts sticking on the day something real depends on it. The invoice cannot be raised until the job is closed. The machine cannot go out until the condition report is captured. The technician does not get his next job until the last one is signed. That is not bureaucracy, it is the difference between a system and a filing habit.
What to check before you buy: ask what breaks if a person skips a step. If the answer is “nothing”, it will be skipped.
4. Nobody in the business owned it
Every system that works has one person inside the business who cares whether it is being used, notices when it is not, and fixes the reason rather than sending a reminder. It does not have to be a technical person. It usually should not be the owner.
Systems that fail were installed by a supplier, handed to everyone at once, and then belonged to nobody. Six weeks later two people had drifted off it, the data had holes in it, and once the data has holes nobody trusts the reports, and once nobody trusts the reports the whole thing is decoration.
What to check before you buy: decide who that person is before go-live, and tell them. It is a small amount of somebody’s week, and it is the difference between the system working and the system being renewed out of embarrassment.
The uncomfortable pattern
Look at those four again. Not one of them is about features.
Buying decisions in this category are almost always made on a feature list, because a feature list is the thing that can be compared in a spreadsheet. But the reason systems fail is never a missing feature. It is speed at the point of capture, language, consequence, and ownership.
Which means the demo you should be asking for is not the one where a salesperson shows you the reporting. It is the one where somebody does one real job on a phone, in your words, and you watch how long it takes.
That is the demo we run, with your machines or vehicles and your job types loaded into it. Thirty minutes. Book one, or look at the pricing first.