What a CRM audit should actually review

1. Record structure. Which objects or modules exist, what each is for, and whether two of them hold the same information. Duplicated structure is usually visible from the names alone.
2. Pipelines and stages. How many pipelines exist, what each stage means, and whether a stage change reflects something the buyer did or something your team did.
3. Ownership and sharing. Who owns a record, who can see it, and whether that matches how the team actually works. Sharing that is wider than intended and sharing that blocks someone from doing their job are both findings.
4. Required fields and validation. What the system insists on, whether those fields are the ones that matter, and where mandatory fields are being satisfied with placeholder values.
5. Data quality. Duplicates, stale records, picklist sprawl, and fields that are consistently empty. Volume matters less than whether the field is trusted.
6. Reports and dashboards. What is actually opened, by whom, and whether two reports describing the same thing agree. Definitions belong with this finding.
7. Automation. An inventory of rules: what fires, on what condition, and what it changes. Rules nobody can explain are findings in their own right.

1. Start from the questions the team asks, not from the configuration screen. The gap between them is the audit.
2. Work through the seven areas in order, recording the setting behind each finding as you go.
3. Where a finding rests on a sample, say so, and note the sample size rather than implying it covers everything.
4. Rank each finding by effect and by effort, then state which findings are not worth acting on.
5. Hand over the written findings, and let the decisions about change sit with the business rather than the audit.

"Stages are inconsistent" is an observation. "Stage 3 accepts a deal with no contact role recorded, so a deal can reach proposal without a named buyer" is a finding: it names the setting, the condition, and the effect. The second can be changed or accepted deliberately. The first can only be discussed again next quarter.

The same discipline applies to what the audit does not cover. Where adoption, process definition, or data entry discipline sits outside the scope, saying so prevents the audit being read as a verdict on the whole system.

The example below is hypothetical and describes a pattern rather than a client account.

The audit is the first of the four CRM consulting scopes, and it sits inside the Operations & Systems capability. Where the findings point at adoption rather than configuration, the training and adoption scope carries that work.