A new tool is the most satisfying answer to a hard problem. It feels decisive. It has a launch date. It has a price. It is rarely the right answer.
We've watched dozens of small businesses spend serious money on a CRM, a project tool, an automation platform — only to find that the thing they actually needed was a clearer process, a shared definition of a "client", or a single afternoon spent agreeing what the word "done" means.
The four questions, in order
Before any tool gets shortlisted, we ask:
- What outcome are we trying to change? Not "we need a CRM" — what specifically would be different in 90 days?
- What's actually blocking that outcome today? If you can't name the constraint in one sentence, you don't know it well enough to buy software for it.
- What would have to be true for any tool to fix this? Usually some process clarity. Sometimes a hiring decision. Occasionally permission to say no to a category of work.
- Of the things in (3), which can a tool actually do? This is usually a much smaller list than people expect.
“The right tool, bought to solve the wrong problem, behaves exactly like the wrong tool.”
A worked example
A clinic came to us last year convinced they needed a new practice management system. The current one was slow, the interface was dated, and the team was vocal about it. Classic signs of needing to replace.
We ran the questions. Outcome in 90 days: fewer billing errors and faster patient communications. Constraint today: three people own the patient inbox and they each handle it differently. What would have to be true: one agreed process, one set of templates, one person owning the queue. Could the existing tool support that? It could.
The fix was a half-day workshop and four shared email templates. The new system the practice was about to spend £18k on would have done none of that — and would have brought its own learning curve, integration cost, and disruption.
When the answer really is a new tool
Sometimes it is. The signal we trust most: you've already solved the process and people side, and the tool is actively blocking the work — not just annoying, but preventing something specific you can name. That's the moment to swap. Before that, the tool is a symptom, not a cause.
fact_check The 30-minute test
Before you pay a vendor, write the four answers down. If you can't do (1) and (2) cleanly in 30 minutes, the stack decision is premature. Spend that time on the process first; the tool decision will get easier (and often cheaper) when you come back to it.
If you'd like a second pair of eyes on a decision you're about to make, our systems consulting engagements often start exactly here — usually with a single call where we run the four questions together. Book one.