Why CRM Projects Fail to Deliver the Expected Value

A salesperson is preparing to speak again with a customer they last spoke to three weeks ago. Before the meeting they open the CRM and read the note they wrote themselves:

"Spoke to them. Following up."

The note tells them nothing. They can't remember what the customer objected to, who makes the decision, or what date was agreed for coming back — and none of it is recorded. They walk into the meeting trying to reconstruct a conversation from three weeks ago.

This is usually where a CRM's failure to deliver becomes visible. The system hasn't gone unused; the fields were filled in. What was filled in simply isn't a record that does any work.

Who is the record kept for?

Every piece of data entered into a CRM has a direction, and that direction determines its quality far more than the tool does.

A record kept upward goes into management's report. The salesperson fills it in at the end of the week, retrospectively, in whatever form looks acceptable on the reporting screen. The purpose isn't to preserve information but to close the field. What results is short, generic and unverifiable — because nobody is going to read it in order to do a job.

A record kept forward goes to the salesperson's own future. It is a message left for whoever will speak to this customer in three weeks. That note gets written immediately after the call, it is specific, and it is honest — because its reader is known, and getting it wrong costs the person who wrote it.

The tool is the same in both. The field is the same. The only difference is who the data serves.

Which is why the diagnosis "the team isn't using the system" is almost always wrong. The team uses the system; they simply give it nothing because it gives them nothing.

Measuring changes what is measured

CRMs are usually bought on a promise of visibility: which opportunity is at which stage, how accurate the forecast is, who generated how much activity.

That promise creates its own problem. The moment a field becomes a performance indicator, its contents stop describing reality and start looking good. Stages advance early, dead opportunities stay open, activity counts get padded when they need to be. None of this is bad faith; it is the ordinary consequence of measuring something.

Management then looks at a picture shaped by its own measurement and assumes it is the truth. The system is technically full and practically undecidable.

The most expensive consequence is forecasting. When stages reflect expectation rather than reality, the quarter-end forecast skews high consistently, and before long management starts correcting it by instinct. At that point the system has stopped being a source used for decisions — still being filled in, but no longer looked at when anything is decided.

The remedy isn't to stop measuring but to make the measurement a by-product of the record. If the salesperson keeps notes for their own work, the stage advances correctly anyway, and the report is derived from that record. In systems built the other way round — the report defined first, fields opened to match — the record always serves the report, and empties out.

The moment of entry matters more than the volume

Data-entry debates are usually held in terms of quantity: there are too many fields, let's cut some. Reducing fields helps, but the deciding factor is timing.

A note written straight after a conversation is a record. A note written at the end of the week is a reconstruction: the person tries to recall what happened and covers whatever they can't recall with a generic phrase. The difference between them isn't a minute of workload — it is whether the data is true.

So the highest-return intervention in most CRM projects is this: move entry to the moment and place the work happens. A note that can be completed in thirty seconds on a phone produces better data than a complete form that takes five minutes at a desk — because the first one gets written and the second gets postponed.

A system that gives nothing back empties out

Living CRMs have one trait in common: they give their user something back.

Giving back isn't an elaborate feature. Opening it before a call and seeing a summary of the last conversation, the question left open, and the promise that was made is enough. At that moment the system stops being a form and becomes a memory — and people write willingly into a memory.

It comes down to a few concrete behaviours: opportunities that have seen no movement surfacing on their own, a promise being raised when its date arrives, scattered information about a customer collected onto one screen. What these share is that they take over work the salesperson had to do anyway. Once a system does that, data entry stops being a request; the user fills the field of their own accord so that their own reminder works.

Where it gives nothing back, a quiet drift starts. The salesperson runs their own follow-up in their own spreadsheet and enters things into the CRM only when asked. This is exactly how the shadow spreadsheets described in the transformation piece come into being: not user resistance, but feedback that the system cannot carry the real shape of the work.

The manager sets the system's real standing

A CRM's place inside an organisation is settled not by training or an announcement but by what the manager does daily.

A manager who asks "where are we with this customer?" in the weekly meeting has, without meaning to, declared the system optional. If the information can be had verbally, entering it becomes a courtesy rather than a requirement. A manager who looks it up before the meeting and opens the conversation from there proves the record's value in a single move.

The same mechanism runs on the reporting side. If management collects figures from salespeople at period end and consolidates them by hand, the system isn't the official record — it is an intermediate store. Expecting the team to take the data seriously in that situation isn't realistic.

The real issue here isn't authority or discipline. What determines whether a system gets used is whether it is possible not to look at it. Every flow that can be run without opening the system empties it a little further.

Changing the tool usually just moves the problem

When a CRM isn't delivering, the most common decision is to replace it. The second system is generally more capable than the first, and eighteen months later it arrives at the same place.

That happens because the problem was never in the tool layer. The direction of the record hasn't changed, the moment of entry hasn't changed, and the system still gives nothing back. A new tool resolves none of these by itself; it continues the same habits behind a more modern interface.

The off-the-shelf versus custom decision applies here too: a packaged CRM carries assumptions about how a sales process runs, and where the company's process sits far from them, the gap is paid daily in data entry. A tool decision made without measuring that gap sets the next two years.

In closing

CRM projects are usually treated as a software problem when they are mostly a problem of direction. Kept upward, the record fills and then empties; kept forward, it becomes part of the work and the reports come out right on their own.

So rescuing a CRM rarely calls for a new module or a new tool. It calls for changing the answer to one question: who is keeping this record, and who for?

In our enterprise software and automation work, a CRM assessment starts not with the list of fields but with what a salesperson sees on screen before a call.