The CRM nobody trusts

The symptom, precisely

Trust is gone when people run the business from somewhere else. The evidence is specific: leadership asks for a spreadsheet before the meeting, reps keep a private list of the deals that are actually live, and forecast conversations start with 'the CRM says, but…'.

Which of the four failures is yours

Definition failure

Two people place the same record in different stages. Symptoms: stage names describe sentiment; nobody can state an exit condition; conversion rates move without behaviour changing.

Adoption failure

The system asks more than it gives. Symptoms: many required fields, updates batched before the weekly meeting, activity logged retrospectively in blocks.

Hygiene failure

The data decays faster than it is maintained. Symptoms: duplicates, deals open past any plausible close date, contacts nobody has touched in a year, owners who left.

Architecture failure

The object model does not match the business. Symptoms: workarounds in note fields, one pipeline serving three unrelated processes, custom fields with overlapping meanings.

Score the four honestly with the CRM health check. Most teams have two, and fixing the wrong one first is why the second attempt is harder than the first.

Restore trust in this order

1. Freeze new complexity

   No new fields, no new pipelines, no new automation for the duration of the repair. Additions during a cleanup guarantee the cleanup never converges.

2. Rewrite stage definitions with sales in the room

   Each stage gets an entry event, an exit condition and a stall limit. Test it: three people classify the same ten records independently. If they disagree, the definition is not finished.

3. Cut required fields to what a live report consumes

   Every required field that does not feed a report you actually run is a tax that buys you a fictional value. Remove it, or make it optional and enrich it automatically.

4. Clear the dead data with a stated rule

   Publish the rule before running it — for example, deals with no activity for ninety days past their expected close move to a closed-lost state with a structured reason. Rules are auditable; judgement calls are arguments.

5. Deduplicate at the point of entry

   Cleanup without an entry-side fix means you will do it again in six months. Match on email and phone at creation, and merge with a deterministic rule for which record wins.

6. Give the rep something back

   Automatic task creation, prefilled context, one-click logging, a view that answers 'what do I do next'. Adoption follows utility, never mandates.

7. Rebuild reporting from what survived

   Four views: pipeline by stage with age, stage conversion, breach list, source to revenue. Publish them and delete the rest.

Should you migrate?

Almost never as the first move. Migration is justified when the object model genuinely cannot express the business, or licensing makes the current platform untenable. It is not justified because the current instance is messy — a migration copies the mess into a system where nobody knows the workarounds yet.

If a migration is genuinely required, do the definitions work first, on the old system. Move clean, agreed structures. Everything else is import archaeology.

How you know it worked

• The weekly pipeline review runs from the CRM with no spreadsheet on the screen.
• Two managers classify the same records identically.
• Duplicate creation is prevented at entry, not cleaned up monthly.
• Every open record has an owner who still works here.
• Reps update it during the day because the next task lives there.

Related work

Run the CRM cleanup playbook for the sequenced version. The definitions layer is covered in CRM architecture, and the cross-team version of the same disagreement is marketing and sales disagree on lead quality.