Your office gets several software calls a week now. Most of them lead with the product and never quite arrive at your operation.
We sit on the other side of that table for a living, and the pattern is consistent: most bad software purchases were working software. The tool did what the demo promised. The promise just answered the vendor’s list of problems, not the buyer’s. We covered how that plays out in Modernizing Without Disruption: A Practical Guide for Operations Leaders, and the pattern starts at the pitch call.
Here are the five questions that separate the two, asked in plain language, before anything gets signed.
1. Will my team actually use it?
Not “is it user friendly.” Ask specifically: does this fit how my dispatchers, estimators, and crews already work, or does it ask them to work differently? Tools that force new workflows get worked around within a month, and a worked-around tool is a subscription, not a system. If the vendor has not asked how your team currently operates, they cannot answer this question honestly.
2. Does it replace something that works?
“All-in-one platform” usually means replacing four things, three of which were fine. Replacement carries risk your operation absorbs: migration, downtime, retraining, and the quiet loss of everything the old system knew. The better question for any tool is whether it can run alongside what you have. We made the fuller argument in Retrofitting Legacy Systems: Why It’s Smarter (and Safer) Than Starting Over, and it applies double when a seller’s revenue depends on the rip-and-replace.
3. What happens to our data?
Three parts. Can you get your data out if you leave? Does the vendor use it, train on it, or share it? And where does it physically live, in your building or on someone’s cloud? A vendor who is vague here is telling you something. Your operational history is an asset, and the answer should be as plain as any other line in the contract.
4. Who maintains it?
Every tool needs an owner after the salesperson stops calling. Ask what maintenance looks like, who does it, and what support costs after year one. Then ask the internal version: who on your team will own it? A tool that belongs to nobody becomes shelfware by spring, and the license keeps billing either way.
5. What does it fix on day one?
Not at full adoption. Not once the team is trained. Day one. A serious answer names one of your bottlenecks and a number that should move. A vague answer means the tool solves a category of problem, and your operation does not have categories. It has a dispatch board, an estimated backlog, and a Friday that disappears into reporting.
The translation rule underneath all five
Vendor language describes the product. Your questions should describe your operation. Any pitch that cannot survive the switch from “what it does” to “what it fixes here” is answering someone else’s problem, and walking away from it costs you nothing but the demo hour.
Not sure a tool you are being pitched passes the test? Bring it to a 30-minute ops walkthrough and we will give you a straight answer, even if that answer is do not buy anything: nexxtideas.com/contact
