We’ve seen beautifully configured systems, built to an exhaustive specification, quietly abandoned within six months. We’ve also seen deliberately simple setups become the single most important system in a business. The difference was never the configuration. It was whether the people expected to use it were involved in shaping it.

We’re not the only ones to notice: the research on change management and project success consistently finds that projects treating the people side seriously are several times more likely to hit their objectives. That matches what we see, and it has nothing to do with which CRM you buy.

A CRM amplifies whatever process you already have. If your handover from sales to delivery is vague, automating it just makes the vagueness arrive faster and more reliably. One mistake that appears repeatedly is buying software in the hope it will decide how the business should work.

“The CRM is a nightmare” is often shorthand for something else entirely — an approval step nobody understands, a pricing rule that changes monthly, or two teams who disagree about who owns a customer. The CRM is simply where those disagreements become visible.

Salespeople are not naturally opposed to entering data. They’re opposed to entering data that only ever travels upwards. The moment the system starts giving something back — a reminder that saved a deal, a quote produced in two minutes instead of twenty — the resistance tends to disappear on its own.

Most training happens before anyone has any real questions. Two weeks later, when people have actually tried to do their job in the system, is when the useful questions arrive — and by then the training session is long over. The most successful customers tend to book a second session deliberately, a month after go-live.

Customers rarely complain that they don’t have enough fields. We have had plenty complain that they had too many. Each one costs something: a moment of data entry, a line of training, a bit of screen clutter, and a column of empty cells in a report that somebody then has to explain.

Reporting is the most requested improvement we hear, and the vast majority of reporting problems trace straight back to inconsistent or incomplete data. You cannot report your way out of a free-text field that eleven people have filled in eleven different ways.

When you find a user running a parallel spreadsheet, the instinct is to ban it. We’d suggest the opposite. That spreadsheet is a very precise specification of something the system doesn’t do yet, maintained voluntarily by the person who needs it most.

We once looked at a sheet one team had kept going for two years alongside the CRM. It turned out to be doing one thing the system wasn’t: flagging which customers hadn’t been contacted in ninety days. That took an afternoon to build properly, and the spreadsheet disappeared on its own.

Not because moving data is hard, but because looking at twenty years of it honestly is. Duplicates, dead contacts, three spellings of the same company name, opportunities that were closed in someone’s head but never in the system. Migration is where a business finds out what it actually knows about its customers.

One customer discovered four separate records for their single largest account, each with different contact details, and each maintained by a different department. Another found open opportunities dating back more than six years — still sitting in the forecast. It’s also the point at which data accuracy requirements under UK GDPR stop being theoretical — four conflicting versions of one customer is a compliance question as well as a reporting one.

If two people run the same report and get different numbers, the number stops being a fact and becomes an opinion. We’ve watched that single experience undo months of good work, because from then on every figure gets checked against a spreadsheet anyway.

The version of the system people imagine is rarely the version they actually need. That isn’t a failure of planning — it’s simply what happens when a specification meets a Tuesday morning. We’ve learned to expect the first round of feedback to be substantial, and to leave room for it.

Projects rarely stall because something was technically difficult. They stall because everyone is waiting for the perfect process to be agreed. Meanwhile the business carries on using the old system, enthusiasm quietly drains away, and the people who were excited in January have stopped asking by June.

Not a committee. One person with enough authority to settle a disagreement between two departments and enough involvement to care how it turns out. The projects that drift are almost always the ones where every decision needs to be taken away and discussed.

A phased go-live feels slower and almost always isn’t. One team, one process, one clear win — then extend. It gives you a group of people inside the business who can say “this works” far more convincingly than any supplier can.

We’ll say it plainly: businesses almost always overcomplicate their first CRM design. We’ve received requirement documents running to hundreds of lines where the genuinely critical items were five or six. The rest were preferences, habits inherited from the previous system, and things somebody remembered seeing in a demo three years ago.

It isn’t carelessness — a long list feels like diligence. But every item on it buys complexity that someone has to configure, learn, maintain and eventually justify. The most successful implementations we’ve run were the ones where we were allowed to say “let’s not build that yet”.

The customers getting the most out of their system are often the ones still making improvements five, ten, fifteen years in. Not because the original build was wrong, but because their business changed — new services, new team structures, new reporting needs — and the system changed with it.

This one might be a little controversial. AI has genuine uses and we’re building with it where it earns its place. But in the conversations we’re having today, most customers still care far more about visibility, reporting, automation and adoption than about the newest AI feature. Those fundamentals are unglamorous and they’re where the return actually shows up.

That may well change, and we’d expect it to. It simply hasn’t changed yet as fast as the industry’s marketing suggests.

A meaningful proportion of what’s in OpenCRM today exists because a customer described a problem we hadn’t considered. Those requests are grounded in a real working day, which makes them far better guides than any internal brainstorm. We wrote about where new features come from separately, because it genuinely shapes how we build.

Businesses often start looking for a new system when what’s really happened is that the questions they ask have moved on. The data is usually there. The views, dashboards and reports built three years ago for a different business simply haven’t kept up.

Over that kind of timescale you’ll speak to your CRM supplier about things no feature comparison covers. We’ve been alongside our customers through the financial crash, Brexit and a pandemic — three events that changed how businesses sold, who they sold to and, in some cases, what they sold entirely. None of that was in anybody’s original specification.

Reorganisations, acquisitions, difficult migrations, regulations nobody saw coming: the system has to bend for all of it. We’ve found that the customers happiest with their choice picked the people alongside the product.