A step-by-step check when CRM is not working
Work from the most reproducible failure towards process definition and information gaps. Each check states which evidence is needed and who can resolve the problem. For a symptom-by-symptom reference, use the CRM problem map.
Five operational checks before changing CRM
The point is to stop as soon as you find the layer where reality and the system first diverge.
Is something technically failing?
Can you describe the expected behaviour and reproduce the wrong result?
Start with configuration, permissions, integration, automation, duplicates or usability.
Can the business define the correct state?
Would different people agree when a lead is qualified, a deal is won, a customer is active or a risk exists?
Fix the definition before asking the CRM to enforce it.
Is the information captured when it becomes true?
Or is the CRM updated later from email, notes, memory or another list?
You probably have a workflow or capture problem.
Does the information survive the handover?
Can the next team see commitments, exceptions, requirements and ownership without reconstructing the deal?
You have a handover or system-boundary problem.
Can management answer the commercial question?
Can one customer be traced across what was expected, sold, delivered, invoiced, cost and what may happen next?
The CRM may be fine locally. The missing layer is management visibility.
If the business rule is clear and the CRM still does the wrong thing, fix the CRM.
A failed integration, incorrect permission, broken automation, duplicate creation rule, import problem or unusable interface is not a philosophical issue. It is a system problem.
Write the expected result, reproduce the failure and give that evidence to the CRM administrator, vendor or implementation partner.
If different teams use different definitions, a field cannot settle the disagreement.
A field can be mandatory and still be ambiguous. A stage can be used consistently by one salesperson and differently by another. A dashboard then turns that disagreement into a precise-looking number.
Choose one disputed state. Define the observable rule for when it becomes true, then test the same examples with several people.
If the important event happens outside the CRM, late data entry is the symptom.
People may make the decision in a call, quote, project system, inbox or spreadsheet and update CRM later because the system is not part of the natural action.
That is also how trust in the CRM can start to collapse. If the record is updated after the real action, reports lag behind operations. People then verify the position in calls, spreadsheets or inboxes before trusting the CRM. Those side checks become the working version of reality, so the CRM is updated even later.
Another cleanup, mandatory field or training session may make the record look tidier without breaking that loop. Trace the information from the moment it becomes true. The useful design question is where it should be captured once, and who needs it next.
A complete sales record can still be an incomplete delivery record.
The receiving team may need commitments, exceptions, dependencies and scope information that were never part of the sales record because Sales did not need them in that form.
If the next function has to ask for the story again, inspect the interface between teams before adding more generic CRM fields.
Cross-system reporting requires agreed identifiers and definitions
Sales, Delivery and Finance may correctly live in different systems. The failure appears when customer identity, events and definitions do not join cleanly enough to answer a commercial question.
The resulting Management View can sit across systems. It does not require CRM to become the master of every operational object.
Determine whether a configuration fix or process decision is required
Business events missing from CRM
Recurring errors may be problems with definitions, ownership or the workflow itself.