What should a shop ask before buying management software?

Why don't features predict whether software sticks?

Because features are what a system does when someone is looking after it.

A demo is a best-case day. One person, no interruptions, complete data, nothing on fire. Every product in this category looks reasonable under those conditions, which is why demos are a poor way to choose between them.

The day that decides whether you keep using it looks nothing like that. Two technicians out, four unbooked vehicles in, a fleet account wanting dates, the phone going. On that day the fastest tool in the building wins, and if the software isn't the fastest tool, the whiteboard gets updated instead. Once the board is right and the screen is wrong, the screen is finished. Nobody trusts a system that misled them while they were busy.

So the useful questions are all versions of the same question: what does this need from me, and what happens when I can't give it?

This is the second half of the decision rather than the first. Work out what to shortlist on first, which is largely about whether a system covers the workflow you actually run and is priced for a shop your size. The questions below are what you put to the two or three that survive that, because they're the ones that decide whether you're still using it in a month.

The eight questions

1. What does this do for me in week one, before anyone is trained? If the answer is nothing, you're being asked to lend the business hours against a promise. That's the pattern behind most of the software that has failed in this industry.

2. What has to be entered before it's useful? Every field someone has to fill is a field someone will skip on a bad day. Ask specifically what breaks when a job goes in incomplete.

3. What happens if nobody touches it for six hours? The important part is whether it goes quietly stale. A system that looks current but isn't is worse than no system, because someone will give a customer a date from it.

4. Can the apprentice use it without being shown? The whiteboard's real advantage is that anyone in the building can correct it. Any replacement that needs a trained operator has lost something the board had.

5. Who at your company will I speak to in week three? Week three is when adoption actually fails. Ask who notices, and what they do about it. A vendor with no answer has never looked.

6. If I stop paying, what happens to my customer and vehicle history? Ask for the export format in writing. Moving data between systems is usually more possible than people fear, but you want to know before you're leaving rather than after.

7. What does this replace, and what does it sit alongside? Anything that sits alongside the whiteboard rather than replacing it means two records, and two records means one of them is wrong. That's the same problem fleets and shops already have with each other, and it ends the same way: nobody trusts either version.

8. Can I speak to a shop my size that stopped using it? Nobody will say yes. Ask anyway, and listen to how they handle the question. A vendor who has thought seriously about abandonment will have something honest to say about it.

What should you make of the answers?

Notice which questions the vendor finds surprising.

A salesperson who has never been asked what happens after six hours of nobody touching the system is not necessarily selling a bad product. But they're selling a product nobody has assessed on the thing that decides whether it survives, which tells you where their attention has been.

Notice also which answers are about you changing rather than the tool changing. "It works well once your team gets into the habit" is a real answer, and it's telling you the tool needs a habit you'll have to fund out of hours you don't have.

What should you check on your own side first?

Two things, both cheap.

Ask the person who would actually use it, not just the person paying for it. In most shops those are different people, and the second one's opinion decides the outcome. A system the owner likes and the front desk resents will be abandoned by the front desk within a month, quietly.

Then write down what you're trying to fix, in one sentence, before any demo. Most shops arrive at this decision because something specific is going wrong. Approvals sitting unanswered, customers not being called back, the same question being asked fifteen times a day. Naming it first stops you being sold a system that solves a different problem well.

The short version

Demos test software on its best day. Adoption is decided on its worst one. So ask what the tool does in week one, what it needs entered, what happens when nobody touches it, whether anyone in the building can use it without training, and who notices in week three when it starts slipping. And ask the person who'll be using it, not just the person signing for it.

Autograff is being built with those questions as the design constraint. ShopOS is our product for repair shops and FleetOS is our product for fleet operators.

Key facts

• Demos are conducted under best-case conditions and do not predict whether software survives a high-pressure day.
• The decisive question is what the tool requires from the user before it returns anything.
• A record that goes silently stale is worse than a manual one, because its unreliability isn't visible.
• Anyone in the building can correct a whiteboard, which is a standard most software fails.
• Week three is when abandonment typically begins, and most vendors have no process for noticing it.
• Data export terms are worth agreeing in writing before purchase rather than at the point of leaving.
• The eventual user, not the purchaser, usually decides whether a system stays in use.