RevOps audit checklist: what to check and how to prioritise fixes

Before you start: choose a useful first audit

Imagine a Monday revenue meeting. Sales has one pipeline number, finance has another, and someone is sharing a spreadsheet that was apparently the source of truth last Thursday. Everyone has done the work. They just cannot agree on what it means. That is a useful starting point for a revenue operations audit.

A CRM audit checks the configuration of a system. A RevOps audit asks whether the people, handoffs, systems and data work together across the customer journey. A perfectly configured field cannot settle a disagreement about when sales should accept a lead.

This walkthrough is designed for a first audit of a B2B revenue motion. Choose new business, expansion or renewals, then repeat the method for the others. You need an audit lead, the people who own the affected handoffs, access to relevant records and reports, and somewhere to record findings. Work through the numbered steps in order. Each ends with something concrete to produce.

The steps and worksheets are our recommended working method. Linked vendor documentation supports the specific system examples; it is not a certification of this audit. Every numerical example below is fictional, not a customer result or an industry benchmark.

1. Agree the question and the decision

“Audit RevOps” is too broad to tell anyone where to begin. Choose a symptom the team can observe, such as slow lead assignment, repeated close-date changes, or customers arriving in onboarding without an agreed scope. Ask the sponsor what they would do differently if the cause were understood.

Write a short audit brief before opening a dashboard. Include the customer segment and sales motion: enterprise new business may need different stage rules from a self-serve upgrade. Name one person who can settle disagreements about definitions and priorities.

1. Write the question in one sentence: “Why do qualified inbound enquiries reach sales without a named owner?” Add the decision: “Choose the routing rule and fallback process we need to change.”
2. Define the boundary: team, region, product, pipeline, systems, date range and timezone. Separate a snapshot of currently open deals from a cohort of leads created during a period.
3. List the exclusions and limitations, such as test records, partner-managed accounts, missing activity history or records your permissions do not expose.
4. Agree who will review the findings and what completion means: an evidenced diagnosis, an ordered backlog and acceptance checks for the proposed changes.

2. Collect the baseline and the evidence

An audit needs enough history to explain what happened. Save the current definitions and measurements before anyone starts cleaning up. A live report is useful for ongoing work, but its result can change tomorrow; retain a dated result or permitted export alongside the saved filters.

Combine a broad count with a closer look at specific journeys. Full-population checks tell you how often a condition appears. A deliberately selected sample helps explain it. A handful of unusual deals is useful investigation material, but it is not a representative estimate of the whole pipeline.

1. Collect the stage definitions, lead-routing rules, handoff agreements, key dashboards, field definitions and integration map. Mark missing documents as unknown rather than treating undocumented work as nonexistent.
2. For records in scope, retain IDs, owners, source, stage, relevant timestamps, amount and currency where needed, next action, and links to related customer records. Keep evidence in an approved shared location with the appropriate access.
3. Choose examples spanning successful handoffs, delays, wins, losses, reassignment and exceptions. Record why you selected each one. Use a separate random or stratified sample if you need an estimate of prevalence.
4. Ask each process owner to walk through a recent real record: what arrived, what they checked, what they changed, and how they knew the next person had accepted it.

3. Map each handoff and its owner

Draw the route a customer takes through the motion you chose. For new business, that could be enquiry, qualification, discovery, proposal, agreement and onboarding. For renewals, begin with the renewal trigger and follow the path through the customer conversation and commercial decision.

For recurring revenue, Winning by Design’s Bowtie model connects acquisition, retention and expansion in one customer journey. That is a useful check on the boundary of this audit: if the problem occurs after the sale, include onboarding and the customer-success handoff instead of stopping at closed won.

At each boundary, separate sending work from accepting it. Creating a task or changing a stage proves an instruction exists; it does not prove that the receiving team has taken responsibility. Interview both sides when their descriptions differ.

1. For each handoff, name the sending owner, receiving owner, trigger, required information, acceptance signal and exception route.
2. Trace your selected records across those boundaries. Compare the expected timestamps and required information with the actual history.
3. Record delays against an agreed service level. Define business hours, timezone, holidays and the event that starts the clock before calculating response time.
4. Ask what happens when an owner is absent, a territory is unclear, a lead is rejected or a customer returns. A fallback that exists only in someone’s memory belongs in the findings.

• Winning by Design: acquisition, retention and expansion in the Bowtie model ↗

4. Test qualification, stages and forecast movement

Stage names can sound precise while meaning different things to different people. Ask what evidence allows a record into a stage and what must happen before it leaves. A salesperson sending a proposal is an activity; the buyer agreeing the scope is a different event.

Keep contact or company lifecycle separate from the progress of an individual deal. HubSpot, for example, uses lifecycle stages for contacts and companies and lead status for additional sales qualification detail. Use the definitions your organisation has agreed rather than assuming a default label proves readiness.

Inspect changes as well as the current position. Salesforce’s Pipeline Inspection documentation distinguishes pipeline movement, including deals moving out of a period, and changes in forecast categories. The practical question is which records changed the number and why.

1. Write an entry rule and exit rule for each active stage. Name the evidence and the person who checks it; avoid rules such as “looks promising”.
2. Compare recent stage entries with that evidence. Include deals that moved backwards, skipped stages or remained open after a decision.
3. Compare stage age with similar deals in the same motion. Investigate outliers with owners before choosing a stale-deal threshold; do not borrow a universal number of days.
4. Track close-date, amount and forecast-category changes between two dated snapshots. If history is unavailable, state that you can assess today’s records but cannot reconstruct past movement reliably.

• HubSpot: contact and company lifecycle stages ↗
• Salesforce: pipeline changes and forecast categories ↗

5. Check the data and follow it through the systems

Start with the fields that drive a decision or an action. Owner affects routing. Close date affects period reporting. Customer and contract associations affect a renewal handoff. Missing information in these places matters more than an unused field that happens to be easy to fill.

For each important value, establish which system is authoritative and which systems can overwrite it. Then follow one real update through the chain. A clean CRM record at the moment of inspection does not tell you whether tomorrow’s import will undo the correction.

1. Define the rule and eligible population for each check: for example, open new-business deals that require a sales owner. Count affected IDs and eligible IDs separately.
2. Check missing values, invalid values, conflicting values, duplicate candidates, stale information and missing relationships. Treat “not applicable” separately from “not known”.
3. Inspect the creation source and change history of affected records. Compare import batches, forms, integrations and manual updates to find a pattern.
4. Trace an update across the CRM, connected system and relevant automation. Record matching keys, direction, failure handling and the person who owns the connection.

6. Reconcile the reports used to make decisions

Choose the reports that people actually use in the revenue meeting. Put their definitions side by side before debating the totals. Pipeline amount, weighted pipeline, contracted value and collected cash answer different questions; they should not be expected to match just because each is displayed with a currency symbol.

For an illustrative win-rate check, define the cohort as deals closed in the period, include both won and lost, and calculate won ÷ (won + lost). A cohort based on deal creation answers a different question and may contain deals that have not finished. Neither number should be silently substituted for the other.

1. Create a metric definition with the object, population, numerator, denominator if applicable, date field, timezone, currency and exclusions.
2. Compare the same set of record IDs in both reports. Look for differences caused by owner filters, permissions, associated records, dates or aggregation.
3. Recalculate a small selection from source records. For weighted pipeline, distinguish the stored stage probability from a measured historical conversion rate.
4. Agree a definition owner and record any remaining discrepancy. If the necessary historical snapshot does not exist, record the limitation and start collecting it rather than inventing a baseline.

7. Turn observations into tested findings

Suppose the fictional baseline contains 200 open new-business deals. Forty-eight have no dated next action: 48 ÷ 200 = 24%. That is a confirmed observation about the CRM. It is not yet proof that 24% of deals have been abandoned.

For illustration, you review 12 of those 48 with their owners. Seven have a follow-up recorded elsewhere, three appear to have been lost without a stage update, and two have no agreed next step. These are three different problems. Because this is an investigative sample, do not apply those proportions to the remaining 36.

1. Write the finding as a testable statement, with population, rule, count, rate, measurement date and evidence link.
2. List plausible explanations, then inspect record history and speak with the owner to distinguish them. Label each explanation confirmed, suspected or unresolved.
3. Describe the consequence you can support: unreliable follow-up visibility, blocked assignment or an inconsistent report. Do not turn deal value into “lost revenue” without evidence of the loss.
4. Record the next investigation when the cause remains unknown. Ask the process owner to challenge the finding before it becomes an implementation task.

8. Put the findings in a useful order

It is quite possible to finish an audit with 70 findings and no idea what to do on Tuesday. Sort the list by the work that is being disrupted, then consider confidence, dependencies and effort. A numerical score is optional; a defensible explanation for the order is not.

A blocked handoff with a confirmed cause may deserve immediate containment. A disputed metric may first need an agreed definition. An unused cosmetic field can wait. Keep urgent business impact separate from confidence: an important unknown calls for urgent investigation, not an untested bulk change.

1. Record the affected workflow, scale, consequence, confidence and urgency for each finding.
2. Identify dependencies before estimating effort. A field definition must be agreed before its validation and reports are rebuilt.
3. Select a first batch that has owners and can be tested together without obscuring which change caused the result.

9. Define the fix, prove it works and assign upkeep

Make each task small enough to verify. “Improve CRM hygiene” cannot be accepted or rejected. “Route records with an unknown territory to the agreed queue and notify its owner” can be tested against known inputs.

Keep the existing backlog and newly arriving records visible separately. If the rate falls because the population grew, the old records may still be wrong. Likewise, clearing one batch does not prove that the source of the problem has stopped producing new failures.

1. Write the expected behaviour, responsible owner, dependencies, test cases and recovery plan before changing configuration.
2. Test the normal path and exceptions in an appropriate test environment: missing inputs, reassignment, repeated events and downstream reporting. Record expected and actual outcomes.
3. Correct the existing records only after the matching and exception rules are agreed. Check that the repair did not overwrite legitimate values.
4. Rerun the original measurement, then monitor a defined cohort of new records. Choose review timing to match the workflow and name who responds when the check fails.
5. Close the audit with the brief, handoff map, metric definitions, findings register, ordered backlog and verification results. Ask the sponsor to approve the decisions and owners.