A 600-employee account downloads a technical asset. The path is worth following, because each stop shows the exact point where one of the functions stops looking.

Day 0: Automation adds points for title, size and engagement. The account clears 70, becomes an MQL, enters the queue. Marketing Ops logs one more against the week's volume, and the account leaves that function's dashboard.

Day 1: Routing distributes by territory. The account lands with an AE who works a different segment. Sales Ops measures response time and queue coverage, and neither metric sees fit.

Day 4: The AE opens the account, assesses it, and does not work it. No formal rejection, because rejecting requires a justification. The account ages in the queue. At that moment it stops existing as a signal in any system: it is not a rejection, it is unworked pipeline, which Sales Ops reads as a discipline issue.

Day 30: The cleanup routine returns the account to nurture. Marketing Ops receives a record with no reason attached and puts the account into the next campaign, at the same score it already had.

Day 90 and day 150: The cycle repeats twice, new campaign, same outcome.

Month 7: The same account arrives through a customer referral, closes in six weeks, and CS inherits name, value, date and contracted product, with no idea it circulated three times before.

Why the leak degrades no metric

This is what makes the problem hard to see. None of the three functions recorded a decline.

Marketing Ops counted three MQLs within the automation rule, at a stable cost per lead. Sales Ops held its conversion rate on what the team actually worked, because the unworked account never entered that denominator. CS gained a new account with onboarding delivered on time.

The real cost was seven months and three paid campaigns on an account that was in profile from day zero. That cost has no line on any dashboard, because each metric is calculated inside its own lane, and the gap between the lanes falls outside all three denominators.

The forecast is the only place the sum shows up, and by then the data arrives aggregated. Pavilion, in the CRO Survival Guide, describes exactly that effect when it observes that what looks like a pipeline issue is often a series of mismatched inputs flowing into the forecast.

The three blind spots between the functions

The path above exposes three specific gaps, and none of them belongs to a single function.

Non-action generates no data

A formal rejection creates a record. An account the AE opens, assesses and abandons creates nothing. Since rejecting requires a justification and not rejecting costs nothing, the rep's rational behavior produces the worst possible outcome for the operation, which is the absence of a signal.

The fix is operational before it is cultural. Every account in the queue needs a deadline and a mandatory outcome, with a short list of reasons. Without a deadline, non-action stays invisible.

The score does not know capacity

Marketing Ops scoring measures account fit. Sales Ops territory and book assignment determine who receives it. The two rules are built separately and meet at routing, with nobody checking the collision.

A high-scoring account landing in a territory with no coverage is acquisition cost already spent and sitting still. Marketing Ops does not see the territory, Sales Ops does not see the score.

The promise from the sale does not travel

When the opportunity closes, the CRM hands CS name, value, date and product. What stays outside is the scope agreed in the technical call, the time to first result mentioned in negotiation, and the metric the customer uses internally to judge the purchase.

The effect surfaces months later in churn analysis, where a cancellation driven by misaligned expectations gets logged as a product problem. The operational detail of these handoffs sits in what a structured opportunity handoff looks like.

What the market solves with an org chart

The standard answer to those three blind spots is to create a function that looks between the lanes.

Pavilion, in its piece on how to implement RevOps in HubSpot, frames the question precisely: who is in charge of looking for operational bottlenecks between departments. The answer the text gives is RevOps.

HubSpot, in its revenue operations strategy piece, draws the lanes. Sales Ops is narrow by design, covering pipeline, quota, CRM hygiene, forecasting and enablement, reporting to the sales org. Marketing Ops is the parallel function, owning campaign, lead scoring, automation and attribution, optimized for MQL volume and cost per lead. RevOps appears as the unification of both, plus CS operations, with responsibility for the full customer lifecycle.

Salesforce, in its What Is Revenue Operations guide, cuts by horizon. Sales operations enters midway through the revenue cycle, and revenue operations covers the entire journey, from product development to cash collection.

All three readings describe the division of responsibility well. None of them closes the three blind spots, because adding a fourth box to the org chart does not turn non-action into data, does not make the score aware of capacity, and does not carry the promise from the sale into CS. What RevOps has to deliver beyond the drawing sits in RevOps in practice.

HubSpot itself records the signal that the drawing is not enough: when sales and marketing are already aligned and the company still sees inconsistent data, broken post-sale handoffs and unpredictable revenue, the text recommends moving from sales ops to RevOps. Operations feel something different, because a company can have all three boxes and the same leak.

What has to be shared for the silo to fall

Coordinating three functions through a meeting costs one meeting a week and works as long as the meeting exists. What sustains coordination without a meeting is a set of things all three functions read and write in the same place. There are seven, and each one closes a specific type of leak.

The entity: The account is the shared unit. While marketing runs leads, sales runs opportunities and CS runs subscriptions, under separate identifiers, the same company exists three times and none of the functions can claim they are talking about the same thing. Normalizing the entity comes before any metric, because without it reconciling numbers becomes permanent weekly work.

The metric definition: MQL, SQL, acceptance, activation and churn calculated once, with version and date. Two formulas under the same name describe two operations. With the version stamped on every record, a drop in conversion becomes answerable, because a performance change can be separated from a definition change.

The goal: A shared goal for the motion, with each function's contribution declared, rather than the sum of three lane goals. When Marketing Ops answers for volume and Sales Ops answers for win rate, both can hit their own number while the motion loses. A declared contribution makes visible which function has to change when the motion's number falls short.

The Cycle objective: What execution is pursuing in this period, with success criteria and exit criteria set before it starts. Without that, each function reads priority off its own queue, and the real priority becomes whoever asked last.

The hypothesis: What the operation is testing, who proposed it, and what would have to be true for it to work. With no record, three functions test in parallel on the same base and none learns from the other. A hypothesis that fails and goes undocumented returns as a paid campaign the following quarter.

The risk: Pipeline concentration in a few accounts, dependency on one source, a competitor's price move, a territory with no coverage. Each with an owner, a trigger and a severity. Risk that exists only in the perception of whoever sits closest disappears when that person changes teams.

The cross-functional action: An action that starts in marketing and ends in sales, with an owner at each step and a single status. While the action lives in three tools, the handoff depends on someone sending a message, and the whole operation inherits the response time of that channel.

The seventh item is the return. What the Cycle teaches has to change the current definition, rather than only appearing in a retrospective. Without that closure, the previous six age together.

How this layer differs from the rest of the stack

A RevOps reader raises the right objection here: part of this already exists in tools the company owns. It is worth separating what each one solves.

The data warehouse normalizes data and does not hold the decision. It answers what the number was, and it does not answer which rule produced the number or who changed the rule.

The dashboard reads and does not write. The metric on it opens no work, and the distance between seeing the number and acting on it is still a meeting.

The task tool writes and does not hold the definition. The action exists on the board without the hypothesis that justifies it, and the quarterly review finds execution with no premise attached.

The CRM holds the current state of the deal well, and overwrites the criteria on the next edit, with no version history.

All four are necessary and none of them is where definition, execution and learning coexist in the same model. The missing layer reads and writes across all three at once: the current definition with a version, the action that originates from it with a traceable origin, and the return that changes the next version.

The same account, with the infrastructure in place

It is worth running the opening path again, now with the seven shared items.

Day 0: The 600-employee account clears 70 on the score. The score is calculated against the current ICP definition, which has a version and an owner, and the Initiative the account belongs to declares which segment this Cycle is pursuing.

Day 1: Routing checks territory and capacity on the same record. The account lands in a territory with no coverage, and that enters as a decision item with an owner, instead of becoming a silent assignment.

Day 4: The account carries an outcome deadline. The AE assesses it and marks a reason from a list of five mutually exclusive options. Non-action stops being free, because the deadline expires and the record requires an outcome.

Day 11: The aggregated reason shows three accounts from the same segment stopped for the same reason. The hypothesis behind that segment gets revised inside the open Cycle, with the source adjusted and the acceptance definition updated for the next version.

Month seven stops existing on this path, because the decision about the account happens on day 11 rather than through a referral half a year later. The gain is not automation, it is time between signal and correction.

Who answers for what

Shared infrastructure does not remove the division of responsibility, it changes what each function answers for.

The definition has a single owner: One person responsible for MQL, SQL and stage criteria, with version and date. When the definition has two owners, it gets renegotiated in the middle of an accept, and the version that holds depends on who speaks last.

Execution within the lane stays distributed: Sales Ops answers for pipeline and quota, Marketing Ops answers for campaign and score, and each reports on its own metric inside the same Initiative.

The return from the gap has a named destination: The reason behind non-action, the collision between score and territory, and the promise CS inherits. An exception field only stays clean when something downstream consumes it and returns consequence to whoever fills it.

At Strataflow the seven items live in the same structure. The Workspace holds the normalized entity, the current definition and the data layer, inside the Organization layer. Initiatives carry the motion's goal, objective and hypothesis, and distribute execution across the functions. Cycles execute with entry, exit and success criteria set before they start. The Operations layer keeps playbooks and actions with the origin of the decision, and the Orchestration layer receives risk, rejection reasons and recommendations as a decision queue with severity and owner, with the GTM Agent surfacing the next highest-impact move.

Sales Ops stays in the CRM, Marketing Ops stays in automation, and CS stays in the account tool. Coordination gets a place of its own, instead of depending on someone reconciling numbers after the period closes.

Frequently asked questions

What is the difference between RevOps and Sales Ops?

Sales Ops is narrow by design, covering pipeline, quota, CRM hygiene, forecasting and rep enablement, reporting to the sales org. RevOps covers the full revenue cycle, from first marketing touch to renewal, with data definitions and handoff criteria shared across the functions.

What does Marketing Ops do that RevOps does not?

Marketing Ops runs campaign execution, lead scoring, automation and attribution, optimizing its own metrics such as MQL volume and cost per lead. RevOps governs the rule those inputs have to respect so they remain valid in the other lanes.

Why is the leak between the three functions hard to detect?

Because each metric is calculated inside its own lane. The unworked account never enters the sales conversion denominator, the returned lead goes back to the marketing base at the same score, and the sum only surfaces in the forecast, already aggregated.

What has to be shared between Marketing Ops, Sales Ops and CS?

Seven items: the normalized entity, each metric definition with a version, the motion's goal with contribution declared per function, the Cycle objective with success criteria, the hypothesis under test, the risk with an owner and a trigger, and the action that crosses more than one function under a single status.

Does a data warehouse solve the silo between functions?

The warehouse normalizes data and holds neither the decision that produced the number nor the rule that changed over time. It is necessary and insufficient, because the silo persists in the absence of a place where definition, execution and learning coexist in the same model.

Does creating a RevOps team solve the problem?

Creating the box resolves reporting. The gap stays unowned as long as non-action creates no record, the score does not know territory capacity, and the promise from the sale does not travel into CS.