Why I refuse to build you a CRM

On many first calls, some version of this line comes up: "we tried this before and it broke."

The tool is different every time. HubSpot. Salesforce. Zoho. Airtable. A custom build from a consultancy that no longer answers email. The story is the same. Big investment, big rollout, big go-live meeting, then eighteen months of the team quietly going back to the spreadsheet.

The mistake was scope, not tools

The failed automations I have seen up close had one thing in common. Each tried to be a system. Each tried to be the one place where clients, jobs, invoices, tasks, calendar and reporting all lived, with everything linked to everything else.

Beautiful on paper. Impossible in practice. When any one of those domains changes — a new invoice tool, a new team member, a new service line — the whole system needs reshaping. Nobody has time. So the change lives in a spreadsheet, and now the system disagrees with reality.

At that moment, the team stops trusting the system. The spreadsheet wins every argument after that.

The scope-of-one rule

Here is the rule I hold on every engagement.

One workflow. One boundary. One month, typically.

I will build one workflow that solves one specific problem, bounded to a scoped timeframe. Not a system. Not a platform. Not a suite.

Examples of "one workflow":

• Job completed → invoice drafted → human approves → sent → payment tracked → reminder scheduled
• Cold email reply → labelled → routed to the right team member → auto-response if it is a known type
• Supplier confirms parts price → quotation drafted → approved → sent to client → decision tracked

Examples that are not one workflow:

• A full CRM
• A "single source of truth" for everything
• A dashboard covering revenue, cash flow, pipeline and team utilisation

If you want the big system, hire a systems integrator. That is a legitimate job, typically a five- or six-figure engagement, and it is outside what I do.

Why one workflow works when a system doesn't

It fits in your team's head. One workflow can be explained on a single sheet of paper. Systems require training programmes. Training decays.

It has an exit. If you fire me in month six, the workflow is one node in your business. Rip it out or keep it — either choice is a scoped conversation, not a rebuild.

It has an honest measure of success. One workflow either saved time or it didn't. Systems get scored on "adoption" and "utilisation" — measures that rarely correlate with the business getting easier to run.

The first month

The first workflow I build with any client is the most annoying and most self-contained one. Not the strategic one. Not the one that looks best in a pitch deck. The one that saves a real team member from an afternoon of clicking every week.

We measure the win in that team member's hours. If we cannot measure a win in the first month, you should not sign a month two.

What this article does not claim

It does not promise that "one workflow at a time" scales linearly. Some workflows depend on others. Some make no sense until a second is in place. That is a real conversation, and we have it in scoping, not on trust.

It does not promise that automation is always the right answer. Sometimes hiring one person part-time is better.

The keeper

One problem solved beats one system to maintain.

If your last automation vendor promised you a system, they were selling something. If I promise you a workflow, I am selling something too — but what I sell ends where your business begins, and that is on purpose.

Talk to me

If you have a system that broke and are unsure whether to revive it or replace it, book 30 minutes and walk me through it. I will give you a working opinion in that call.