RevOps audit checklist: what to review first, and what to do in 30 days

You inherit a CRM the way you inherit a house. The previous owner left a binder of dashboards, a tech stack diagram and a forecast that lands somewhere near the number most quarters. The temptation is to start with the binder: list the tools, interview the reps, rebuild the board deck. Most audit checklists are written that way, and it is why the same forecast argument shows up again a quarter later.

This checklist starts with the deal record and works outward, in the order that moves the forecast: stage definitions and the fields that prove them, then ownership and handoffs, stage history, metric definitions and forecast rules. Dashboards come last, because they sit on top of all of it. Each item is a pass/fail question you answer from the CRM records, not from interviews, and the last section puts the work into a four-week order. If the record is wrong, the reports built on it are wrong in the same direction, and dashboard work won’t change that.

Why audit in forecast order?

A RevOps audit should start where the forecast is built: stage definitions, required fields and ownership, then handoffs, reporting definitions and forecast rules. Clari Labs’ January 2026 research, a Censuswide survey of 400 North American enterprise revenue and IT leaders, found 55% report conflicting pipeline signals from disconnected data sources and 42% still lack formal governance frameworks for data consistency and accountability. Dashboards built on undefined stages inherit the problem.

That sample is enterprise, so read it as a direction for a smaller company, not a measure of one. The broader survey lands in the same place. Validity’s State of CRM Data Management in 2025, a survey of 602 CRM users and stakeholders, found 76% said less than half of their organization’s CRM data is accurate and complete. Across the 150+ B2B companies we’ve worked inside, roughly 7 in 10 had material CRM data accuracy problems.

The order matters because each layer inherits the one under it. A forecast category depends on a stage. A stage means something only if the CRM asks for proof when a deal enters it. A report of pipeline created this quarter depends on which date property and which stages somebody picked when they built it. Audit the top layer first and you can spend a month polishing numbers whose inputs you haven’t checked.

Answer each question below from the records themselves: pull the report, open a sample of deals, read the field history. Where the answer is no, write it down and keep going. No RevOps person to run it? Running RevOps without a RevOps team covers who can own the work.

Area 1: Stage definitions with entry and exit criteria

Each stage needs a written entry criterion a manager can check on the record, and the CRM should ask for the evidence at the moment a deal moves into the stage. A stage defined only in a training deck is an opinion. A stage that requires a field is a rule the system can hold.

The major CRMs can each hold that rule. Per HubSpot’s knowledge base, admins can set properties for each pipeline stage and mark them required, and users cannot create or update the record until they set a value. Pipedrive lets admins on Professional and higher plans make a deal field required for specific pipelines and stages, and prompts a user who moves a deal to a new stage without it. In Salesforce, validation rules verify that data entered in a record meets the standards you specify before the user can save it, and can show an error message when a value is invalid.

Check stage probability while you are in the pipeline settings. In HubSpot’s default sales pipeline, each stage has an associated probability, and HubSpot uses it to calculate the weighted amount shown in board view. If those numbers weren’t chosen on purpose, the weighted pipeline is running on somebody else’s assumptions.

Pass/fail:

• Can two reps, asked separately, give the same definition of each stage?
• Does each stage require at least one field that proves its entry criterion?
• Is there a written exit criterion for moving a deal out of each stage?
• Was stage probability set deliberately, or left at the default?

Area 2: Required fields that are filled, and filled by whom

A required field proves that something was typed. It doesn’t prove the value is right, and the requirement may not apply to each way a record gets into the CRM. Check how deals enter before you trust a requirement, because rules set in the UI may not hold for imports and integrations.

Pipedrive documents the gap plainly. Per Pipedrive’s required fields article, required fields won’t stop deals from progressing if the fields are updated via import, bulk-editing, API, automations or third-party integrations. On HubSpot or Salesforce, test your own instance instead of assuming either way: push a test record through each integration that writes deals and look at what lands.

The quality question sits underneath the enforcement question. In Validity’s 2025 survey, 76% said less than half of their organization’s CRM data is accurate and complete. A required field full of “TBD” fails the same way an empty one does. The usual answer is fewer fields, enforced, which the field bloat paper covers.

Pass/fail:

• What share of open deals created in the last 90 days came from imports, integrations or automation?
• Do those records carry the same required fields as deals reps created by hand?
• Do required fields hold real values, or placeholders like “TBD” and “n/a”?
• Can you name the owner of each integration that writes to deals?

Area 3: Who owns each record and each handoff?

Each open deal, account and active contact needs a current owner who still works at the company. Each handoff, lead to rep and rep to customer success, needs an owner, a defined set of data and a time limit. Records owned by people who left drop out of the forecast conversation, because the person who would speak for them is gone.

Handoffs drag quietly. A lead with no follow-up SLA sits until somebody notices it. A closed-won deal reaches customer success without the context the rep carried in their head. For that second handoff, the sales to customer success handoff paper lays out what the record should carry.

Pass/fail:

• How many open deals belong to inactive or deactivated users?
• Do accounts and active contacts have a current owner, too?
• Is there a written SLA for lead follow-up, and can you see breaches in a report?
• Does the closed-won to customer success handoff have a named owner and a required set of fields?

Area 4: Can you see how deals moved?

You can’t audit slippage you can’t see. Confirm the CRM records when deals enter and exit each stage, and logs changes to close date and amount. Salesloft’s 2026 U.S. Revenue Benchmark Report estimates 19.7% of pipeline is affected by stalled deals, slipped close dates and other execution breakdowns combined, and found only about 32% of leaders can instantly diagnose why a deal has stalled.

Both big platforms can record the movement. In HubSpot, the Date entered and Date exited stage properties hold the date and time a deal entered and left each stage, and HubSpot says they need a Professional or Enterprise subscription. In Salesforce, field history tracking covers up to 20 standard or custom fields on an object, logging the date and time of each change, the user who made it, and the old and new values, per Trailhead. Twenty fields go fast, so spend them on the fields the forecast depends on.

Without history, a deal that has pushed its close date again and again looks the same as one created yesterday with that date. Once you can see the movement, the stalled deals paper covers what to do with it.

Pass/fail:

• Does the CRM record stage entry and exit dates for each deal?
• Is close date in tracked history?
• Is amount?
• Can you pull a list of deals whose close date moved this quarter, with who moved it?

Area 5: One definition per reported metric

Pick the five numbers leadership reads each week and write one definition for each: which date property, which pipeline, which stages and which record types. Two reports that disagree are usually two definitions, not two errors, and you find that out only when the definitions are on paper.

The 55% in the Clari Labs survey describes conflicting pipeline signals across disconnected data sources. The same conflict shows up inside a single CRM when two people build “pipeline created this quarter” on two different date properties. Why HubSpot reports don’t match walks through the date property and data source causes.

Pass/fail:

• Do two reports of “pipeline created this quarter” return the same number?
• Is each board metric defined in writing, including its date property?
• Does each definition name the pipelines and record types it includes?
• Does the person who built each report agree with the written definition?

Area 6: What decides whether a deal is in commit?

In HubSpot, the forecast tool assigns deals to forecast categories based on deal stage, and users can also change the category on an individual deal by hand. Audit how often that override happens and whether a written rule says what earns commit. Per HubSpot’s forecast tool setup guide, the default categories include Most likely, Best case, Pipeline and Commit, and the tool needs Sales Hub or Service Hub Professional or Enterprise.

An override is a judgment call, which is fine. A judgment call with no rule behind it is a rep’s mood, logged as a forecast. If you run Salesforce or Pipedrive, ask the same questions of whatever sets forecast category in your instance. The forecast categories glossary defines the categories, and the sales forecast accuracy paper covers how to measure the result.

Pass/fail:

• Is there a written commit rule a manager can check on the record?
• How many deals in commit sit in an early stage?
• How many deals carry a forecast category that differs from the one their stage would assign?
• Does a manager review overrides before the forecast call?

What should you fix first in the next 30 days?

Work in the order the audit ran. Week 1 writes the definitions: stages, the commit rule and the five metrics. Week 2 enforces them with required stage fields, validation and history tracking on stage, close date and amount. Week 3 cleans up ownership and sets handoff SLAs. Week 4 rebuilds the five reports on the new definitions and compares the new forecast with the old one.

You set the bar for each pass condition. A small company and a large one will draw it in different places, and the point of the first month is that the line exists and somebody owns it.

Notice what week 1 leaves out: new dashboards. They come in week 4, after the definitions underneath them exist.

Audit the dashboard, or the record underneath it

You can keep auditing the dashboard. It will look a little better each quarter, and the forecast argument will keep happening in the same meeting. Or you can audit the record underneath it, accept a month of unglamorous definition work, and walk into the next forecast call knowing what commit means.

This gets harder when the CRM carries years of imports, integrations and departed owners, because the gaps sit in records people rarely open. AeolusGTM is CRM, RevOps and GTM advisory, with Atlas connecting to your CRM to find gaps the CRM can’t show natively. If you want the record-level read done for you, the free CRM Diagnostic connects read-only to HubSpot, Salesforce or Pipedrive and runs 40+ automated checks across data quality, pipeline hygiene, freshness, reachability and ICP fit.

Start this week with one question from Area 1. Pull the open deals in your main pipeline, find the two stages holding the most of them, and ask two reps, separately, what a deal has to show to enter each one. Write both answers down. Where they differ, you have your first definition to write.