Chapters · 11 of 11
- 01 · What Makes CRM Data Trustworthy?
- 02 · Run a Baseline Data Audit
- 03 · Find and Prevent Duplicates
- 04 · Standardize and Validate Records
- 05 · Handle Consent, Opt-Outs, and DNC
- 06 · Handle Job Changes, Departures, and Churn
- 07 · Enrich the Records That Matter
- 08 · Resolve Conflicting Values
- 09 · Choose What to Buy, Configure, Connect, or Build
- 10 · Establish Continuous Checks and Quarterly Audits
- 11 · Capstone: Repair a Broken CRM Population
14 min · Interactive exercise
Capstone: Repair a Broken CRM Population
Review eleven combined example cases, check the saved plan’s readiness, and approve it against its current version.
Each policy in this guide was written against one situation at a time: an ambiguous duplicate pair, a customer contact who opted out of marketing, a champion who changed jobs mid-evaluation. Before anyone approves a plan made of those policies, it has to be read as a whole.
Eleven example cases, reviewed together
In this review, the eleven situations from earlier chapters sit in one population: the duplicate pair, the inconsistent field batch, Priya Shah's marketing opt-out, Leah Fenwick's sales DNC request, Derek Chen's employer change, Kessler Metal Works' stale status, Sam Okafor's re-engagement, the provider-conflict pair, the enrichment-ineligible cohort, the unsafe proposed merge, and the failed partial scan. Their outcomes are prepared by the guide. Reviewing them shows what the plan is meant to deliver and which saved sections each case depends on. It does not run your policies against those records.
Readiness is a check of the saved plan
Eleven readiness checks read the plan saved in your browser: whether each section exists and states what its chapter decided. A plan that passes is complete and internally consistent. That is a narrower claim than a real CRM, or several policies running at once, having been tested. For example, would the protected-record hold still apply if the same record were also waiting in the conflict-review queue? Answering that takes a test against a realistic population in your own systems, which this guide does not simulate.
Approval describes one version
Approval records an accountable owner, an effective date, and a review date against the plan exactly as it is saved. If a policy changes afterwards, the approval no longer describes the plan and has to be given again. Having completed this chapter stays recorded either way.
Carry this into your business
A policy that passes its own test case is a start, not a finished program. Read your data-quality rules together, confirm each one says what you decided, and then test them against a realistic population before you rely on them.