An opportunity handoff is the moment an account changes owner inside the revenue operation, and the criteria authorizing that change either hold or fail. It happens three times per cycle: when a rep accepts the lead marketing sends, when sales rejects and records the reason, and when CS receives the account sales closes.

RevOps in practice describes the four dimensions that support Revenue Operations, and identifies the operational dimension as the one most implementations postpone. The three handoffs are where that dimension becomes verifiable.

All three share a property that separates them from the rest of the operation. Each is a writing moment, on a short clock, performed by someone under queue pressure. Criteria that require leaving that moment to consult an external document survive none of the three.

The test is direct. Compare the current SQL definition against the last fifty accepted leads and count how many pass. The gap between the definition and the sample is the size of the problem.

Why the definition of RevOps is settled and the implementation is not

The model has consensus. Gartner projects that 75% of the highest growth companies will deploy a RevOps model, and names functional silos, with teams handing clients from one function to another using different technologies and processes, as a direct barrier to revenue growth. Forrester quantifies the opposite direction, with companies that align people, process and technology across revenue teams posting 36% higher revenue growth and up to 28% higher profitability than siloed organizations.

The friction shows up on Gartner's own revenue operations page, which acknowledges that the term carries multiple definitions, treated as a title change, an org structure, or a software category, and that none of those readings captures the impact of the function.

The missing definition is operational. RevOps describes what needs to be aligned. Tactical-operational practice describes where that alignment becomes verifiable, under what record, and under whose ownership. That is the scope this article covers, along with the technical requirements it imposes on any enterprise operation running more than one growth motion at a time.

Criteria applied at acceptance

The MQL and SQL definition exists in nearly every enterprise operation. It is written, it goes through leadership approval, and it lives in a document someone reviews every couple of quarters. Friction shows up when a rep receives a lead at 2pm on a Tuesday and decides to accept or reject in under a minute, without opening that document.

Acceptance happens in a short window, under queue pressure. The operator decides from memory, not from documentation. Any criteria that requires leaving the writing moment to consult a reading artifact stops being applied within weeks.

Usable SQL entry criteria are verifiable and simultaneous. An example with four conditions:

1. Account classified in tier A or B of the current ICP.
2. Contact with stated influence over budget.
3. Pain mapped to one of the use cases the product covers.
4. Decision window stated within two quarters.

Three elements determine whether that criteria becomes operation or stays a document.

Location: The criteria lives on the record the rep opens to decide, with the conditions visible at the moment of acceptance. Anywhere else, the application rate drops without anyone noticing, because acceptance records keep getting created the same way.

Version: The SQL definition changes over the year. When the March version differs from the June version and neither is stamped on the record, quarter-over-quarter conversion comparison loses meaning. A drop from 34% to 27% in SQL to opportunity conversion admits two incompatible explanations, a performance change and a definition change, and without the version stamped there is no way to separate them.

Owner and SLA: Acceptance carries a named owner, a response SLA, and a defined consequence when the SLA breaks. Without an SLA, the qualified lead ages in the queue and the conversion metric starts measuring wait time instead of source quality.

Reason recorded at rejection

Rejection carries more information about the operation than acceptance does, and it is usually the first field to degrade.

A usable reason list has five to seven mutually exclusive options, each pointing to a different owner of the fix.

• Outside ICP - Fix belongs to segmentation and source.
• No budget authority - Fix belongs to enrichment and routing.
• No decision window - Fix belongs to nurture, with scheduled re-entry.
• Pain outside product scope - Fix belongs to messaging, with a signal to product.
• Account already in pipeline-  Fix belongs to deduplication.
• Active contract with a competitor - Fix belongs to a re-engagement sequence tied to renewal date.

The design principle that keeps the field alive: an exception field stays clean when something downstream consumes it and returns consequence to whoever fills it. Without that return, the field degrades within weeks to the first option on the list, and the report starts measuring dropdown order.

Reading the field in aggregate changes the type of decision it supports. Forty percent of a quarter's rejections classified as outside ICP, concentrated in a single source, points to a segmentation and budget allocation decision. Rejection volume on its own points to SDR performance. The two readings lead to opposite actions, and only the second one is available when the reason does not exist as data.

Timing matters as much as the field. A correction made during the open cycle changes execution in flight. The same correction presented at QBR three months later becomes a report on a period that already closed.

The promise handed to CS

When the opportunity closes, the CRM hands CS the account name, the value, the date, the contracted product and the agreement.

What stays outside the record is what determines how the customer perceives success in the first ninety days: the integration scope agreed during the technical call, the time to first result mentioned in negotiation, the training committed, and the metric the customer uses internally to judge whether the purchase works.

Research sizes the problem. Forrester surveys more than 16,000 business buyers in The State of Business Buying 2024 and finds 81% of them dissatisfied with the provider they select at the end of a successful purchase process, rising to 91% among younger buyers. The same study reports that 86% of purchases stall at some point in the process.

Dissatisfaction that surfaces after signature originates in what the commercial operation promises and does not record. The practical consequence lands in churn analysis. First-year cancellations get logged as a product problem when part of them start from expectation misalignment created during the sale. Without a record of what sales commits, the analysis cannot separate the two causes, and the fix goes to the roadmap when it belongs in the sales playbook.

The operational adjustment is to generate the onboarding action from the playbook, with the origin of the commercial conversation attached to the account record.

This point closes the loop that opens at acceptance. The criteria applied at entry determines which accounts reach CS. An account accepted outside the ICP becomes churn nine to eighteen months later, and by then the acceptance decision has left everyone's field of view. In enterprise sales, the signal returns too late for any individual's memory. Closing a loop with that delay requires a record that outlives the full cycle.

The structural limit of the current stack

Each category in the stack solves one part and leaves the rest uncovered.

CRM

Records the current state of the deal well. Does not record the criteria that produces the state, or the reasoning that changes the criteria. Custom fields cover part of this and create a second problem, because the criteria becomes a field value with no history, overwritten on the next edit.

Docs and wikis

Store criteria with version history and sit outside the moment of decision. The distance between where the rule lives and where the rule applies is the source of most drift.

BI

Shows the result after the period closes. It serves reporting, and arrives too late to correct the execution that produced the number.

Task tools

Carry the action without the strategy that justifies it. The action exists on the board, the reason behind it disappears along the way, and the quarterly review finds execution with no hypothesis attached.

Automation

Moves data between systems without deciding anything. A poorly designed process, once automated, breaks faster and at higher volume.

The diagnosis that comes out of this list: criteria, execution and learning live in three systems with no shared object. Someone has to stitch the three together by hand. In most enterprise operations, that someone is the RevOps lead, who ends up operating as a human integration layer between tools. The arrangement works while that person has bandwidth and degrades the quarter they do not. In those operations, tactical-operational RevOps exists as a person rather than as a system, and the proof shows up when that person leaves the company.

What a system needs to support the three handoffs

Five requirements follow directly from what the three moments need.

1. Versioned criteria at the point of decision. The current definition stays visible where the record is created, with version and date stamped on every record produced under it.

2. A destination for every exception. Each exception field has a named consumer and a return path to whoever fills it. A field with no consumer becomes noise within six weeks.

3. A trace from action to strategy. From the action to the playbook, from the playbook to the cycle objective, from the cycle to the growth initiative that justifies it. Without that trace, results review cannot attribute what works.

4. An accumulation scope above execution. Learning from one execution needs a place that outlives it, and that the next execution consults by default rather than by individual initiative.

5. Continuous reading of the whole set. An operation running four simultaneous motions generates more signal than one person can read every week. Reading becomes automatic, decision stays human, and each approval is recorded with author and date.

None of these requirements is met by adding more tools to the stack. All of them require criteria, execution and learning to share the same data model.

A coordination layer above the stack

That requirement is what Strataflow addresses. The CRM stays the system of record for the deal, email stays the channel, the CS tool stays the home of the book of business. The coordination layer sits above what the company already runs.

The structure has three levels.

Workspace

The institutional level. It holds the current ICP, the company structure, the catalog of products and services, and the data layer feeding the levels below.

GTM Initiative

A growth motion with its own objective, owner, business unit and region. An enterprise expansion initiative groups the Cycles pursuing the same objective, with a health diagnosis of the motion as a whole.

Cycle

The operational unit. Cycle Definitions carry entry criteria, exit criteria and success criteria. Playbooks generate Actions with a traceable origin back to the definition that justifies them. Impacted Accounts shows where execution lands.

Two mechanisms operate on top of that structure.

Orchestration maintains a decision queue with pending, in review, applied and history states. Each item enters with origin, severity and owner, including competitive risk signals and AI-generated recommendations. Nothing becomes an action without recorded approval.

The Knowledge Base, scoped to the Cycle and the Initiative, keeps what one execution learns available to the next execution of the same motion. The GTM Agent reads that set continuously and surfaces the next highest-impact move.

Applied to the three handoffs: acceptance criteria live in Cycle Definitions with the version stamped, the rejection reason feeds the Orchestration queue that adjusts the open Cycle, and the onboarding action originates in the Playbook carrying what sales commits during negotiation.

Implementation sequence

Four moves, in order, each with an observable signal that it works.

1. Criteria at the point of writing, with version and date. Signal: two different reps classify the same lead the same way.

2. Rejection reason list cut to five options, with weekly review by a named owner. Signal: the distribution of reasons varies between quarters instead of concentrating in a single option.

3. Playbook generating the onboarding action with the origin of the commercial conversation. Signal: the first CS meeting does not spend time reconstructing what sales agreed to.

4. Cycle close with a record of what changed the criteria. Signal: the next Cycle opens with a different definition, and the change traces back to the data that caused it.

Diagnosing your own operation

Five questions, answerable in an hour with CRM access.

1. What is the current version of the SQL definition, and what date does it carry?
2. Of the last fifty acceptances, how many pass that definition?
3. What is the distribution of rejection reasons for last quarter, and who reads that report every week?
4. Among accounts that cancel in year one, how many reach CS with a record of what sales committed?
5. If the RevOps lead leaves tomorrow, how many of these points still work the following week?

In an operation with one sales motion and a small team, one person holds the first four points together with a spreadsheet and discipline. In an operation with four simultaneous motions, a nine-month sales cycle and separate teams per segment, the volume of decisions exceeds what one person can read. That is the point where the criteria has to live in the system.

Frequently asked questions we usually receive

What is the difference between RevOps and tactical-operational RevOps? 

RevOps names the function that aligns marketing, sales and customer success around shared data, process and goals. Tactical-operational RevOps names the implementation layer of that function, verifiable at three points in the daily operation: lead acceptance, the recorded rejection reason, and what CS receives from the commercial conversation.

How do you know whether a company's RevOps exists in practice?

By comparing the current SQL definition against a sample of the last fifty accepted leads. When most of the sample does not pass the written criteria, the model exists as a document rather than as an operation.

How many rejection reasons should an operation carry in the CRM?

Five to seven, mutually exclusive, each pointing to a different owner of the fix. Longer lists dilute the data, and lists with no downstream consumer degrade to the first dropdown option within weeks.

Does the CRM solve tactical-operational RevOps?

The CRM records the current state of the deal. It does not record the criteria producing that state, or the reasoning that changes the criteria over time. Custom fields store criteria as a value overwritten on the next edit, with no version history.

Why does enterprise need a system when a smaller operation does not?

The interval between an acceptance decision and the corresponding churn signal reaches eighteen months in enterprise sales. With one sales motion, a single person holds that context. With four simultaneous motions and separate teams per segment, the volume of decisions exceeds what one person can track every week.