How to Run a CRM Data Audit in One Week

What is a CRM data audit supposed to produce?

A ranked list of problems, each with a dollar figure or a named decision attached. A slide showing that 63 percent of fields are populated tells leadership nothing they can act on.

Most audits fail on output rather than analysis. The analyst pulls every field, computes completeness across all of them, and delivers a report where a blank secondary industry field sits next to a missing close date as though the two carried equal weight. The report gets thanked and shelved.

Write the deliverable first. Three columns: the problem, the decision it corrupts, and the estimated revenue exposure. If a finding cannot fill all three columns, it does not go in the report. That constraint alone cuts most of the scope and makes the remaining work finishable in a week.

What do you measure on day one?

Start with open pipeline only, and only the fields that feed a revenue decision. Historical records and dormant fields can wait, because nothing in this quarter changes based on them.

Run these checks against every open opportunity.

Two of those rows usually deliver the headline finding.

The 12-month test is the first. Across ORM's customer base, 10 percent or more of open value has gone 12 months untouched, and the share varies by company. Those deals inflate coverage without contributing to the forecast.

The deal size comparison is the second. When open pipeline averages $80,000 and closed won deals average $40,000, half the open value does not survive to close. No amount of coverage ratio arithmetic surfaces that, and it changes the forecast more than most modeling adjustments would.

How do you separate broken records from broken rules?

Look at how each failure distributes across reps. Concentration means coaching. Even spread means the system is at fault.

Take a failure category, group the failing records by owner, and sort. When three reps out of 40 hold most of the exceptions, that is a manager conversation and the records get fixed by the people who own them.

When the failures spread evenly, stop correcting records. An even distribution means every rep is responding rationally to the same bad design. Maybe the field is required at a stage where nobody can know the answer. Maybe the picklist has no value that describes reality, so people pick the nearest wrong one. Maybe the process changed and the field did not.

How do you size the impact of each finding?

Convert each problem into the revenue decision it distorts, then estimate the size of the distortion. This is the step that turns an audit into a budget request. Stale pipeline sizes easily. Sum the open value of deals with no meaningful activity in 12 months, then state the coverage ratio with and without them. A team reporting 3.5x coverage that drops to 2.9x once stale deals are excluded now has a real problem to discuss, and 3x to 5x is the standard band most teams operate in.

Close date clustering sizes through history. Take the deals that carried a last-day-of-quarter close date at the start of the prior quarter and report what share actually closed in that quarter. The realized rate is usually far below what the pipeline implied, and a plausible working figure is that only about a fifth of the value sitting in the quarter on day one closes inside it.

Amount inflation sizes directly. Multiply the gap between open and closed average deal size by the count of open deals past proposal. That is the overstatement carried in the current pipeline coverage number.

Duplicate opportunities size by summing the value of the duplicate side of each matched set. That amount is in the forecast twice.

What does the audit output actually look like?

One page of findings, one page of recommended fixes with owners, and an appendix with the record-level lists. Nobody reads the appendix, and that is fine, because its job is to make the findings checkable.

Order the findings by revenue exposure rather than by how easy they are to fix. Ease belongs in the recommendation column, not the ranking. A finding worth $2 million that takes a quarter to fix outranks a finding worth $40,000 that takes an afternoon, and leadership should make that tradeoff with both numbers visible.

Split recommendations into two buckets. Corrections, which fix existing records and have a completion date. Controls, which prevent recurrence and have an owner. An audit that produces only corrections guarantees the same audit next year.

How does bad data actually affect the forecast?

Less than most teams assume, and in a specific way. Inconsistency damages a forecast. Incompleteness mostly does not.

Every revenue team believes its data is uniquely bad and that this is why the number keeps missing. That belief is almost always wrong. Garbage in does not have to mean garbage out. As long as the garbage is consistent, the pattern is learnable and the bias is correctable.

The damage comes from definitions that move. Stage exit criteria rewritten each time a new sales leader arrives. A lead source picklist that gets restructured mid-year. An amount field that meant annual contract value last year and total contract value this year. Those changes break the comparability of history, and history is what every forecasting method depends on.

Weight your audit accordingly. Findings about consistency over time outrank findings about completeness today, which is why stage definition drift belongs at the top of the report even though it produces no obvious exception list. The connection between definition stability and forecast accuracy is tighter than the connection between field completeness and anything, and the same logic governs how to read deal slippage signals from close date history.

How often should you repeat it?

Once a year in full, with a quarterly check limited to the items the last audit flagged. Continuous auditing produces a dashboard that gets ignored by month three.

The annual pass works because it has a sponsor, a deadline, and a decision attached. The quarterly check works because it is narrow enough to finish in an afternoon and specific enough to show whether the controls held.

Track one number across cycles: the count of findings that reappear. A repeat finding means the control failed, and a control that fails twice should be replaced with a hard system constraint rather than a third attempt at the same soft approach.