How to Audit Your CRM: A Step-by-Step Health Check for Sales Leaders

Most CRM problems do not announce themselves. Forecast accuracy slips by a few points, reps start keeping a private spreadsheet for the deals they care about most, and a report that used to be trusted in the Monday pipeline review quietly stops being opened. By the time someone says the CRM is broken, the underlying causes are usually a year old: fields added for a campaign that ended, an integration that stopped syncing after a field rename, permission sets copied from a team that no longer exists. A CRM audit is the structured way to find those causes before they show up in a missed quarter, and it is work a sales leader can drive without hiring a consultancy. The exercise is diagnostic rather than cosmetic, so the output is a prioritized list of defects with owners, not a tidy-up session.

The cost of skipping it is measurable. Gartner research puts the average annual loss from poor data quality at around $12.9 million per organization, covering wasted effort, bad decisions, and operational drag (Gartner research, as summarized by ZoomInfo). B2B contact data also degrades on its own, at roughly 22.5% per year as people change roles and companies (per Cleanlist’s B2B data decay analysis). A CRM that was clean at launch is not clean two years later, regardless of how disciplined the rollout was.

What a CRM Audit Reviews and How Often to Run One

A CRM audit is a systematic review of six areas: documentation, data quality, usage patterns, integrations, user feedback, and compliance. Treating them as one pass matters because the findings interlock. Low field completion usually traces back to a required field nobody agreed to, and a broken integration often explains a duplicate problem that looks like rep behavior.

Cadence should match how much the system changes. Annual audits are the practical minimum, with lighter quarterly reviews catching problems sooner, and most mid-market teams complete a full pass in three to five focused days (based on Insightly’s CRM audit guide). Beyond the calendar, four events justify an unscheduled audit:

• A major platform release or app upgrade that changed field behavior or permissions
• A new integration joining the stack, especially one that writes to contact or deal records
• A territory, quota, or org restructure that changed who owns which records
• A visible drop in forecast accuracy or a spike in rep complaints about data entry

Running the audit right after the fiscal year closes tends to work best, since the team is already reviewing performance numbers and has the context fresh. Pick the window before the new quota period starts, because reps under fresh targets will not give interview time.

Step 1: Compare CRM Documentation With the Live Configuration

Start by collecting whatever documentation exists on how the CRM was supposed to work, then compare it with what is configured today. The gap between the two is your first set of findings. Expect it to be wider than anyone on the team predicts.

Pull the original implementation notes, the field dictionary, the pipeline design, the permission model, and the integration specs. Then open the system and inventory what exists today: every pipeline, every stage, every custom field, every automation rule, and every user role. In practice this is where teams discover the drift. One mid-market sales org I worked with had documented seven deal stages and found eleven in production, three of which had been added by a regional manager to track a partner motion that ended eighteen months earlier. Two of those stages still appeared in the forecast report, so weighted pipeline numbers had been inflated for a year and a half without anyone tracing the cause. Missing documentation counts as a finding in its own right, and writing it during the audit is cheaper than reconstructing it during the next migration.

Field inventory deserves particular attention because it is where technical debt accumulates fastest. Salesforce’s own guidance separates fields that were never populated from fields that were used historically but have gone untouched for a defined window, typically the past 12 to 36 months (per Salesforce’s Trailhead metadata cleanup module). The distinction changes what you do next. A never-populated field is usually safe to retire, while an abandoned field may still hold the only record of how an old product line was sold.

If the field structure is the worst-looking part of your inventory, CRM Custom Fields: How to Design Your Data Structure for Reporting walks through rebuilding it without breaking historical reports.

Data Quality Scoring Before Any CRM Cleanup (Step 2)

Data quality work fails when it starts with cleanup instead of measurement, because nobody can tell whether the effort changed anything. Score the database first, on a sample if it is large, then decide what to fix. A random sample of 150 to 200 records, verified by hand against public sources, is enough to estimate accuracy across a database of any size.

Completeness. Define the fields that genuinely matter for each record type, then calculate the percentage of records where all of them are populated. Sales leaders usually care most about open deals: amount, close date, stage, owner, and at least one associated contact. Anything below 90% completion on those fields makes pipeline reporting unreliable.

Uniqueness. Run duplicate detection and record the duplicate rate rather than just merging what you see. A 1% duplicate rate is the commonly cited target, and roughly a fifth of organizations reach it (per Landbase’s duplicate record benchmarks). Note the source of the duplicates too, since imports, form submissions, and integration writebacks each need different prevention.

Freshness. Pull the count of contacts still flagged as active that have had no engagement in 24 months, and the count of open deals with no logged activity in the last 14 days. Fourteen days is a common definition of a stale opportunity, though stage-specific clocks work better in long cycles, with something like 21 days at discovery and 30 days at proposal. Both numbers tend to shock people the first time they are calculated.

Consistency. Check whether tags, industries, lead sources, and account types are applied the same way across teams. Free-text entry on a field that feeds a report is a defect, even when every value is technically correct. Two teams recording the same lead source as “Webinar” and “webinars 2025” will produce two rows in an attribution report and a long argument about which one is right.

Duplicate handling is worth understanding at the platform level before you start merging. HubSpot, for example, rescans records daily against a default property set and allows two custom duplicate rules per object with up to nine comparison properties each, and rejected duplicate pairs can only be restored within 14 days (per HubSpot’s duplicate management documentation). Merges themselves cannot be reverted. Knowing those constraints keeps a bulk merge from becoming its own incident.

The scoring numbers also give you a baseline to re-measure after remediation. We cover the downstream damage from bad records in detail in CRM Data Quality: How Dirty Data Kills Your Pipeline .

Step 3: Measure CRM Usage Patterns Beyond Login Counts

Login reports are the easiest adoption metric to pull and the least useful one. A rep can open the CRM every morning to check a task list, update nothing, and still appear as a daily active user. What you want to know is whether the system reflects the work the team is doing, so the metrics need to describe records rather than sessions.

Look at records created and updated per user per week, the proportion of deals where the next step and next-step date are filled, average time between a customer conversation and the corresponding activity log, and stage movement volume by rep. Compare those figures across the team. Wide variance usually means the process is ambiguous, not that half the team is lazy. Then look at feature usage: which reports get opened, which dashboards get shared, which automations fire, and which modules nobody touches. Unused features are either a training gap or a sign the feature was bought for a workflow the team abandoned.

Access review belongs in this step as well. Users who have not logged in for 90 days, seats assigned to people who changed roles, and permission sets that grant more than the current job requires are all security findings, and they are usually easy to fix during the audit rather than after it. Retention limits matter here: Salesforce keeps login history for six months, so an annual audit cannot reconstruct a full year of authentication activity from the standard object. Export the log as part of the audit if you want a longer baseline for next time. Unused seats are also the fastest cost saving the audit will produce, and finance tends to notice.

Low adoption is rarely a discipline problem on close inspection. Salesforce’s State of Sales research has consistently found reps spending under a third of their week on actual selling, with administrative work and data entry consuming the rest, and a CRM that adds friction to that ratio gets worked around. For the patterns behind resistance to a CRM rollout, see Why CRM Projects Fail: Real Reasons Behind Low User Adoption before you plan more training.

Integration Testing That Goes Past the CRM Status Page (Step 4)

How do you know an integration is working? Not from a green connection indicator, which only confirms authentication. You confirm it by pushing a record through the full path and checking what arrives on the other side.

Build a short test script and run it during the audit:

• Create a test contact and a test deal in the CRM, then verify both appear correctly in the marketing platform, the support desk, and any BI destination.
• Move the test deal to closed-won and confirm the downstream handoff fires: onboarding task created, invoice request raised, customer record flagged.
• Send a calendar invite and a tracked email, then check that both land on the right record as activities.
• Edit a field on the receiving system and confirm whether the change syncs back, if the integration is meant to be bidirectional.
• Review the integration’s error log for the last 90 days and count failures by type.

That last step catches the failures nobody noticed. Field mapping breaks silently after a rename, API rate limits delay syncs during bulk operations, and OAuth tokens expire when the person who authorized the connection leaves the company. Each of those produces partial data rather than an outage, so the CRM keeps looking healthy while the records drift apart. One team I reviewed had lost the company field on inbound leads for four months after a marketing form was rebuilt, and the only visible symptom was a rising count of contacts with no account association. Document the owner of every integration during this step, because ownerless integrations are the ones that stay broken longest. Where no owner exists, the audit finding is the ownership gap rather than the technical fault.

Teams running sales workflows inside Jira face a variation on this problem, since customer data usually lives in a separate CRM and syncs across. Jira-native options such as Mria CRM keep deal and contact records on the same platform as delivery work, removing the sync layer from the audit scope entirely.

Interviews With the People Entering CRM Data (Step 5)

Reports tell you what is in the system. They do not tell you why a rep skips a field, and that gap is where most audit findings get their explanation. Plan for interviews early, since calendars fill fast in a selling quarter.

Talk to six to eight users across roles, and watch at least two of them work. Screen sharing while someone logs a call after a real customer meeting surfaces friction that no survey captures: the required field with no sensible default, the picklist missing the option they need, the three clicks to reach the notes panel. Ask three questions in every session. What is the most annoying part of entering a new deal? What workaround have you built outside the CRM? What do you wish the system did that it does not?

Write down the workarounds verbatim. A shared spreadsheet, a WhatsApp group for deal updates, or a personal calendar used as a follow-up tracker each represents a requirement the CRM failed to meet.

Compliance Checks for CRM Retention, Consent, and Audit Trails (Step 6)

Compliance review is the part sales leaders are most tempted to delegate and least able to ignore, since the records in question are the ones their team created. The checks are concrete enough to complete in an afternoon with an admin and whoever handles privacy. Bring the findings to legal rather than asking legal to run the review.

Retention. Confirm that every category of personal data in the CRM has a defined retention period, a documented justification, and a working deletion or anonymization process. GDPR’s storage limitation principle requires the period to be tied to purpose, and the documentation is what demonstrates accountability if a regulator asks. A policy that exists in a document but is never enforced in the system counts as a finding.

Consent. Verify that lawful basis is recorded per contact, that marketing consent is stored in a field rather than inferred, and that unsubscribes propagate to every connected system.

Access to sensitive fields. Check who can see contract values, personal phone numbers, and support history. Field-level permissions drift as roles change, and admin rights tend to accumulate.

Audit trail. Confirm the platform records who changed what and when, that you can export that log, and that the retention window on the log itself covers your reporting obligations. For teams on Atlassian, Atlassian’s audit log activities reference documents which organization and product events are captured.

One practical note on data subject requests: if a contact asks for deletion, the request has to reach every system the CRM syncs to. Test that path during the audit, because a deletion that leaves copies in the marketing platform is not a deletion. Record how long the round trip takes, since response deadlines are measured in days.

Turning CRM Audit Findings Into a Fix Plan

An audit that ends in a document changes nothing. Sort the findings by impact and effort, then split them into three buckets before anyone leaves the room. The sorting conversation is where sales leadership earns its place in the process, because the trade-offs are commercial rather than technical.

Quick fixes get done during the audit week: retiring never-populated fields, correcting permission sets, disabling dead automations, merging an obvious duplicate batch. Scheduled projects need a plan, an owner, and a date, covering things like restructuring pipeline stages, rebuilding a broken integration, or a data cleanse across tens of thousands of records. Sequence those projects so structural work lands before data work, since cleaning records into a pipeline you are about to redesign wastes the effort twice. Accepted risks are findings you consciously choose not to fix, and writing down the reason prevents the same item reappearing as a surprise next year. Keep that list short, because a long accepted-risk register is usually a sign the audit found more than the team has capacity to absorb.

Assign a single owner per finding, in the CRM itself rather than in a side document, and set a verification date 60 to 90 days out. Re-run the data quality scores from Step 2 on that date. If completeness moved from 71% to 88% and the stale deal count dropped by half, the audit worked. If the numbers are flat, the fix was cosmetic and the finding is still open.

CRM Audit FAQ for Sales Leaders

The questions below come up on almost every audit, usually while someone is trying to work out how much of the quarter this will consume.

How long does a CRM audit take?

A small team on a simple configuration can finish in a day. Mid-market organizations with several integrations typically need three to five focused days, and complex multi-region setups run one to two weeks. Splitting the work helps: documentation and data quality in one session, usage and integrations in another, user interviews spread across the period.

Who should run the CRM audit?

Someone accountable for revenue outcomes should own it, usually a sales leader or RevOps lead, with the CRM administrator doing the technical extraction. External consultants are useful when the system is large enough that nobody understands the full configuration, though the findings still need an internal owner to act on them.

What should a CRM audit produce?

A scored baseline for data quality, an inventory of fields, pipelines, automations, and integrations, a list of findings with severity and owner, and a verification date. Anything less than that is a review, not an audit.

How often should data quality be re-checked between audits?

Monthly is reasonable for the two or three metrics that drive reporting, usually required field completion on open deals, duplicate rate, and count of deals with no activity in 14 days. Automating those checks into a dashboard means the next full audit starts from trend data instead of a cold sample.