CRM Audit Checklist: 50 Checks Across Data, Process and Reporting

A CRM audit is not a cleanup exercise. It is how you find out whether your CRM can be trusted before changing automation, reporting, integrations or sales processes.

When a HubSpot portal feels messy, the problem is rarely one thing. It is usually a combination of weak data standards, unclear lifecycle rules, old workflows, duplicate properties, reporting shortcuts, and permissions that grew organically over time.

This is the checklist I would use before optimizing a CRM, migrating data or asking leadership to trust pipeline and marketing numbers.

1. Data model and hygiene

Start with the data. If the CRM cannot describe customers cleanly, every dashboard, workflow and handoff becomes less reliable.

1. Contacts and companies are deduplicated with a clear matching rule.
2. Company domains, names, countries, industries, and employee ranges are consistently populated.
3. Lifecycle stage is defined, enforced, and not manually overwritten without reason.
4. Required fields are actually required at the right moment, not only documented in a spreadsheet.
5. Custom properties have clear names, descriptions, owners, and usage notes.
6. Unused properties are archived or clearly marked as deprecated.
7. Contact, company, deal, ticket, and custom object associations are reliable enough for reporting.
8. Import processes prevent bad data instead of creating recurring cleanup work.
9. Email validity, bounced contacts, unsubscribes, and consent fields are monitored.
10. Data enrichment is mapped to source fields so teams know what came from forms, users, integrations, or enrichment tools.

2. Lifecycle, pipeline, and handoffs

This is where marketing and sales alignment either becomes operational or stays theoretical.

11. Lifecycle stage definitions are written in business language and understood by marketing, sales, and customer success.
12. MQL, SQL, opportunity, customer, and evangelist stages have objective entry criteria.
13. Lead status is not being used as a second, conflicting lifecycle system.
14. Deal stages match how sales actually works, not how the CRM was configured years ago.
15. Every deal stage has a clear exit requirement.
16. Ownership rules are documented for contacts, companies, deals, tickets, and accounts.
17. Handoff rules between marketing, sales, SDRs, account executives, and customer success are visible inside the CRM.
18. Stale leads, stalled deals, recycled leads, and disqualified records have a defined path.

3. Workflow and automation risk

Automation should scale a process that already works. It should not hide a process nobody owns.

19. Active workflows have owners, descriptions, and last-reviewed dates.
20. Critical workflows are grouped by business purpose: routing, nurture, lifecycle, sales ops, support, internal ops.
21. Workflow enrollment criteria are specific enough to avoid accidental enrollment.
22. Suppression lists and exclusion rules are documented for email and lifecycle automations.
23. Workflows that update lifecycle stages, owners, lead status, deal stages, or attribution fields are reviewed carefully.
24. Workflow conflicts are checked, especially when multiple automations update the same property.
25. Manual overrides are possible where the business needs exceptions.
26. There is a rollback plan for automations that create bad tasks, emails, records, or property updates.

4. Reporting and attribution trust

The dashboard is not the source of truth. The data underneath it is.

27. Leadership dashboards are tied to documented business questions.
28. Revenue, pipeline, MQL, SQL, conversion, source, and campaign reports all use agreed definitions.
29. Attribution fields are populated consistently and not overwritten by later imports.
30. Closed-won and closed-lost reasons are structured enough to be useful.
31. Forecast, pipeline, and stage-conversion reports exclude test data and obvious junk records.
32. Marketing reports can connect campaigns to contacts, companies, deals, and revenue where relevant.
33. Every critical dashboard has an owner who understands the fields and filters behind it.

5. Governance, permissions, and accountability

If everyone can change everything, the CRM will eventually reflect nobody's process.

34. Admin rights are limited to people who need them.
35. Property creation, workflow creation, list creation, and pipeline edits follow a review process.
36. Teams know who owns data quality, automation, reporting, integrations, and permissions.
37. Naming conventions exist for properties, lists, workflows, campaigns, reports, and dashboards.
38. Archived assets are cleaned regularly so old logic does not confuse current users.
39. GDPR, consent, subscription, and deletion processes are documented and tested.
40. Change management is visible: major CRM edits are logged, announced, and reviewed after launch.

6. Integrations and migration readiness

Most CRM problems get worse when another system starts syncing into them.

41. Every integration has a documented purpose, owner, data direction, and sync frequency.
42. Field mappings are documented for key tools such as forms, enrichment, support, billing, ads, data warehouse, and sales engagement.
43. Sync errors are monitored instead of discovered during reporting reviews.
44. Migration imports are tested on samples before full import.
45. There is a clear source of truth when two systems disagree.

7. Customer handoffs and ongoing ownership

Follow the customer beyond a won deal. The next team needs the agreed scope, responsible people and relevant commitments.

46. Closed-won deals trigger a defined sales-to-onboarding handoff with a receiving owner.
47. Product, contract and service commitments are available to the teams who must deliver them.
48. Onboarding exceptions have an owner, escalation route and next review time.
49. Renewal or repeat-purchase responsibilities are defined where relevant to the business model.
50. Customer changes are reflected in the appropriate records without overwriting reporting history.

Turn the findings into a change plan

Separate urgent operating failures from structural improvements and routine maintenance. Assess the affected population and dependencies, then agree an owner and acceptance check for each change.

For example, missed lead assignment may require an immediate fallback while the broader territory model is redesigned. Removing unused properties can wait until the dependency review confirms that it is safe.