Your CRM Isn’t Broken. It Was Never Designed for You.

When businesses say “CRM,” they often mean very different things. Sometimes they mean contacts. Sometimes pipeline. Sometimes quoting, invoicing, project tracking, and client communication in one place.

Once “CRM” starts meaning “the system that runs everything,” disappointment is almost guaranteed.

I’ve seen this across consulting firms, agencies, recruiters, property businesses, and service teams. The issue is rarely that the software is bad. The issue is that the business needs one system to support sales, delivery, finance, reporting, and handoffs, and most CRMs are not built for all that.

The word “CRM” is doing too much work

A normal business has at least three different layers of work:

• Outbound: campaigns, newsletters, ads, follow-up
• Inbound: email, calls, forms, messages, enquiries
• Operations: delivery, finance, approvals, reporting, fulfilment

Those are different jobs. They create different data. They need different interfaces.

A CRM can handle some of that. It usually cannot handle all of it well.

That is where teams get stuck. They buy a CRM for sales, then keep stretching it. Soon it is supposed to store client records, track delivery, manage invoicing, support handoffs, and act as the reporting source of truth. And then they post on Reddit: "Is there a CRM that can do X?"

Good software fails when the model is wrong

Off-the-shelf tools work well when your workflow matches the model they were designed for.

That is why the default advice is usually correct: rent software. Do not build unless you have to.

If your team runs a standard sales process, a standard CRM is fine. If your support team works like a support team, Zendesk is fine. If your hiring process looks like normal hiring, an ATS is fine.

The problem starts when the fit is not close enough. Not “we prefer it slightly differently.” Structurally different.

The tool assumes one pipeline. Your team has three.
The tool assumes one deal owner. Your work crosses departments.
The tool assumes a sale is the end of the process. In your business, the sale is where the hard work starts.

Once that happens, your team starts building workarounds around the product’s assumptions. Fields multiply. Automations get brittle. Reporting stops being trusted. And people go back to spreadsheets. And no one knows where things are at.

Every business system has three layers

This is what most CRM advice skips.

A real business system usually has three layers:

1. Data layer — where the records live
2. Logic layer — rules, automations, scripts, approvals
3. UI layer — forms, portals, dashboards, internal views

Most CRMs bundle all three. That is convenient when the bundle matches your process. It is scalable for the provider, and cheap for the consumer.

Once your business process gets into an unhandled nuance, the bundled approach becomes the constraint. You are no longer choosing the best tool for each job. You are choosing whatever your CRM happens to support.

That is why so many “all-in-one” setups feel heavy. They are trying to be database, workflow engine, inbox, reporting layer, and front end at the same time.

The better question is not “Which CRM?”

The better question is: what should be the system of record, and what should stay specialised?

For outbound, there are already good tools.
For inbox collaboration, there are already good tools.
For accounting, there are already good tools.
For forms, dashboards, documents, and ticketing, there are already good tools.

The real design decision is what sits in the middle.

I usually default to Airtable for that role. (I am biased here, but it is a pretty neat tool.)

Not because Airtable is “the best CRM.” It isn’t. It doesn't look anything like a CRM on first load. Airtable is useful because it can act as a flexible data layer that non-technical teams can actually work with. I can model contacts, companies, projects, properties, invoices, submissions, approvals, or anything else the business needs, then connect the right tools around that structure. And you can configure it to look almost like a CRM in a few hours.

That is a very different job from buying a CRM and hoping custom fields will save you.

“Just use a real CRM” is still valid advice sometimes

There is a fair counterargument here.

If your main problem is sales activity tracking, email history, lead stages, and rep accountability, then yes, use a dedicated CRM. Close, Pipedrive, HubSpot, and similar tools solve that faster than a custom stack. You can always sync those to a Data layer (or Airtable) to extend it to other parts of the operation.

I would not argue with that approach.

But that is not the situation many growing businesses are actually in.

They do not just need pipeline tracking. They need pipeline tracking tied to delivery, invoicing, documents, approvals, client history, and internal operations. They need one reliable picture of the business across functions.

That is where the standard CRM starts to strain.

Historical reporting on CRM outcomes has shown wide failure ranges, and recent industry surveys still point to usability, integration, and fit as recurring problems. Bain said in 2025 that 70% of companies struggle to integrate sales plays into CRM and revenue technologies. (Harvard Business Review)

That lines up with what I see on projects. The issue is usually not “nobody built CRM software well.” The issue is that the business bought one category of software to solve a broader systems problem.

Composable stacks used to be expensive

Five years ago, the answer to this problem was often custom software. That meant long timelines, bigger budgets, and more engineering overhead than many SMBs could justify.

Now the build surface is smaller.

You can use Airtable as the data layer, pair it with purpose-built tools, and connect logic through Airtable automations, Make, n8n, or light scripting. The result is not a random stack of apps. It is a system where each part has a clear job.

That does create a new responsibility: architecture.

Composable does not mean chaotic. It means you decide, deliberately, which tool owns which part of the process.

This is what “bad CRM fit” looks like in practice

A commercial real estate firm came to us after, in their words, trying “57 different demos” and finding that none of them worked. Their workflow was not a normal CRM workflow. They had properties, units, listings, deals, complex commission splits, transaction records, and accounting dependencies that did not map cleanly to a standard CRM model.

So the project was not really a CRM replacement project. It was a system design project.

Airtable became the data layer. n8n handled automation. QuickBooks stayed in place as the financial source of truth. The useful part was not “switching tools.” The useful part was getting the structure right.

The same pattern showed up with Jemini. Their recruiting process did not match what ATS products assumed. The issue was not price first. It was fit first. OpsTwo’s published case study shows ATS vendors quoting $5K–$15K per year for a workflow that still did not match how the team evaluated candidates across long cycles and multiple engagements. (Read it here)

That is the dividing line.

When the workflow fits, rent.
When the workflow does not fit, forcing it into a packaged CRM usually adds friction to the business process.

What I would change in how businesses buy CRM

I would stop asking, “Which CRM should we use?”

I would start with:

• What data has to live longer than any one tool?
• Which teams need to touch it?
• Where does work actually move after a lead becomes a client?
• Which parts should stay in specialist products?
• What needs to be visible in one place?

That is a system design exercise, not a software shopping exercise.

I wrote about the same idea in Stop Looking for a CRM: Here’s where to start. The point is not to avoid CRMs. The point is to stop treating “CRM” as a substitute for process clarity.

If your team is living across spreadsheets, a half-used CRM, inboxes, and manual handoffs, the next step is not another demo. Map the system first.

Book a Discovery session. I’ll help you map what exists, what breaks, and what should actually own the data before you spend more money forcing the wrong tool to do the wrong job.