RevOps data quality: fix the handoffs before you fix the dashboard.

The dashboard is usually where the problem becomes visible

Sales has one pipeline figure. Finance has another. Marketing reports more qualified leads than the sales team remembers receiving. It is tempting to call this a dashboard problem because the disagreement appears on a dashboard. But a chart cannot resolve a disagreement about what an account, a qualified lead, or a new opportunity actually means. Rebuilding the chart without resolving those definitions gives the disagreement a better-looking home. The numbers may reconcile temporarily, then diverge again as soon as the next edge case arrives.

A dashboard is a rendering of upstream decisions. It inherits how an account is defined, how a contact becomes associated with an opportunity, how ownership changes between SDR and account executive, and how old information is treated. If those decisions are inconsistent, no amount of reporting polish produces a number that survives a second look. You can rebuild the model and still find that the apparent win rate moved because the definition of an eligible opportunity changed underneath it. That is a change in measurement, not necessarily a change in selling.

My argument is specific: the handoffs between systems and teams deserve more attention than the charts built on top of them. A handoff is any moment a record crosses an ownership or interpretation boundary. Marketing passes a contact to an SDR. An SDR passes an opportunity to an account executive. A product signup is associated with an account. A billing record is matched to a commercial agreement. Each crossing needs an explicit rule. Fix those rules, and reporting becomes a query against decisions the business already understands.

Account, contact, and opportunity are different promises

An account represents a business entity or a defined buying unit. A contact represents a person and their relationship to that entity. An opportunity represents a bounded pursuit of revenue with a scope, stage, owner, and eventual outcome. Those distinctions sound elementary, but they are easy to blur when a team is moving quickly. The trouble is not that everyone lacks the vocabulary. It is that different teams use the same vocabulary while recording different things.

Imagine a rep creating a new opportunity for every renewal discussion, upsell suggestion, and re-engagement attempt against the same company. The opportunity count starts measuring how often the rep initiated a conversation, not how many distinct commercial decisions exist. Pipeline value and conversion rates then mix overlapping pursuits. The repair is not automatically to ban renewal opportunities. Renewals may absolutely deserve their own records. The repair is to classify each motion, define when a separate opportunity is justified, and prevent the same commercial scope from being counted twice.

The contact layer needs equally careful treatment. If a champion leaves a customer and a new buyer arrives, renaming the old contact record transfers historical activity to the wrong person. Create or match the new person, preserve the former contact's identity, and record the changed relationship. Likewise, a person changing employers should not silently carry an old company's account history into a new company. You need written rules for these transitions, not a hope that every user will interpret an ambiguous form the same way.

Decide what one row means before counting rows

Grain is the level of detail represented by one row. A row might mean one company, one person, one form submission, one stage-change event, or one account-month. Many reporting disputes are grain disputes in disguise. Marketing may report qualified leads at the form-submission level while sales counts unique people who reached a qualifying conversation. Those are both potentially useful observations. They are not interchangeable populations, and dividing one population's outcomes by another population's size produces a rate whose meaning nobody can defend.

Consider a fictional prospect who starts a trial, books a demo, and submits a pricing question a week later. At the interaction level, there are three events. At the person level, there may be one contact. At the account level, there may be one company with several additional users. Nothing is wrong with keeping all three events. Something goes wrong when the report labels three interactions as three unique leads, then compares that figure with a sales report that recognizes one account. The discrepancy is not fixed by changing the lead-scoring threshold.

Put the grain next to the metric definition. For example, a team might define qualified accounts as distinct account identifiers that met an agreed qualification rule for the first time within a reporting period. That is an illustrative definition, not a universal standard. Another company may need requalification windows or separate product motions. The important part is stating the choice. Also state whether the report is a cohort view or a snapshot. A monthly intake cohort followed over time answers a different question from today's open pipeline.

Identity rules need an exception path, not just a match key

Identity resolution decides whether two records refer to the same real-world thing. On the account side, a weak rule can split one customer into multiple entries and spread its opportunities across them. On the contact side, it can create duplicate outreach or merge two different people. A deterministic key is a useful first step, but it is not the whole policy. Company domains can be shared by business units, changed after rebrands, or absent from a signup using a personal address. Email identifies an address, not a permanent human identity.

Start with a documented hierarchy of evidence. An established internal account identifier should survive an enrichment update. A verified business domain can support matching, but a conflicting company name or parent relationship should trigger review rather than automatic certainty. For contacts, use normalized addresses carefully, preserve previous addresses as historical associations where appropriate, and avoid broad fuzzy merges based only on similar names. The right policy depends on the business. A parent-level enterprise seller and a product-led business selling to individual teams may need different boundaries.

Name the owner of ambiguous matches. A queue without an owner is simply a place to hide uncertainty. Give the reviewer the original values, proposed match, supporting evidence, and affected downstream records. Before merging, inspect ownership, open opportunities, suppression, and activity history. Keep an audit record and a practical way to correct a bad merge. The acceptance test is not whether duplicates disappear. It is whether the remaining identity accurately represents the company or person without losing the information the business needs.

Let buying behavior determine account hierarchy

A large company may contain several subsidiaries or business units that buy independently. Treating them as unrelated accounts loses the parent relationship. Collapsing them into one account loses the distinct buying decisions. Neither extreme is automatically correct. The useful question is who signs, who pays, who uses the product, and who renews. If those responsibilities sit with different entities, the account structure needs to retain that distinction while supporting a deliberate rollup for enterprise-level reporting.

A flatter hierarchy reduces maintenance effort but can obscure real differences in purchasing behavior. A deeper hierarchy preserves detail but adds relationships that someone must maintain through acquisitions, rebrands, and internal reorganizations. Keep the hierarchy as shallow as the actual commercial process allows. Do not add a child account merely because a public data source lists a regional office. Do not flatten a child account that genuinely has its own budget and agreement. Write down examples so users do not have to recreate the policy every time.

Test hierarchy changes against both operational and reporting questions. If a subsidiary joins an existing parent, does an open opportunity keep its original commercial owner? Does an account-level suppression decision extend to the subsidiary, or require a separate interpretation? Can finance still reconcile the contracting entity to the billing record? Can a sales leader view the parent without counting the same opportunity twice? These questions reveal whether the hierarchy is a usable model of the business or just a neat-looking tree.

Record where a fact came from and when it was checked

Provenance is the source of a data point. Freshness is how recently it was observed or verified. An employee-count field typed by an SDR, supplied by enrichment, or inherited from a parent merge carries different uncertainty. Without that context, a field appears authoritative simply because it is populated. A routing decision based on an old size estimate may send an account to the wrong team while leaving no clue about why the decision was made. More complete data is not always more reliable data.

For fields that influence routing or segmentation, record source and verification time alongside the value. In a small operation, this can begin with a documented convention rather than a sophisticated metadata platform. An automated update should change the value and its provenance together. If only the value changes, the record may falsely suggest that a human verified it. If only the timestamp changes, a stale fact may look fresh. Track the observation date separately from the date an integration happened to import it.

Freshness policies need an action when the window expires. Depending on the field's importance, that might mean requesting verification, lowering confidence, or excluding the value from an automated decision. There is no universal expiry period for all revenue data. A pending opportunity's owner may require rapid correction; a stable industry classification may tolerate a longer review interval. Define windows based on the cost of being wrong, then inspect exceptions. Freshness should govern decisions rather than serve as a decorative timestamp nobody uses.

Every integration is a contract between interpretations

A CRM, marketing platform, product analytics system, and billing tool can all use the word customer while referring to different states. One may mean an account with a signed agreement. Another may mean a person using a paid workspace. A third may mean an entity with an invoice. These are not necessarily errors. They become errors when an integration maps the labels without mapping the meaning. Before connecting systems, write down which object is being transferred and which system owns each field.

For each important flow, specify the fields, update timing, precedence, and failure behavior. What happens when an address changes? What happens when the source removes a record? What happens if the destination receives events out of order? How do you prevent an old enrichment result from overwriting a newer human correction? A working integration should preserve context as well as move values. A successful import notification does not prove that the destination has the correct business state.

Small teams should prioritize the contracts with the highest consequences: ownership, suppression, bookings, opportunity classification, and compensation-related data. Start with a one-page agreement and concrete examples. Include a named owner and an alert path. If the sync breaks, the response should be more specific than waiting for someone to notice a strange dashboard. Reconciliation can catch mistakes, but documenting expected behavior makes those mistakes easier to identify and less likely to recur when a field or workflow changes.

Routing and suppression have to agree before a rep acts

Routing answers whose job a record is. Suppression answers whether the proposed action should happen at all. A routing engine that assigns every record successfully can still create a bad outcome if it assigns an existing customer to net-new outreach or ignores a person's contact preference. Evaluate eligibility before celebrating coverage. A record can be correctly matched to an account and still be ineligible for the workflow because of an active opportunity, an existing relationship, a do-not-contact instruction, or unresolved ownership.

Define an ordered routing policy with an explicit conflict path. For one business, existing relationship ownership may come before a named-account assignment, followed by territory and a fallback queue. Another business may need a different order. The point is not to adopt a universal hierarchy. It is to make the team's hierarchy visible and test it. If two rules match, the system should explain which won. If none match, it should surface uncertainty instead of silently distributing a record that needs review.

Suppression must survive new imports and new signals. Reintroducing an unsubscribed contact because a separate tool discovered a fresh event defeats the purpose of recording the preference. Decide which system is authoritative, how quickly updates propagate, and what happens while confirmation is unavailable. The safer operational choice for an uncertain send is often to hold it. This article does not establish legal permission for any outreach. US and EU teams should verify applicable requirements and platform rules with qualified advisers before implementing contact workflows.

Ratios change meaning when their populations change

Conversion rates are ratios. A qualified-opportunity count divided by raw form submissions measures something different from the same count divided by distinct eligible accounts. Both can be calculated accurately, yet only one may answer the question the business is asking. The denominator needs a written definition, an observation period, and a stable unit. Without those, a percentage can move because duplicates increased, an exclusion rule changed, or the intake mix shifted—not because the sales team became better or worse.

Suppose a trial flow begins requiring a payment card. The people who start may now differ from those who started under the previous flow. A higher trial-to-paid percentage would not, by itself, show that the product or sales process improved. Likewise, raising a qualification threshold can shrink the denominator toward stronger accounts. Keep the original definition available, annotate the change date, and compare compatible cohorts. Sometimes the most useful report shows the new definition and the old definition side by side until the transition is understood.

Open opportunities require particular care. Wins divided by all opportunities is a cohort-to-date conversion measure. Wins divided by won plus lost opportunities is a closed-decision win rate. Neither is inherently wrong, but presenting one as the other creates confusion. State the cutoff and show how much pipeline remains unresolved. A young cohort can have a low conversion-to-date figure simply because it has not had time to mature. The right interpretation depends on what decisions the metric is meant to support.

A fictional 100-account funnel, reconciled step by step

Consider a fictional B2B SaaS company called Lanternworks. The following figures are constructed arithmetic, not customer results or benchmarks. Its monthly intake contains 130 raw account records. Review removes 18 duplicate records and 12 ineligible entries: four competitor records, five existing customers outside this net-new workflow, and three internal tests. That leaves 100 distinct eligible accounts. The cohort is frozen at those identifiers so later updates do not silently change the population used to evaluate it.

Routing assigns all 100 accounts, but six initially reach the wrong owner. Review catches and reassigns them before activity begins. This is a useful distinction: a routing defect occurred, but it did not create a duplicate account or necessarily change the final cohort. After qualification, the team creates 40 apparent opportunities. A separate audit discovers four duplicate records representing the same commercial pursuits as four of the other records. Removing those duplicate opportunity entries leaves 36 distinct net-new opportunities associated with the original eligible account cohort.

Assume each of the 36 opportunities belongs to a different cohort account for this example. The account-to-opportunity rate is therefore 36 divided by 100, or 36 percent. Dividing the same 36 by the original 130 raw records gives approximately 27.7 percent. The arithmetic is valid in both cases; the label must explain the denominator. Neither figure demonstrates an improvement in sales performance. Their difference shows the effect of counting duplicate and ineligible intake records as if they were eligible accounts.

At a later reporting cutoff, nine opportunities are won, fifteen are lost, and twelve remain open. The closed-decision win rate is nine divided by twenty-four, or 37.5 percent. The cohort's opportunity-to-win conversion to date is nine divided by thirty-six, or 25 percent. Both are legitimate measures with different meanings. If the nine wins each have an illustrative annual contract value of $42,000, cohort bookings total $378,000. Dividing bookings by the original 100 eligible accounts gives $3,780 per entrant. None of these numbers should be generalized beyond this constructed example.

Attribution is a documented allocation rule, not proof of causation

Attribution assigns credit to recorded interactions. It does not necessarily establish which interaction caused a purchase. A contact may attend a webinar, read an article, reply to an SDR, and later involve colleagues whose activity is not tracked. Choosing first touch, last touch, or a multi-touch model is a way of distributing recognition across the available evidence. A polished model cannot recover interactions that were never observed or prove what would have happened without the campaign.

Set boundaries around eligible touches. A webinar attended years earlier should not receive current opportunity credit merely because it exists in the historical record and no one specified a lookback window. Define the window, the person-to-account matching rule, and how dormant accounts reenter a journey. Also decide whether expansion and net-new opportunities use the same policy. These are business choices with trade-offs. Make them explicit and version them so a later analyst can reproduce the allocation instead of guessing which defaults were active.

Separate sourced and assisted reporting when it helps explain the journey, but do not add those figures together as if they were unique bookings. The same opportunity may appear in both views. Show the underlying identifiers, the value basis, and the allocation policy. If a campaign receives more attributed pipeline after the policy changes, annotate the change. Otherwise, the team may direct budget toward a measurement artifact rather than toward activity that genuinely helps buyers progress.

Reconciliation should find causes, not merely match totals

Reconciliation compares the same defined population through independent paths. Matching the total pipeline value in the CRM and the warehouse is useful, but an equal total can hide offsetting errors. One missing opportunity and one duplicate of the same value produce a reassuring number. Compare record identifiers and classifications as well as sums. Check whether the same opportunities exist, whether their amounts use the same currency treatment, and whether both systems apply the same stage and cutoff definitions.

Begin with the few measures that influence important decisions. For each, retain a reproducible query or report definition, a known cutoff, and a list of expected exclusions. When a discrepancy appears, classify it: timing difference, identity mismatch, missing record, conflicting field ownership, or metric-definition drift. A timing gap may be acceptable within a documented window. An unexplained suppression mismatch may require immediate action. Treat the category, not just the current total, so the repair applies to sibling workflows sharing the same assumption.

The review should produce an owner and a next action. A spreadsheet full of unexplained exceptions is not a control. Record the decision, the evidence used, and whether historical reports need correction. If a repair changes a previously reported business figure, say so rather than quietly updating the chart. Trust comes from explaining revisions clearly. Revenue data does not need to be perfectly immutable, but the business should be able to understand why a number changed.

Make changes fast enough to use and clear enough to audit

Change control does not have to mean a committee for every field edit. It means preserving what changed, why, who approved it when approval was necessary, and when it became effective. A lead-scoring threshold, account classification, suppression rule, or attribution window can alter reports without changing the underlying business. A shared changelog with a precise description and example is a reasonable starting point. Avoid vague entries such as improved routing; they do not help explain an unexpected reassignment later.

Apply more scrutiny where consequences are higher. A compensation-affecting definition or a workflow that can send messages deserves review and testing. An exploratory chart may need only a logged change. If every adjustment receives the same ceremony, people will bypass the process. If none receive review, the business discovers mistakes through commission disputes or prospect complaints. Choose a lightweight policy based on the risk of being wrong, and make emergency fixes possible without losing the record of what happened.

Keep a small test set of awkward cases: shared domains, a rebranded company, a former employee, an acquired subsidiary, an active customer with a new inbound contact, a duplicate event, and a suppressed person discovered by another source. Run it when matching or routing rules change. The test set is not proof that every edge case is covered. It is a memory of the cases the team has already decided must work, which is more valuable than relying on whoever happens to remember the previous incident.

Build an operating routine that outlasts the cleanup

A cleanup project ends. The business keeps changing. New products, territories, acquisition targets, and integrations introduce new assumptions into the data model. A sustainable routine includes frequent checks on important reconciliation measures, a regular review of ambiguous matches and routing exceptions, and periodic evaluation of freshness and hierarchy rules. The exact cadence depends on activity and risk. Start small enough to maintain rather than scheduling an ambitious governance program that disappears after the first busy month.

Give incidents a named owner and a severity based on impact. A broken forecast sync, a stale enrichment field, and a suppression failure are different problems. The response should preserve evidence, stop harmful actions where necessary, correct the source of the error, and identify which downstream records need repair. Afterward, write a short note explaining what happened and why the existing controls missed it. Avoid a vague promise to be more careful. Add a concrete check or change the underlying assumption.

The result is not an impressive new dashboard. It is a revenue system whose numbers have an intelligible history. When a conversion rate moves, the team can ask whether buyer behavior changed, whether the cohort matured, or whether a documented rule changed. When a record routes unexpectedly, the owner can inspect the evidence rather than guess. That is the practical standard I would use for RevOps data quality: decisions that can be traced, corrected, and reproduced before they become stories about performance.