All notes

CRM ≠ Excel: why implementations fail

CRM does not fail because the system is bad. It fails because it gets implemented as reporting instead of as a workplace.

Published 7 min readCRMimplementationprocess
An electrical cabinet, a row of breakers, one green indicator lit
The system comes after the agreementsillustration

The typical picture six months in: the system is bought, licences are paid, the integrator is gone, and deals still live in a file called clients_final_FINAL2.xlsx. People open the CRM on Fridays to “fill it in for the report.” Formally the system exists. In practice the company pays twice: for licences and for double data entry.

Excel is not the enemy, it is the symptom

A salesperson does not stay in Excel out of spite. They stay because the file opens instantly, asks no questions, does not demand eight mandatory fields, and lets them do in a minute what takes ten clicks in the CRM. While that is true, no policy will help: people always pick the tool that solves their own problem faster.

An implementation succeeds not when Excel is banned, but when the CRM became the faster way to work.

Three reasons implementations fail

The reasons are almost always the same, and none of them is technical.

  • Built for the manager, not for the rep. The system is designed backwards from reports: which slices the director wants to see. The rep ends up serving the report rather than the deal — and takes revenge through formal, meaningless data entry.
  • Porting the chaos as-is. If the sales process is not described, the CRM will not invent it. It will encode the disorder and make it faster, which, contrary to expectations, is not an improvement.
  • No process owner. There is a sponsor who signed the budget and a vendor who delivered the milestones, and no one inside the company accountable for the process still working six months later.

The right order of work

The order matters more than the choice of vendor. It is the same everywhere.

  1. Process. How a deal is born, who owns it, which transitions exist, where it dies. On paper, before a single setting is configured.
  2. Fields. Only the ones without which you cannot move to the next stage. Every mandatory field is a tax on every deal; the list should be painfully short.
  3. Integrations. Telephony, email, website, warehouse, accounting. One goal: remove manual re-entry, because manual re-entry is exactly what breeds the second Excel file.
  4. Reports. Last. A report is a consequence of data arriving naturally, not the reason people enter it.

What not to do

  • Don’t migrate the entire history. Moving ten years of deals is months of work and guaranteed garbage in the new system. Take active customers and open deals; archive the rest.
  • Don’t create forty mandatory fields. Every field must answer “what decision do we make based on this data.” No answer, no mandatory field.
  • Don’t launch without training on real deals. A demo on invented data teaches nothing. Week one is working in the system next to someone who already can.
  • Don’t keep Excel “for the transition period” without an end date. A transition period with no end date is simply the new permanent state.

How to audit an implementation in a week

Sit next to a rep and ask them to run one deal from call to invoice. Time it and count the clicks. Then ask them to do the same thing their own way. The gap between the two measurements is the honest score of your implementation. Everything else is opinion.

I run this loop regularly: my main product, Cehovik ERP, runs at more than 1000 manufacturing sites across Russia and the CIS, and the pattern holds everywhere — the system that sticks is the one that makes the person on the line faster than they were without it.

Facing something similar?

Tell me what your processes look like today — I’ll say whether it is worth automating and where to start.

Get in touch