A company running four systems asks what an account is and gets four answers.

For finance, an account is the tax ID, because the invoice needs one. For sales, it is the holding company that signs, because that is the entity that negotiates. For CS, it is the contract that renews. For marketing, it is the domain that converted.

All four answers are correct inside their own system. None of them is wrong, and the forecast does not close.

This is the problem data cleanup does not solve, because it is not a formatting problem. After deduplicating, standardizing spelling and filling required fields, the four definitions remain intact, now written in the same spelling.

The two layers of normalization

Normalizing data across teams has two layers, and the market treats only the first.

The format layer answers how the value is written. Standardized spelling, consistent type, merged duplicates, required fields filled. It is necessary work, it has a settled method, and it delivers something verifiable.

The meaning layer answers what the value stands for. Which entity the word account designates, which event the word win represents, which condition the word MQL requires. That layer has no delivery, it has a period of validity. It stays valid as long as someone is responsible for maintaining it.

Salesforce, on its data management page, describes the first layer precisely: cleaning standardizes formats, removes errors and gives data a usable structure, and master data management creates a single trusted version of key data. The framing is honest and it solves copies. A single version of a record does not solve two definitions of a win living in the same standardized field.

The distinction matters because the two layers fail differently. A format failure produces a visible error, with duplicate records and a report that does not run. A meaning failure produces a report that runs, a number that appears, and three readings that contradict each other without any of them raising an alert.

The three names that cross every team

Three words appear in the vocabulary of marketing, sales, CS and finance at the same time. Those are the ones that break.

What an account is

The case described at the opening. The divergence does not come from carelessness, it comes from legitimate and different needs: issuing an invoice, negotiating a contract, renewing a subscription, attributing a conversion.

An operational definition has to pick one primary entity and declare the others as attributes of it. While the four coexist as equals, any count of customers depends on who runs the query.

What an MQL is

HubSpot describes an MQL as a lead the marketing team considers more likely to become a customer than others, and explicitly asks marketing and sales to work together to identify, explain and record the characteristics that make up an MQL on that team.

The verb that matters in that recommendation is record. The difference the vendor describes is buyer readiness. The difference the operation feels is acceptance: marketing marks it, sales sends it back. The field accepts the value because validation checks format. The criteria sales applies at acceptance lives somewhere else, and validation does not know it.

What a win is

A win breaks where the CRM and the financial result meet. Sales marks it when the buyer commits. Finance recognizes it when the obligation is fulfilled. CS counts it when the offer delivered is the offer sold.

With no shared rule, the same month produces forecast revenue, recognized revenue and renewed revenue, all called a win. Standardizing the spelling of the stage decides nothing about which event the number represents.

Why field validation does not reach meaning

A reader with CRM experience raises the right objection: part of this gets solved with validation and closed lists.

Validation checks whether a value belongs to an allowed set. It does not check whether the value was assigned for the right reason. A rep can mark a win on a deal finance does not recognize, and validation accepts it, because the value is on the list.

Sync rules between systems have the same limit. The most common two-way setting determines that the most recent value overwrites the previous one, which resolves a write conflict and resolves no conflict of meaning. The definition agreed on Monday disappears on Tuesday if someone edits the field afterward.

What is missing sits upstream of the field. While the definition lives in a glossary and the field lives in the system, the operation has two sources, and the one that wins is the one closest to the moment of writing.

What a definition needs in order to hold

An operational definition has five properties. Missing any one of them, it returns to being a glossary.

A verifiable statement: Conditions two different people assess the same way. "Account with potential" is not verifiable. "Account in tier A or B of the current ICP, with a contact holding stated influence over budget" is.

A single owner: One person with authority to change it. When the definition has two owners, it gets renegotiated mid-execution, and the version that holds depends on who spoke last.

Version and date: Every record created under the definition carries the version that was in force. Without that, comparing conversion across quarters loses meaning, because a drop admits two incompatible explanations, a performance change and a definition change.

A point of application: The exact place the definition is consulted, which has to be the same place the record is created. A definition that requires opening another document does not survive a queue with a deadline.

A destination for exceptions: What happens when someone needs to deviate from the rule. An exception field stays clean when something downstream consumes it and returns consequence to whoever fills it. With no consumer, it degrades within weeks to the first option on the list.

A definition record with all five properties fits in a few lines:

Name: SQL. Version 3, in force since March 12. Owner: Revenue Operations lead. Statement: account in tier A or B of the current ICP, contact with stated influence over budget, pain mapped to one of the covered use cases, decision window stated within two quarters. Application: the lead acceptance screen. Exception: mandatory reason from a list of five options. Supersedes version 2, changed because 40% of the previous quarter's rejections cited the absence of a decision window.

The last line is the one most operations do not have. It turns the definition into something that evolves with evidence, rather than changing by opinion in the quarterly meeting.

Governance as decision rights

The most common market reading of data governance is a council, a policy and a dictionary. The canonical reference of the profession says something else.

DAMA, in its description of the DMBOK, places governance at the center of the discipline and states what it is not. Governance is not a council, a policy library or a technology implementation. It is the function through which an organization exercises authority and control over the planning, stewardship, use, protection and value of its data, coordinating definitions, metadata, quality expectations and issue management.

Authority over definitions is exactly the property missing when account means four things. The council exists, the policy exists, and nobody holds the formal right to decide which entity the word designates when finance and sales disagree.

In that framing, governance in Go-to-Market is not a project running parallel to RevOps. It is the assignment of decision rights over the names the operation uses every day, exercised in execution rather than in a forum. The work of keeping that rule alive through the week is what we describe in RevOps in practice.

What changes in the forecast meeting

With the five properties in place, the forecast meeting changes subject.

Without them, the first half hour reconciles numbers. How many accounts are customers, which month recognizes which revenue, whether the sales pipeline matches the marketing report. The direction discussion starts once the time is gone.

With them, the number arrives single and the meeting discusses what to do with it. The disagreement that remains is about the definition itself, and that discussion has an owner, produces a new version with a date, and live executions inherit the change.

The gain is time between divergence and correction. When the definition lives in the file from the last cleanup, the correction waits for the next quarter. When it lives in the system execution consults, it changes inside the open cycle.

At Strataflow the five attributes live in the same place. The Organization layer holds the normalized entity, the commercial catalog and the structure, which Initiatives inherit without reopening vocabulary. Cycle Definitions carry entry, exit and success criteria with a version. The Knowledge layer keeps metrics, funnel logic and taxonomy available to the next execution, alongside what the previous Cycle taught.

How to start a normalization process

Alignment across teams is achievable, and it has to happen before any tooling decision. What it requires is a written agreement on a few names, with an owner and a date, and a place where execution consults that agreement.

Step 1: Pick three names, not twenty. The ones that appear in more than one team and have already caused a disagreement in a forecast meeting. In most operations they are account, MQL and win.

Step 2: One spreadsheet, one row per version of each name, with eight columns: name, version number, effective date, owner, statement, point of application, exception handling, and what this version supersedes with the reason for the change. An old row is never edited, only succeeded.

Step 3: Move the statement to where the record is created. Field help text in the CRM, descriptions on the picklist options, the header of the acceptance queue. As long as the statement lives only in the spreadsheet, it is not consulted at the moment of decision.

Step 4: Stamp the version number on the record. A short text field on the object, filled by simple automation with the version in force on the creation date. Without this step, no comparison across periods is interpretable afterward.

Step 5: A monthly review with a named owner and a single question: what in this month's execution contradicts the definition. The output of the review is a new row in the spreadsheet or nothing.

This arrangement holds an operation with one sales motion and three definitions for several months, and it is already better than what most companies have today.

Cautions with this approach

Recording the definition is the easy part to maintain. Keeping it current is where the process fails, and that deserves attention before it scales.

The main risk is silent drift. The definition changes in a conversation between the sales leader and marketing, the operation starts applying the new criteria in practice, and the spreadsheet keeps describing the previous one. From that moment, every report built on it produces a number that is technically correct and semantically wrong. Nobody notices, because there is no visible error: the report runs, the chart appears, and the reading leadership takes describes an operation that no longer exists.

The practical effect is worse than the original divergence. With no normalization, the company knows the numbers do not match and reconciles them in the meeting. With outdated normalization, the company trusts a number that describes last quarter, and decides budget allocation, team targets and segment cuts on that basis. Apparent alignment replaces the checking that used to happen.

Three aggravating factors make the drift likely rather than occasional.

Dependency between definitions: Win depends on account, MQL depends on ICP, and ICP depends on segment. From the fourth or fifth definition onward, changing one requires revisiting the others, and the spreadsheet does not flag who depends on whom. The review turns into a memory exercise for whoever was in the room.

Variation by motion: The same definition usually needs to vary across segments, because enterprise acceptance criteria are not mid-market acceptance criteria. The spreadsheet becomes either single and imprecise, or one per motion, and the original problem returns multiplied.

Exceptions with no consumer: The reason list exists in the spreadsheet and returns no consequence to whoever fills it. With nobody reading the aggregate and changing the source, the field degrades within weeks to the first option, and the evidence that would support the next version disappears with it.

The point where all three arrive at once is predictable: more than one sales motion running in parallel, more than three live definitions, and more than one system where the same criteria has to hold.

From there, normalization stops being a record to maintain and starts requiring a system that takes part in the operation. Currency that changes inside the open cycle, dependencies between definitions that flag who needs to revisit, variation by motion without duplicating the base, and exceptions that return as consequence to whoever filled them. A spreadsheet does not deliver that, because a spreadsheet does not know when the operation changed behavior.

Frequently asked questions

What is data normalization across teams?

Normalization across teams has two layers. The format layer standardizes spelling, type and duplicates. The meaning layer defines which entity the word account designates, which condition the word MQL requires and which event the word win represents. The first has a delivery date, the second has a period of validity.

Why does data cleanup not resolve the divergence between marketing and sales?

Because cleanup corrects format. After deduplication and standardization, the definitions remain intact, now written in the same spelling. Marketing marks an MQL in a sense validation accepts and sales refuses in conversation.

What does a definition need in order to hold in the operation?

Five properties: a verifiable statement, a single owner, a version with a date stamped on every record, a point of application in the same place the record is created, and a named destination for exceptions.

Is data governance the same as a council and a policy?

The DAMA reference describes governance as the function through which an organization exercises authority and control over the planning, use and value of its data, coordinating definitions and quality expectations. A council and a policy are instruments of that function, not the function itself.

Why stamp the definition version on every record?

Because without the version, a drop in conversion between quarters admits two incompatible explanations, a performance change and a definition change, and there is no way to separate them after the fact.