I'm Building a CRM...Again.

I'm building a CRM...

Not because the world needs another one. And not because I think I can compete with Salesforce or HubSpot or the next AI-powered platform promising to revolutionise your pipeline. I'm building one because I run a small consultancy and I need something that actually works the way I work. Something I'll reach for on a bad day, not just demo on a good one.

That probably sounds like an odd project for someone who's spent thirty years leading IT transformation programmes. I've rolled out ERPs across manufacturing sites, consolidated 56 locations into shared services, rebuilt datacentres under nine-month deadlines, and been brought in to assess whether a €29m infrastructure programme could be rescued, restructured, or whether it was better to close it down entirely. I should know better than to build my own.

Or should I?

When I started sketching out what I actually needed — not features, not integrations, just the basics of managing contacts, tracking conversations, and knowing who to follow up with — I realised I'd done this before. Exactly this. Thirty years ago.

Then

Mid-1990s. I was a business trainee at a manufacturing company in the South West. Not IT. Not even close. My days were spent rotating through internal sales, external sales, QC, warehousing, accounts and production planning. I was learning the business from the shop floor up, not from behind a screen.

The office had McDonnell Douglas green-screen dumb terminals wired into an HP 9000, a bank of dot-matrix printers screaming out green-bar paper in their own room, and smoke hanging in the air — years before workplace smoking bans made it somebody else's problem.

External sales ran off paper lists. Actual paper. Bought from trade magazines, sometimes arriving on a floppy disk if you were lucky and someone in the office knew what to do with it. Every desk had a Rolodex stuffed with business cards in various states of decay. Numbers were wrong. Names were out of date. Follow-ups were forgotten the moment the phone went down. And if you wanted to reach someone, you picked up the phone, sent a fax, wrote a letter, or got in the car. There was no internet. No email. No LinkedIn.

I wasn't "in IT", but I was frustrated by bad process. So I did what — in hindsight — I've done my whole career. I built something.

Two beige PCs networked together. One acting as a "server", the other connecting over a simple LAN. It stored company and contact details, a notes field, a couple of categories, and a next-contact date. That was it.

No dashboards. No AI. No pipeline tracking. No customer journeys. No workflows. The term CRM barely existed as a recognised business function — nobody was calling it that yet. It was just enough structure for people on the phones to work through a list, remember who they'd spoken to, and know who to call next.

In fact, we didn't even have a telesales operation at that point. The system I built helped create one. It was crude, but it was ours. And it worked — not because it was clever, but because I'd sat in the sales office, done the job, heard the calls, felt the pressure when a big customer was annoyed, and built something that fitted the work people were actually doing.

Now

Fast-forward thirty years.

CRM has had its own transformation. Cloud platforms you can log into from anywhere. Integrated telephony, marketing automation, ticketing, BI and workflow engines. AI that promises to write your emails, update your notes, and forecast your quarter before you've finished your coffee.

And yet.

When I sit with sales teams, account managers and service desks in 2026, I hear versions of the same things I heard in that 90s office:

The technology is unrecognisable. The problems haven't moved.

Back then, the data was dirty because someone bought a paper list from a trade magazine and it was already six months old before it hit a desk. Different lists from different sources, different formats, no clear lineage back to where the data came from or when it was last checked. Now the data's dirty because there are 47 integrations, three different systems of record, and nobody owns the clean-up. Different cause. Same result. Nobody trusts the data.

Back then, there was no email, no messaging, no social media. Just a phone, a fax, a letter, and a car. The limitation was reach. Now there's email, LinkedIn, Teams, WhatsApp, video calls, and whatever else has launched this week. The limitation isn't reach — it's noise. There are so many channels that the basics of "who is this person and when did I last speak to them" get buried under features nobody asked for.

And back then, humans were the only option. Every call was made by a person, every note was written by a person, every follow-up was remembered — or forgotten — by a person. Now we're racing to automate everything and remove the human from the loop entirely, and then wondering why the CRM is full of data but empty of meaning.

So What

Here's the thing I keep coming back to. That first system I built worked for one reason: I was sat in the work.

Not designing from a boardroom. Not comparing vendor feature matrices. Not optimising for reporting or governance or integration architecture. I was sitting next to the people doing the job, hearing what they hated, watching what they ignored, and building something that fitted the actual work under actual pressure.

In thirty years of watching systems succeed and fail — not just CRMs, but ERPs, data platforms, infrastructure programmes, and many more — the common thread in failure is almost never the technology. Often, it's disconnection. The person making the decision is too far from the person doing the work. What's needed and why it's needed gets lost somewhere between the steering committee and the desk where the phone is ringing.

Sitting in the work doesn't mean hovering over someone's shoulder for an afternoon. It means asking the questions nobody in the steering committee wants asked. It means examining the evidence that doesn't fit the preferred narrative — the workaround spreadsheet, the process people actually follow instead of the one that's documented, the report nobody trusts but everybody runs. And it means challenging assumptions before they become expensive, not after.

So before you build, buy, or sign off on anything, there are three questions worth asking: What is the problem you're actually trying to solve? Who are the people who'll use it day to day? And will it make them more effective, or just more managed?