RevOps value isn’t universally contested. It’s situationally contested. The same function that gets treated as a strategic intelligence layer at one company gets treated as glorified CRM administration at another. That gap is rarely about the practitioner’s skill. It rarely reflects the quality of their business case. It almost always reflects the org they walked into. The culture of RevOps is what needs to change. The psychology of it.

Where RevOps is already valued

Some organizations have already done the cognitive work. RevOps as an intelligence and operations layer isn’t a foreign concept. The category doesn’t need to be sold. Folks have mostly heard about RevOps by now so it should boil down to our ability to execute.

CRO led organizations with operational DNA tend to fall here. CROs who came up through structured enterprise sales environments, including the Salesforce ecosystem, Oracle, and high volume B2B SaaS, know what functioning RevOps looks like. They’ve managed through quarters with unreliable forecast data. They’ve seen the consequences of conversion metrics that live in spreadsheets nobody trusts. When you walk in as RevOps in one of these orgs, the conversation shifts fast from “why does this matter” to “what are you going to build.” The strategic value of the function is assumed. The operational question is whether you can deliver.

PE backed portfolio companies work similarly, but the driver is different. Private equity investment theses run on specific numbers. ARR per employee. CAC payback period. Net revenue retention as a proxy for product quality and account health. EBITDA per dollar of growth investment. These aren’t metrics that show up once a year in an investor update. They’re the inputs that drive the value creation plan and ultimately the exit multiple. The portfolio company without clean, reliable access to those numbers is a problem the fund won’t tolerate for long. Research on PE backed SaaS makes this explicit: comp plans that don’t incentivize multi year contracts produce exactly the short term deal behavior you’d expect, and it’s RevOps that exposes that misalignment. In a PE environment, RevOps doesn’t need to justify itself. Our value should already be baked in… I hope!

Then there are organizations that hit what practitioners call the scaling wall. ICONIQ Capital’s research on SaaS growth identifies a growth plateau that tends to appear around the $20-25M ARR mark, where the systems and habits built in earlier stages buckle under a larger team. Forecast misses start appearing with regularity. New rep ramp time extends. Compensation disputes surface because the commission rules were built for fifteen people and the team is now fifty. The founder who used to know every deal can no longer hold the pipeline in their head. The VP Sales who ran on intuition and relationship knowledge runs out of bandwidth.

When an organization hits that wall hard, and usually it takes a painful quarter or two to make it undeniable, the RevOps mandate becomes real fast. It tends to arrive after a crisis, which is late. But the mandate that follows a genuine crisis is usually genuine. Nobody is debating whether the function matters when the board has asked four straight forecasting questions the team couldn’t answer cleanly.

CFO partnered growth organizations are a fourth environment where RevOps finds real organizational backing. The CFO who cares about LTV/CAC and payback periods is asking for the same data infrastructure RevOps builds. When the CFO and CRO are aligned on unit economics, and that alignment is increasingly the default as efficient growth has replaced growth at any cost as the primary investor priority, RevOps has two executive sponsors instead of one. That is a meaningfully different political position than having one.

Reading the org before you take the role

This diagnostic doesn’t just apply to practitioners already in seat. It applies before you accept an offer.

The org type signals are usually visible in the hiring process if you know what to look for. Ask who RevOps has historically reported to, not who it will report to in the new role, but where it has lived. The reporting line reflects the organizational theory of the function more accurately than any job description does. A RevOps role that has reported into IT twice in three years tells you something about how leadership frames the work. A RevOps role reporting directly to the CEO or CRO signals a different conversation.

Look at the reason the role exists. Is RevOps being built for the first time, or is it replacing someone who left? If it’s a replacement, find out why the previous person left. Voluntary departures from RevOps roles in contested environments are often exits driven by operational frustration. The function was constrained in ways the practitioner couldn’t change. Understanding that history before you accept the role lets you make a genuine assessment of whether the conditions have changed.

Ask specifically about the relationship between sales and the other go to market functions. In interviews, the language leaders use to describe the relationship between sales and marketing, and whether they describe it as a relationship at all versus two separate operations, reveals quite a lot about the alignment RevOps will be working within or against.

None of these questions guarantee you’ll read the org perfectly before joining. But they improve the odds significantly, and they set up an honest conversation about expectations before you’re in the seat.

Where RevOps is still a question mark

The harder environments show up more often. Walking into one without recognizing it is how otherwise skilled practitioners get stuck on problems that look like communication failures but are actually organizational ones.

Founder led sales cultures are the most common version of this. When the founder is the revenue engine, closing on relationships and institutional knowledge that lives entirely in their head, RevOps looks like process overhead applied to something that’s already working. The ICP is the founder’s intuition. The playbook is the founder. In this environment, you’re not just pitching a function. You’re implicitly suggesting that the thing the founder takes the most personal pride in could benefit from systemization. That is a more politically loaded conversation than it appears on the surface, and it rarely goes well when pursued directly.

VP Sales dominant organizations present a related but distinct version. The VP Sales who owns the revenue number and sees anything that creates cross functional visibility into rep activity as a threat to their autonomy is a real stakeholder archetype. Data on win rates and stage to stage conversion isn’t neutral information in this org. It’s a performance audit they didn’t commission. They want CRM administration. They don’t want a strategic partner surfacing conversion trends to the board. The org chart tells the story clearly: if RevOps reports into the VP Sales, the function gets scoped to support that leader’s preferences, incentives, and blind spots. Everything outside that scope becomes a political fight you haven’t earned the standing to win yet.

The “we just need more pipeline” org is one where leadership has diagnosed a volume problem when the actual problem is conversion or lead quality. The answer to every growth challenge is more SDR headcount and more outbound volume. RevOps in this context registers as a distraction from the top of funnel investment that leadership is already convinced will fix things. The accurate read, that pipeline quality and stage velocity matter, that rising CAC often reflects falling close rates more than rising acquisition costs, that adding volume on top of a broken conversion motion produces linear results at best, isn’t what they want to hear. Delivering it too directly, too early, gets RevOps positioned as obstructionist.

Organizations where RevOps reports to IT or Finance get siloed at the functional level before the function can do much of anything. IT cares about uptime, access management, and system security. Finance cares about cost containment, period accurate reporting, and compliance. Neither function is primarily thinking about GTM architecture or pipeline velocity or comp plan alignment. The RevOps function gets oriented toward the priorities of whoever it reports to, and in both cases, that means orienting away from the revenue conversation that would make the function useful. The org chart here doesn’t just shape what RevOps works on. It shapes what RevOps is permitted to care about.

Then there’s the org where the tool is the strategy. “We just need to use Salesforce better” is a statement that reveals a category of thinking. The CRM vendor has become the de facto operating model, and RevOps gets reduced to platform administration. The problem is that no amount of Salesforce optimization changes territory design, realigns comp incentives, or fixes the handoff between marketing and sales. These are process and incentive problems, not system configuration problems. But when the current paradigm frames them as system problems, the RevOps practitioner who tries to push upstream on process is swimming against a current that’s been flowing for a while.

The question stakeholders are actually asking

None of the resistance in those contested environments is really about whether RevOps creates value. What stakeholders in difficult orgs are actually asking is simpler and more uncomfortable: “Are these people going to make my life harder, create visibility I don’t want, or slow down what already works for me?”

That is a threat perception question. It doesn’t get resolved with a business case. Revenue impact projections and ROI frameworks don’t move people who are primarily worried about exposure, loss of autonomy, or losing the informational advantages they’ve built over years. Those things move people who have already decided you’re safe to work with. That decision, consciously or not, happens before most practitioners ever get to present anything.

The implication is that trust has to precede value communication. And in organizations, trust comes from a narrow set of experiences: you made my work easier, you made me look good to someone who matters to me, or you told me something honest that others weren’t saying. These are the building blocks. The strategic partnership comes later.

In a new or contested environment, the job for the first several months is not primarily to sell the function. It’s to become the person that specific, influential individuals want working on their problems.

Building your mandate from the bottom up

With the diagnostic in place, the communication and relationship work follows a more predictable shape.

Gap framing, not gain framing. Most RevOps practitioners default to gain framing: here’s what RevOps could enable, here’s the productivity we’d unlock, here’s what companies with mature RevOps functions achieve. This framing is accurate and doesn’t generate urgency. Stakeholders in contested environments don’t wake up excited about potential upside. They wake up worried about existing problems.

The more powerful opener is loss aversion applied as communication strategy: what is the absence of this capability currently costing you. Not in the abstract. Specifically. What did the last forecast miss cost in hiring decisions that got delayed by six weeks? What did the comp dispute with the top AE last quarter cost in distraction, legal review time, and leadership attention? What would it mean, concretely, for the next board meeting, to actually know whether the Q3 number was real or optimistic? These are conversations that land because they’re about pain that already exists and is already being felt.

The most effective version of gap framing names the cost before the stakeholder does. If you can walk into a conversation with a VP Sales and open by saying “it looks like your ramp time has extended by about six weeks over the last two quarters and I’d like to understand what’s driving that,” you’ve already demonstrated that you’ve done the analysis and you’re coming with data, not a pitch. That changes the dynamic immediately. The conversation shifts from “RevOps is going to create more work for me” to “RevOps has already done work on my problem.”

Making invisible costs visible is higher leverage than selling a vision. The vision conversation asks stakeholders to imagine a future they can’t verify. The cost conversation asks them to account for something they’ve already experienced but probably haven’t quantified. The second conversation creates urgency in a way the first one doesn’t.

Run the listening tour as intelligence gathering. The listening tour concept gets recommended often in change management contexts, usually as a relationship building exercise. That framing undersells it. A well run listening tour is intelligence gathering. You’re not just creating goodwill. You’re learning the specific language and specific pain of each stakeholder before you’ve committed to a communication strategy.

The questions that matter here:

• What makes your forecast conversations painful?

• Where does your confidence in the pipeline number break down?

• What’s creating friction for your reps that shouldn’t exist?

These aren’t generic. The answers tell you which problems are acute enough to move people to action, who owns them, and where a visible early win is possible. They also tell you which problems to avoid touching, because some of them belong to stakeholders who aren’t ready to acknowledge the problems exist.

The listening tour also reveals the political landscape more accurately than any org chart does. You learn which VP Sales is open to data conversations and which one experiences data as accountability. You learn which marketing leader is eager for pipeline attribution clarity and which one knows the attribution is bad and prefers it stays vague. That map is invaluable.

Solve something small and set someone up to look good. The mandate doesn’t arrive via proposal. It comes from a moment where a specific stakeholder realizes their working life is better with you in it. That moment is almost always small, specific, and fast. A dashboard the VP Marketing didn’t have to build. A comp model error you caught before it reached the board deck. A pipeline report that answered a question the CRO had been trying to answer for three weeks.

Small, visible problems solved quickly, with credit flowing to the stakeholder who was identified as caring about them, this is how you accumulate political capital. It sounds counterintuitive for a function that’s supposed to be making its own case. But the business case for RevOps gets made through repeated demonstration of usefulness to specific people, not through a strategic presentation to a room of skeptics. Each small win also produces something more valuable than gratitude: it produces a specific story the stakeholder can tell when someone else asks what RevOps does around here. In contested environments, those second order endorsements are the foundation of the mandate.

Prioritize by pain and influence, not strategic importance. Early RevOps prioritization looks like a question of strategic value: which problems are the most important to the business? That’s the right question eventually. In the first phase of building a mandate, the right question is different: which problems are acutely painful for people with enough organizational influence to become real advocates?

The intersection of acute pain and organizational influence is where early effort produces disproportionate return. A highly strategic problem that nobody is currently losing sleep over won’t generate the urgency or the gratitude that a smaller, more immediate problem will. Solve for what people actually feel, and you build the standing to pursue the strategically important work later.

Build relationships from the bottom up, not the top down. Top down RevOps mandates, the “we’re doing RevOps now and everyone needs to engage with it” announcement from leadership, produce compliance without trust. People show up to the required meetings and continue doing what they were doing before. The function exists on paper and atrophies in practice.

Bottom up relationship building is slower and it builds. Start with the people who have the most acute pain and the most openness to trying something different. Solve their problems. They tell colleagues. That colleague has a problem that also needs solving. The mandate grows through the accumulation of individual moments of usefulness rather than through a top down announcement. The difference becomes clear when you eventually need to push for something that creates friction, a process change, a data standard, a comp plan redesign. The practitioner who built their mandate from the bottom up has a network of stakeholders who have personally benefited from working with them. That network becomes the coalition that absorbs and advocates for the harder work.

The type of org receptiveness will dictate your timeline

Building a mandate in a contested environment takes longer than building one in a receptive environment. That’s just how it is.

In a PE backed portfolio company with a commercially oriented CEO and a CRO who came up through structured enterprise sales, the trust building phase compresses because the cognitive work has already been done elsewhere. The org is ready. In a founder led culture where RevOps is a new concept and the founder has been running on intuition for seven years, you might spend six to nine months on foundational relationship building before you have the political capital to address the actual systemic problems. Both timelines can be appropriate given the starting conditions.

Understanding which environment you’re in early changes how you set expectations, with yourself, and with whoever hired you. Committing to strategic outcomes in a six month window in a contested environment without an established ally network sets you up to underdeliver on things that were never realistic given the starting conditions. Committing to a trust and relationship building phase that earns the right to pursue larger outcomes later is both more honest and more likely to actually work.

The practitioners I’ve seen build the most durable RevOps mandates in difficult environments share a consistent approach: they read the org quickly, adjusted their timeline accordingly, and invested in individual relationship quality before they pushed for systemic change. The systemic change happened. It just happened later, once they had the standing to push for it and the allies to absorb the friction.

Read the org first before you just go in and build the case.

Members: the RevOps Stakeholder Communication Playbook is available below. It includes an org type diagnostic with scoring questions, gap framing scripts by stakeholder type, a listening tour question bank organized by stakeholder role and pain category, a quick win identification matrix, and a 30/60/90 day mandate building plan template.

Read more

It’s been 60 days since my last tuner publication and these frontier AI labs innovate FAST! The last model my mantra was “stay liquid”. Meaning, you should remain flexible. Now RevOps teams have to decide between four models: Fable, Opus, Sonnet, and Haiku. The new top tier costs twice the previous one. Fable pricing sure is top of the top!

So the obvious question is whether you should reach for it.

But the framework that produces the right “no” is the same framework that produces the right “yes” when the use case calls for it. This is my initial assessment after having switched several workflows and agents to Fable. There are some serious pricing dynamics that surround it.

What Fable 5 actually is

Fable 5 is the publicly available release of Mythos class capability, previously restricted to government cybersecurity partners and select Glasswing program participants at $25/$125 per million tokens. The public version costs less than half that, at $10/$50, sitting roughly 2x above Opus 4.8 on both input and output prices.

The model is built specifically for what Anthropic calls autonomous knowledge work. Long horizon tasks. Multi step problems with ambiguous structure. Work that previously required frequent human checkpoints because the model couldn’t be trusted to maintain coherence across many steps. Fable 5 ships with verification loops, self correction behaviors, and improved reliability on tasks that “would otherwise take a person hours, days, or weeks.”

Two details matter for GTM teams. First, the 1M token context window with 128K maximum output, which means you can hand it your full account history, prior call transcripts, deal documents, and competitive research in one API call and ask for a coherent output. Second, the safety routing behavior. Fable 5 has safety classifiers on cybersecurity, biology and chemistry, and distillation queries. When a query matches one of these classifiers, the request gets automatically routed to Claude Opus 4.8 and billed at Opus 4.8 rates. Anthropic notifies users when it happens, or so they say! Based on early data, the classifier fires in fewer than 5% of sessions. For GTM use cases this is largely irrelevant unless you’re running highly sensitive workflows, but it sets a precedent worth tracking. But it does make you question whether Anthropic is overreaching with a dash of censorship?

The distinction from Claude Mythos 5 is access control rather than capability. Mythos 5 has the same underlying model with no safety classifiers and remains restricted to approved programs. For practical purposes, Fable 5 is what GTM teams will use.

Spending on token

Anthropic added a tier above Opus at $10/$50 without cutting Opus, Sonnet, or Haiku prices. Opus 4.8 launched May 28 at the same $5/$25 as 4.7. Sonnet 4.6 sits where Sonnet has sat for two years, $3/$15. Haiku 4.5 sits at $1/$5.

It’s tempting to read this as a missed opportunity for price competition. But I think this is intentional.

Sonnet has held at $3/$15 across every generation since Claude 3 launched in March 2024. Multiple years, multiple major releases, same price. Haiku actually went UP when 3.5 Haiku launched in November 2024, from $0.25/$1.25 to $1/$5, a 4x increase that Anthropic justified as reflecting the model’s increase in capability over Claude 3 Opus on many benchmarks. Opus did drop materially at some point in the 4.x series, from the original $15/$75 down to $5/$25, but that drop happened under direct competitive pressure from GPT-5 and Gemini Pro on premium reasoning. It was not tied to a new top tier launch.

Anthropic’s pricing has held or increased within model families, with drops happening only when external competitive pressure from peer tier models forces them. New tier launches don’t trigger price cuts on existing tiers. But competition does!

Fable 5 launched into a market where there’s now significant downward pressure on the bottom of the price ladder. DeepSeek V4 Pro shipped on April 24 at $0.435/$0.87 per million tokens, with the launch discount becoming the permanent list price on May 22. V4 Pro is roughly 28x cheaper than Opus 4.8 on output and 34x cheaper than GPT-5.5. The open weight Llama and Gemma alternatives sit in similar territory. The economic gravity on Haiku and Sonnet is increasing. Pricing pressure between Foundation labs is one source of price dropping, but more so from the open source models.

It begs the question, at what point do open soure models reach good enough status?

Anthropic had a strategic choice. Cut Sonnet and Haiku prices to defend against open weight commodity pressure. Or expand UP into more capable, higher priced territory and let the bottom be competitive on its own merits.

They chose to expand up. I think it’s smart! I alongside many other AI fanboys and fangirls gush over how amazing Anthopic’s models are. I find mself operating with these models on a daily basis.

The bet is that frontier capability is defensible at premium prices, that there’s enterprise demand willing to pay $10/$50 for autonomous workflows that justify the premium, and that the volume layer (lead routing, BANT scoring, ticket classification, enrichment) is going to be competed away anyway. The strategic question for Anthropic isn’t whether DeepSeek beats Haiku on price. It’s whether Anthropic can hold ground at the frontier while commodity competition takes the rest. What a balancing act.

The downward pressure on routine workflow costs is going to come from open weights and the GTM teams that figure out how to use them safely. The downward pressure on premium workflow costs may also come, but slowly, and probably from competition between Anthropic, OpenAI, and Google at the very top rather than from price wars in the middle.

Build your architecture accordingly. It’s what my AI modeling tuning matrix is for.

Frontier vs Value: the framework

The widening gap between the top and bottom of the price ladder has created a question that was less important a year ago.

1. For any given GTM use case, what is the best capability available?

2. And separately, what is the cheapest model that produces acceptable quality?

These two answers used to be close enough that most teams could pick the better one and not think too hard about it.

They aren’t close anymore.

For lead routing, the Frontier answer is Opus 4.8 at $5/$25. The Value answer is Haiku 4.5 at $1/$5, a 5x price difference. The quality difference on routing classification is so small that it’s not measurable at scale.

For deep account research, the Frontier answer is Fable 5 at $10/$50. The Value answer is Gemini 3.5 Pro or Opus 4.8 at less than half that. The quality difference on truly autonomous multi hour research is real and material. The quality difference on a 30 minute account brief is not.

For data enrichment at high volume, the Frontier answer for teams with US data residency requirements is Haiku 4.5. The Value answer for teams whose policy permits non US providers is DeepSeek V4 Flash at $0.14/$0.28, roughly 7x cheaper than Haiku.

The new edition of the tuner adds three columns to every use case row. Frontier model. Value model. Tradeoff. The tradeoff column captures what you actually give up when you choose Value over Frontier. Sometimes the tradeoff is small enough to ignore. Sometimes it’s material. The discipline is asking the question per use case rather than picking a default and applying it everywhere. Paid Substack members get immediate access to the tuner in detail.

A team defaulting to Frontier across the board is paying somewhere between 5x and 20x more than necessary, depending on the workload mix. Spending on tokens like drunken sailors. Let’s go! But equally, a team defaulting to Value Mode (“cheap and cheerful crowd”) across the board is leaving real quality on the table. The framework forces the per use case judgment.

Walking the GTM use case map

Most GTM use cases have a clear winner per category. A walk through of the highest impact ones illustrates the pattern.

Lead routing. Frontier: Opus 4.8. Value: Haiku 4.5. The tradeoff is minimal. Routing is a classification task with structured inputs (lead form fields, source, firmographic data) and structured outputs (territory, owner, queue). The capability gap between Opus and Haiku on this work doesn’t show up in production. Cost delta 5x. Pick Haiku.

BANT and MEDDPICC scoring on form fills. Frontier: Sonnet 4.6. Value: Haiku 4.5. Light reasoning, clear rubric, structured output. The tradeoff is minor and surfaces only on edge cases with ambiguous input. Cost delta 3x. Lean Haiku for high volume, Sonnet if you need higher precision on lower volume.

MEDDPICC parsing from call transcripts. Frontier: Opus 4.8, or Fable 5 if the parsing chains across multi call deals where context compounds. Value: Sonnet 4.6 with structured prompting. The tradeoff is roughly a 5-10% quality drop on complex multi stakeholder deals, where Opus catches subtle implications that Sonnet misses. For most teams, the Sonnet pick is correct because the quality drop matters less than the 1.67x cost saving.

Outbound personalization at scale. Frontier: Sonnet 4.6. Value: Haiku 4.5. Tradeoff small on routine personalization, meaningful for high touch accounts. Lean Haiku for SDR volume work, Sonnet for AE volume work where the per touch value justifies the difference.

Real time call coaching. Frontier: Sonnet 4.6. Value: Haiku 4.5. Latency bound anyway, so the model selection is constrained by inference speed. Quality difference is minimal in practice. Pick Haiku.

Deep research and account briefs. Frontier: Fable 5 for truly autonomous multi hour briefs that compound across many sources. Value: Gemini 3.5 Pro or Opus 4.8 for shorter briefs. This is one of the cases where the tradeoff is real. Fable 5’s verification loops and self correction matter when the agent is running unattended for hours. For a 20 minute briefing prep, I would just go with the value plays.

High volume data enrichment. Frontier: Haiku 4.5 for teams with US data residency. Value: DeepSeek V4 Flash for teams whose policy permits non US providers. Quality is comparable on structured field population. For US and EMEA companies you’ll likely have data residency requirements so the US based models it is. However, the open source models are highly capable. HIPAA/BAA requirements also dictate going with the Frontier.

Multi-agent orchestration as planner. Frontier: Fable 5. Value: Opus 4.8. This is the case worth examining most carefully, because the planner’s quality compounds across every downstream subagent it calls. The next section walks through this in detail.

Recursive agent building —> agents building agents?

My buddy Nikko Georgantonis posted a super credible agent setup on LinkedIn that captures where this is all going. If you haven’t seen it, here it is.

He built out an agent that monitors the routing queues for his sales org. Downloads the logic of what roles should be in what queues. Pulls Snowflake for the active AE roster. Sends a message if anything is off. In a few months, he says, he’ll be comfortable with it actually making the changes itself. WHAT!?

This is the canonical multi-agent GTM workflow. And it’s the right place to do a film breakdown on Frontier vs Value selection, because every step has a different right answer. I have no way of knowing exactly what models Nikko selected here so this is only my hypothesis.

Step 1 is the orchestrator deciding what to build. Nikko works out of Claude Code, which drives n8n through an MCP to build the workflow. The orchestrator decomposes the goal (”monitor routing queues for inconsistencies”) into the operational steps: identify data sources, structure checks, design alert logic. This is Frontier territory. The planning quality compounds across every downstream execution call. A poor plan creates ten subagent calls producing subtly wrong output. A good plan creates ten subagent calls that work first time. Opus 4.8 is the right pick here for most teams. Fable 5 earns its price only if the agent has to do this planning autonomously across many such workflows without a human checkpoint between them.

Step 2 is the workflow builder generating the actual n8n nodes via MCP. Frontier: Sonnet 4.6. Value: Haiku 4.5. The tradeoff is real here. Haiku struggles with multi step n8n composition because the structural complexity of node graphs exceeds what it handles cleanly. The Value pick wastes more cycles iterating than the Sonnet premium costs. Lean Sonnet here.

Step 3 is documentation. The agent writes back to GitHub as it goes, leaving a trail for the next agent. I cover leveraging GitHub in lecture 3 of my RevOps for AI course (shameless plug).

AI for RevOps

Nikko said “documentation is the product”. WHAT!? For all you documentation lovers out there… OUR TIME HAS ARRIVED.

If the documentation is consumed by humans (Nikko reads it later, his teammates browse it), write quality matters and Sonnet 4.6 is the right pick. If it’s mostly machine consumed (the next agent reads it as context), the bar shifts and Haiku 4.5 with structured prompting works fine. Most teams will end up running this as Sonnet because the hybrid case (humans and agents both reading the docs) demands it. I’d expect we, humans, will be quite involved with inspecting workflows for quite some time. But one day… the agents will build agents and lean towards machine efficient reading.

Step 4 is the execution pull from GitHub. The agent loads the role logic, the queue definitions, the rules. This is reading and parsing structured data. Haiku 4.5 is fine. No need to live on the Frontier here.

Step 5 is the Snowflake query. Pulling the active AE roster requires SQL generation from a natural language specification. Clearly you’d have to have a datawarehousing setup with CRM data mirrored over via ETL. You’ll live with a slight delay in synchronicity, but it’s better than taxing your CRM via API call. For a simple roster pull, Haiku handles it. For complex aggregations or joins, Sonnet’s reliability justifies the 3x premium. But I’d say that most queue monitoring workflows are simple roster pulls. Proceed to the Value tier.

Step 6 is the comparison and anomaly detection. Pattern matching between “who should be in each queue” and “who actually is.” This is structured comparison work. Haiku 4.5 is competent but you should know that Sonnet catches subtler issues. The tradeoff depends on how much of the value comes from catching the subtle ones. For most teams, Haiku is the right call.

Step 7 is the alert message to Nikko. Writing a concise, useful Slack message. Both Haiku and Sonnet do this well. The tradeoff is negligible so the Value tier it is!

Step 8 is the future state Nikko describes, where the agent makes the changes itself rather than alerting him. This is where the calculus changes. Now the model is making decisions that affect production sales operations workflows (we’re being replaced!). The cost of one wrong change includes potential lost deals, broken account assignments, or revenue rep frustration. I would not want to mess around with any value models here. Clearly live on the Frontier here with Fable. Or live with Opus and have it sit side by side with manual workflows for a few months. If the manual decisions and autonomous decisions match, then we are in a brand new operating paradigm.

The cost differential will compound into real overspend or savings. Running every step on Fable 5 for a workflow that executes ten times per day at modest token volume would burn through roughly $40 per day. Running each step on the right tier per step burns roughly $5 per day. That’s an 8x cost reduction with no quality loss on the steps where the gap doesn’t matter. Across a fleet of similar agents (Nikko mentions he has many across go to market), the multiplier compounds.

This is why having an AI Operating framework matters. A team that runs every agent on Fable 5 because “it’s the best” is paying enterprise prices for commodity work (sad face). A team that tiers properly across the steps is paying for capability where it earns its keep.

Where Fable 5 fits like a glove in GTM

Five categories of GTM work justify Fable 5 economics.

Autonomous workflows running over an hour or more without human checkpoints, where self correction matters. Most RevOps work has frequent checkpoints as they should. The agent surfaces a result, a human reviews, a decision is made. Fable 5 doesn’t make sense there. But where the workflow runs unattended across many steps (Nikko’s future state of agents making changes), the verification loops would justify Fable.

Compounding error tasks where each step’s mistake amplifies downstream. Multi call deal qualification across a full deal lifecycle. Complex account research that builds on its own findings. The planner role in any multi agent system.

Work where the cost of one undetected error exceeds the model premium by 10x or more. Contract review. Complex deal desk decisions. Account specific executive prep where the consequence of a wrong fact in a CRO briefing is real. Strategic account intelligence for major opportunities.

Tasks the model can verify itself, where the savings on human review time pay for the premium. Anything with self correction loops baked in. Anything where the agent can check its own work against ground truth.

The orchestrator role in agent systems.

For everything else, Frontier is overpayment. The framework’s job is making the distinction clear per workflow.

What this framing requires architecturally

The Frontier vs Value framing only works if the architecture supports it.

Model abstraction so swapping between tiers is a config change. My step by step breakdown above only works if the team has the ability to route different steps of a workflow to different models trivially. Hardcoded provider SDKs make this impossible.

Per workflow cost observability so you can see what Frontier is actually costing you versus Value. Without this, the framework is a thought experiment. With it, you can run the math monthly on whether each workflow is on the right tier.

Quality benchmarks so you can test whether the tradeoff is real on your specific data. Generic benchmarks tell you that Opus is better than Sonnet on coding. They don’t tell you that Opus is better than Sonnet on your team’s MEDDPICC parsing for your deals. Build your own benchmarks and take the time to inspect the outputs.

Quarterly re-evaluation, because the tradeoffs shift. The next 75 days will deliver new pricing, new model generations, and likely new tiers above Fable 5. The architecture that lets you adapt is more durable than the picks you make today.

AI Operations is truly a new operaating discipline. I’m figuring it out just as much as you are.

The frontier moved up

The frontier moved up. The discipline is knowing when to follow it and when not to.

For most GTM work, the answer is not. Lead routing on Haiku. BANT on Haiku. Enrichment on Haiku or DeepSeek depending on policy. Personalization on Haiku or Sonnet depending on touch level. The use cases where you actually need Fable 5 are concentrated in autonomous multi agent orchestration, compounding error tasks, and high stakes work where one undetected error costs more than the model premium ten times over. These are real opportunities but few and far between.

The bigger story is the pricing strategy underneath the launch. Anthropic is betting on defending the frontier at premium prices while letting commodity competition handle the bottom. The GTM teams that win the next year will read that bet correctly. They’ll architect for the tier of work each task actually requires. They’ll use open weights where policy permits and Frontier where the workload demands. They’ll measure cost per workflow and quality per workflow separately, so the tradeoff stays empirical rather than vibes based.

Or our finance teams will finally start placing the clamps on token spend. When that day comes, knowing model architecture will keep you at the operator’s edge.

For paid members: this week’s deliverable is the GTM AI Model Tuner workbook, refreshed for June 12 with Frontier and Value picks added to every use case row, the explicit tradeoff captured per row, and the full diff against the April 23 edition built into a dedicated tab. The new Model Comparison tab includes Fable 5, Opus 4.8, GPT-5.5, Gemini 3.5 Flash, and DeepSeek V4 Pro and Flash with current pricing. The Cost Estimator supports Frontier vs Value selection per workflow so you can run the math for your specific volume mix. Download the workbook, drop in your monthly volumes, and use it as the operating tool for the architecture this article describes.

Read more

What strikes me about this is how much of it comes back to measurement architecture rather than marketing strategy. The companies with thin pipeline did not necessarily make bad spending decisions. Many of them made completely rational decisions inside a measurement system that was showing them an incomplete picture.

The buying process your pipeline review does not see

Start with what the research says about how B2B buying decisions actually form.

Forrester’s 2025 Buyers’ Journey Survey found that 70 to 80% of the B2B evaluation process happens before first vendor contact. 92%percent of buyers begin with a vendor already in mind.

Read that last number again. By the time a prospect fills out a form, books a discovery call, or replies to an outbound sequence, the shortlist has almost certainly already been assembled. Your company is either on it or it is not. The actions your pipeline review tracks are largely downstream of the decision that determines whether you were in the conversation at all.

AEs report this with enough consistency that it deserves to be taken seriously. Prospects mention in discovery calls that they first learned about a company from a podcast appearance, a newsletter, a peer recommendation at a conference, a LinkedIn post they saw months earlier. The influence was real. In many cases it was the reason the company was on the shortlist. And it generated zero trackable data in Salesforce or HubSpot.

This is not a soft observation about brand awareness. Brand is just really really hard to measure!

The gap is widening. When a B2B buyer asks an AI answer engine for vendor recommendations, the companies that surface are the ones with substantial content presence across the web. Buyers are increasingly beginning their research this way. Forrester’s data on the number of stakeholders involved in a purchase compounds the problem: 13 people inside the buying organization and nine outside it, each doing independent research, each arriving through channels you cannot track. Every one of those people is forming an opinion before they become visible to your revenue team.

If you are running a pipeline review built around CRM data, you are reviewing the 20% of the buying process that left a trace. The other 80% happened in channels your dashboard was never designed to see.

What attribution was designed to answer

Attribution models were built to answer a specific question.

It’s a useful question. For e-commerce, for consumer software, for any purchase that happens in a single session or close to it, the answer is both available and meaningful. Someone clicked an ad, landed on a page, entered a credit card. Attribution works.

B2B enterprise software is a different category of purchase. No one buys a $250,000 solution based on one interaction with one person. The buying committee researches across multiple channels over months. Individual stakeholders form views independently. The person who ultimately signs has often been aware of the vendor for a year or more before the opportunity ever appeared in a pipeline report.

Attribution models applied to this purchase type produce a misleading picture. The final touchpoint before form fill gets the credit. The 18 months of podcast appearances, conference sessions, peer conversations, and content that built the familiarity that made the prospect receptive get nothing.

The downstream consequence plays out in budget planning. Programs that generate traceable events get funded and expanded. Programs that build awareness before any traceable event fires cannot produce an ROI number in the format the CFO wants. Over time, the budget composition shifts. More outbound sequences. More paid campaigns. More money chasing a shrinking pool of trackable responses. The pipeline does not get thicker. CAC payback gets longer.

This is where the coverage problem originates. It is not that demand generation stopped working entirely. It is that a system optimized exclusively for measurability gradually crowds out the upstream investment that makes demand generation work in the first place.

The inbound hand-raiser cohort

There is an analysis you can run with data you already have that makes the invisible visible.

Go back through 12 months of closed-won deals. For each one, find the answer to a single question in AE notes or discovery call recordings: how did this prospect first hear about the company? Not what campaign converted them. Not what touchpoint is logged in the CRM. What was their actual account of first awareness.

Segment the results into three groups. Hand-raisers: prospects who sought out the company themselves, through search, referral, direct navigation, or inbound inquiry. Campaign-sourced: prospects who responded to a specific marketing program. Outbound-sourced: prospects who entered the funnel through an AE or SDR sequence.

Then calculate three numbers for each group. Conversion rate from first touch to close. Average days to close. Win rate against known competition.

The differential between the hand-raiser cohort and the other two is almost always significant. These are buyers who arrived already familiar, already somewhat sold on the category, often already convinced the vendor was worth evaluating. They require less education, fewer touches, less convincing of the basics. They close faster and win more often.

That differential is the brand ROI number. It does not come from a brand attribution platform. It comes from a field in the CRM and a quarter of AE notes. Once you have calculated it, you have a conversion rate premium you can show the CRO in the same format as any other pipeline quality metric.

Make this cohort a permanent fixture in your pipeline reporting. Add a source value called “inbound hand-raiser.” Train AEs to assign it when a prospect had clear prior awareness at the start of the first call. Track the cohort’s size as a percentage of total qualified pipeline, and its performance metrics, in every monthly business review. When that percentage drops, something upstream is weakening. You now have an early indicator rather than a lagging one.

Four metrics that belong in your pipeline review

The hand-raiser cohort is one instrument. Four more give you a fuller picture of what is forming upstream of the CRM.

Direct traffic share. Visitors who arrive without a referral source typed your URL or had it bookmarked. They came looking for you specifically. A rising direct traffic share over time reflects awareness that paid acquisition and organic search do not explain. Pull this from your web analytics monthly and trend it over rolling quarters. A declining trend, especially against a backdrop of flat or rising overall traffic, tells you brand is weakening even while other channels are holding.

Branded search volume. Available in Google Search Console at no cost. A rising trend in searches for your company name means more people are looking for you by name, not just finding you through category keywords. A declining trend is a leading indicator that shows up in pipeline data six to nine months later. This is one of the few brand metrics with a credible lag relationship to revenue.

“Already knew us” discovery call rate. One field, populated by AEs after every first call: did the prospect mention prior awareness of the company before the AE made any introduction? Track the percentage of first calls where this is true, and trend it monthly. This requires no tooling. It does require making it a consistent habit in the AE workflow, which means it lives in your call review checklist and your CRM as a required field on the first activity.

Win rate by source cohort. Segment your wins by how the prospect first entered the funnel. Deals where the buyer named you on call one. Deals where you were added to an existing shortlist mid-process. Deals sourced entirely from outbound sequences. These three groups behave differently. The win rate differential between them is the most direct signal you have of how brand presence is affecting revenue outcomes.

None of these metrics are perfect. Each one captures a directional signal. Taken together, across 12 months of data, they give you a view of what is happening upstream of the funnel that your current pipeline review cannot produce.

Setting thresholds that actually drive decisions

Metrics that live only in a monthly slide deck do not change decisions. They get noted, they move on. The mechanism that converts a metric into a decision is a threshold: a defined floor or ceiling, agreed in advance, that triggers a specific conversation when crossed.

Here is how to set them for the four metrics above.

Inbound hand-raiser percentage. Run your 12-month cohort analysis first. Calculate what percentage of qualified pipeline came from hand-raisers over that period. Use that number as your baseline. Set a floor at 80% of the baseline. If the trailing quarter drops below that floor, the question of upstream investment goes to the leadership agenda that month, not the marketing agenda.

Direct traffic share. Calculate a 12-month rolling average. Set an alert threshold at a 15% quarter-over-quarter decline. This is not a marketing metric at that point. It belongs in the pipeline coverage discussion alongside bookings pacing.

Branded search volume. Two consecutive months of decline below the 12-month rolling average triggers a review. One month is noise. Two months is a trend. Your SEO team or marketing ops person can set this as an automated alert in Google Search Console.

“Already knew us” rate. Establish a baseline from the first 60 days of tracking. Set a floor. When the rate drops below it for two consecutive months, include it as a data point in the next pipeline generation review, not as a standalone marketing discussion.

The owner of these thresholds matters as much as the thresholds themselves. These are not owned by marketing. They are owned by whoever runs the operating rhythm: RevOps, the CRO, or the revenue leadership team. Thresholds without a named owner and a defined escalation path are decoration.

These thresholds are leading indicators. They fire before the pipeline impact is visible in coverage ratios. That is the point. By the time quarterly coverage looks thin, the quarter is often already too difficult to recover. The value of measuring upstream is that you get more time to respond.

What to do before your next pipeline review

Three additions to your existing operating rhythm, none of which require new software.

Pull the last 12 months of closed-won deals and build the hand-raiser cohort analysis. Export the list, work through AE notes or Gong recordings for each deal, and segment. Calculate conversion rate, cycle time, and win rate for each cohort. This is an analysis that takes a few hours and produces the baseline you need to make the case for upstream investment in the format your CRO already uses.

Add direct traffic trend and branded search volume to your next monthly business review deck as standalone line items. Two charts, 12 months of data each, one slide. Put them in the pipeline section, not the marketing section. That placement signals that these are revenue metrics, not brand vanity metrics.

Add a required field to your first-call activity record in the CRM: prior awareness, yes or no. Brief AEs on why it matters. Give it 60 days to generate a baseline. After 60 days you have a metric. After six months you have a trend.

The pipeline review you are running today is showing you the deals that are already in the system. These three additions show you the conditions that determine whether deals enter the system at all. Both views belong in the same conversation.

Paid members: the download below includes a Pipeline Measurement Audit workbook with the handraiser cohort calculator pre-built, the four brand proxy metrics set up as a 12-month trend tracker, threshold fields with ownership assignments, and a first-call activity field template for your CRM. Download it, enter your data, and you have the baseline analysis complete.

Read more

Here’s the conversations I keep getting pulled into:

• Sales leadership asks whether two open SDR seats really need backfilling.

• Finance asks why outbound headcount keeps climbing while reply rates don’t.

You give an answer. You’re not sure it’s the right one.

This post is a sponsored deep dive with 11x. The framework here is mine, pulled from RevOps conversations I’m having every week, and the perspective on what’s actually shipping at the enterprise level came out of a long conversation with their CEO Prabhav Jain.

I’ve been there. Multiple times. The last time was at a startup where leadership set the new fiscal year’s target at 275% of the previous year. By June we were pacing at 30%. Half the year done. Less than a third of the way there.

I pulled the fire 🚨 alarm.

Different problem, same shape. When the math underneath the SDR motion stops working, RevOps gets the call. Right now, the math is shifting again.

What I’m actually seeing

Pull an SDR’s calendar from a year ago. Put it next to last week. List building. Contact enrichment. First-touch emails. Follow-up cadences. Inbound triage. A year ago, that filled most of the week.

Now? A real chunk of it runs somewhere else.

The hallway feeling matches the data, but I’d encourage you to pull your own numbers before you take anyone else’s at face value. I’ve seen too many AI SDR pitches built on suspiciously clean industry benchmarks. Look at your own funnel. Compare Q1 to Q4 of last year. Compare per-rep volume now to twelve months ago. Compare your reply rates by segment. The story will tell itself.

When I do that exercise with operator friends, the same pattern keeps showing up:

• Per-rep outbound volume is up. A lot.

• Reply rates are down or flat. The volume isn’t translating one-to-one.

• Junior SDR seats are getting harder to justify. Senior SDR and account specialist seats are getting easier.

• New roles are showing up that didn’t exist 18 months ago. GTM Engineer. Pipeline Operations Analyst. RevOps Architect.

The question underneath the headcount question is this. What should the human revenue team look like once the execution layer can run on its own?

That’s what I want to work through. Four functions I see emerging, an honest read on whether your org should move this quarter or wait, and a 90-day plan if the answer is yes.

The execution layer is becoming infrastructure

Let me give the current model its due. Two SDRs. A solid cadence tool. A clean ICP. A manager running call reviews. That machine generated real pipeline for a decade. A lot of us got promoted on the back of it.

Nothing here is a claim the model was wrong.

What’s changed sits underneath the model. The cost of the execution layer.

Think back to when marketing teams adopted marketing automation around 2014. The repetitive send-and-nurture work stopped being headcount. It became infrastructure. You stopped counting it in heads and started counting it in throughput.

11x’s take on this is more specific than most. They’re not trying to be a better cadence tool. They’re trying to rebuild the execution layer from scratch, with the building blocks each owned by an agent. Lead finding, enrichment, scoring, research, message writing, CRM integration. Across phone, email, chat, SMS, even WhatsApp. The pitch isn’t to “replace your SDR,” it’s “give your team an orchestration layer that didn’t exist before.”

Whether that pitch holds at scale is something each operator has to test. But the framing matters. It’s the difference between buying a tool and adopting infrastructure.

Same move. Sales development now.

Here’s the mechanic. When the execution layer runs as infrastructure, the marginal cost of one more touch drops close to zero. 11x is one of the few I’ve seen actually shipping this at enterprise scale, with customers like Xerox, Sage, and Checkr running it in production. The math underneath outbound changes.

A few caveats I want on the table before we go further, because I’ve watched too many operators get burned by skipping these.

One. Fully autonomous AI SDRs have not replaced human teams at any scale I’ve seen. The deployments that actually work keep humans in the loop. The ones that pulled humans out entirely mostly got canceled. The vendors who pretend otherwise are lying to you.

Two. Vendors like 11x have caught up to this. Prabhav, CEO at 11x, put it to me like this: “AI didn’t take their job, it took the worst parts of it.” That framing matters because it sets the right expectation. Their outbound worker Alice runs the execution layer. Their inbound worker Julian handles voice and chat qualification. The humans run the parts that need humans.

Three. The conversation about AI SDRs gets framed wrong almost every time. People ask “what’s the reply rate” when the real question is “what does this unlock that I couldn’t do before.” AI SDRs or AI inbound sales agents (e.g. 11x’s Alice and Julian) handle outbound execution end to end and inbound qualification across every channel. The win isn’t a better email, but rather coverage your team couldn’t build any other way.

Here’s the reframe I’d offer.

We’ve long treated pipeline generation as a headcount problem. Reasonable instinct. It’s how the job worked. But what if it’s closer to the data warehouse now? Something you architect, staff thinly, and measure?

That reframe changes which humans we actually need above it.

Four functions emerging from one role

If the execution layer becomes infrastructure, the human work above it sorts into four jobs. Let me list them, then we’ll pressure-test each.

1. Pipeline architecture and orchestration

2. High-stakes account ownership

3. Inbound conversion and edge-case handling

4. Pipeline quality and feedback-loop ownership

Two notes before we dig in. These are functions, not titles. Most teams running this redesign today fold two of them into a single role, and grow into the rest. And plenty of teams keep the SDR title and just change what sits behind it. The functional split holds up better than any title taxonomy you’ll see on LinkedIn this quarter.

Pipeline architecture and orchestration

This function designs the system that produces pipeline. It owns the orchestration layer. Data sources, intent signals, AI agents, CRM, the wiring between them. It does not run a floor of SDRs.

There are fewer SDRs to run.

The titles vary. GTM Engineer. RevOps Architect. Pipeline Systems Manager. The work is system design.

The skill profile leans technical. SQL. A no-code workflow tool, or light Python. Deep CRM fluency. Signal taxonomy. Enough prompt literacy to direct an agent. Deliverability fundamentals.

Most people doing this came from RevOps, marketing ops, or sales engineering. Some came from an SDR seat. Specifically the ones who were already drifting toward systems and away from the dialer.

Comp lands in senior IC or first-line manager bands. Often comparable to a senior AE, without the swing.

One thing to watch. It’s tempting to slot your best SDR manager here and call it done. They earned the look. The work is genuinely different though. An SDR manager coaches humans through pipeline reviews. This function diagnoses why segment three of the ICP stopped converting and rewrites the targeting logic. Different muscle.

High-stakes account ownership

Here’s the part of the human SDR job that holds up well. Account ownership at low volume and high specificity.

A small set of named accounts. Three per rep. Sometimes ten. Rarely more.

Real research. Multithreading. Reading a buying committee.

The seat looks closer to a junior AE than a senior SDR. Senior tier roles I’m seeing posted increasingly carry titles like Strategic Account Development or Named Account ADR, with small account loads and AE shadowing built into the ramp.

The skill profile is sales. Account research. Executive conversation. Deal psychology. Light technical depth depending on the category. The human still owns this because no current AI agent reads committee politics well.

Comp shifts toward higher base, lighter commission, faster path to AE. Some teams skip the SDR-to-AE jump entirely and hire straight into a hybrid junior AE role.

One thing to watch. The instinct is to make this the reward seat for your longest-tenured SDR. Filter for strategic instinct instead. Years in seat won’t tell you who has it. A great list builder is not automatically a great account owner.

Inbound conversion and edge-case handling

Speed-to-lead used to be the whole inbound game. We built rotations and SLAs around it. That work mattered. It moved real numbers.

The bottleneck has shifted.

Voice agents now call inbound leads instantly. 11x’s inbound worker Julian has twenty-second response time across phone, chat, SMS, WhatsApp, and email. The system adapts to whichever channel the prospect actually engages on. Since speed is handled at the infrastructure layer, what’s left is the conversation itself. The human seat doesn’t go away and instead moves to the conversations the agent decided needed judgment.

This function owns the handoff moment. The ninety seconds after a prospect picks up. Read the energy. Find the unstated need. Book or advance the next step. It also takes the conversations the agent flagged as messy. Compliance-heavy deals. Multi-product cross-sell. Anything off-script.

The skill profile is discovery instinct and fast pattern matching. Comfort reading a conversation that arrived as a transcript or chat log. Most people here came from senior SDR or junior AE seats.

One misread to flag. This is not a queue worker watching dashboards. Most inbound volume clears before a human sees it. Every conversation that does reach the human is one the agent already decided needs judgment.

The stakes per conversation go up.

Pipeline quality and feedback-loop ownership

This function exists because of volume. An agent books 40 meetings a month. 12 convert. Someone has to own the other 28. Find the pattern. Feed it back into the system.

Half analyst, half coach.

The role wasn’t viable before because the volume wasn’t there to do statistics on.

What the function does, plainly. Audits agent output for false positives. Finds the ICP segments where the agent is missing and adjusts targeting. Watches for messaging drift. The slow slide to generic tone when a self-learning loop optimizes reply rate over reply quality. Runs sequence and persona tests. Owns the loop between sales and whoever configures the agent.

The skill profile. Comfortable in data, opinionated about copy, mechanical about funnel diagnosis. Often a RevOps or marketing ops background. Or the SDR who always liked the analytics more than the calls.

Comp lands at senior IC. Sometimes a management track. Sits in RevOps, or in a new AI operations group some companies are standing up to oversee agents across sales, marketing, and CS.

One misread here too. People hear “quality” and picture a QA reviewer. This role looks forward. The job is making the system better. Writing up yesterday’s misses is a small part of it.

Five gates to clear before we redesign anything

Before we take any of this to sales leadership, we owe ourselves an honest check. This redesign isn’t a gradient you slide along. There are gates.

Miss one and the productivity unlock doesn’t show up. You lose the SDRs you had. You pay for an agent that misses. That’s a worse spot than where you started.

Gate 1. Data quality. A CRM full of stale contacts and mismapped accounts breaks any agent. Garbage in, garbage out. Same rule we’ve had since SugarCRM. The agent writes to the wrong people at the wrong companies with the wrong context. Quick test. Can you name the percentage of your top 500 accounts with clean primary contact data? If you can’t, that’s the read I’d bring to leadership. We’re not ready yet.

Gate 2. Deliverability. Volume capacity means nothing if your domains get flagged. Teams running AI SDR seriously run mailbox infrastructure too. Warm pools. Rotating domains. Per-inbox throttling. A single domain handling both CS notifications and outbound lands you in spam before it lands a meeting. This line item gets forgotten in the budget. Don’t let it.

Gate 3. ICP clarity. Agents underperform hard on ICPs with high persona variance. “Decision makers at architecture firms” is not an ICP. It’s a wish. A one-paragraph ICP with three personas is ready. “Anyone who might need our software” is not.

Gate 4. Volume. The four-function split needs scale to make sense. An agent booking eight meetings a month doesn’t need a quality lead. You should be sitting in those eight meetings yourself. The split earns its keep once the patterns are statistically real. Most operators I’ve compared notes with put the line around 80 to 100 meetings a month from AI and human pods combined.

Gate 5. Motion type. This is the gate people miss. The split fits outbound-heavy and inbound-heavy mid-market and enterprise motions. It fits awkwardly on PLG-led motions, where the real work starts after a user is already inside the product. It also fits awkwardly on high-ACV, low-volume enterprise, where an agent’s marginal contribution is small next to the AE’s relationship work. A mostly product-led motion with light sales assist needs a different redesign. Roles built around activation and expansion.

Honest scoring, the way I’d do it for myself.

• Fail one gate. That’s a quarter of work.

• Fail two. That’s closer to a year.

• Fail three. This isn’t an SDR redesign conversation. It’s a RevOps foundations conversation, and the AI SDR pitch is pulling focus from the real one.

Where to start: a 90-day plan

When we bring this to leadership, the first move surprises people. The first move is an audit. The hiring comes later.

Days 1 to 30. Data and ICP. Pull a sample of your top 500 accounts. Score them on completeness. Contact, role, email validity, recent activity. If fewer than 80% pass, freeze the AI SDR conversation until the foundation is fixed.

In parallel, rewrite the ICP. Three paragraphs. Three personas. Named triggers. Named disqualifiers. Most teams fail this on the first try. That failure is useful information. Don’t paper over it.

Days 31 to 60. A constrained pilot. One ICP segment. One channel. One persona. Set baselines first. Meeting volume in that segment last quarter. Conversion to opportunity. Cost per opportunity. If you can’t answer those cleanly, pause and answer them.

The pilot has one job. Show what your team can actually operate.

Days 61 to 90. Hire the quality function first. Of the four, pipeline quality is the cheapest to stand up and the fastest to pay back. One senior IC. Audits agent output, diagnoses ICP fit, owns the feedback loop with whoever configures the agent.

On most teams I’ve watched run this, the hire covers itself inside a quarter.

Architecture, account ownership, and inbound conversion come after. In that order. As volume and infrastructure mature.

One more piece. The hard one.

The conversation with the SDR team you have today. The technology and the hiring are the easy parts. Sitting down with your reps is not. The honest version sounds like this.

Some of you move into the new functions. Most of you need new skills to get there. A few of you move up into junior AE seats. A few of you will leave.

That’s heavy. The instinct is to defer it. Deferring it just turns it into attrition and surprise, which is the worst version for everyone in the room.

The teams that handle this well start early, say it straight, and put real skilling paths in front of the people who want them.

That’s the advice I’d give my own sales leadership. It’s the advice worth carrying into yours.

Bringing it back

Let’s return to where we started. Two open SDR seats. A question you couldn’t fully answer.

Here’s where I’ve landed. I’d genuinely like to hear if you see it differently.

The seat is becoming four seats. Most of them won’t carry the SDR title.

Nobody has to make all four hires this year. Most teams won’t. The realistic path is one role that folds two functions together, usually starting with quality, then growing into the rest as the volume justifies it.

We don’t need this solved by Q3.

What we can do now. Run the audit. Get honest about the five gates. Walk into the next planning conversation with a real read instead of a guess.

That’s a strong place for RevOps to be standing. We’ve done the harder version of this before. Every time the GTM stack shifted under us. We can do this one too.

If you run the data audit this month, tell me what you find.

I’ll be running mine.

If you want help mapping any of this to your own GTM motion, the 11x team is open to that conversation. Tell them the RevOps Impact Newsletter sent you.

A brief note on the example used throughout. The RevOps leader in the 201 article, Marcus Webb at Vantyx, is a constructed example. The context file, skill, and agent configurations shown below follow the same structure, using the same field names and business logic Marcus built in 201.

We’re moving to Shell/Terminal!

The 201 article lived in claude.ai web and desktop. For this article we’re shifting to Claude Code, Anthropic’s terminal-based agent environment. Claude Code runs across terminal, VS Code, JetBrains, desktop app, and a browser-based IDE. For the agent workflows covered here, terminal is the primary surface. The browser-based IDE at claude.ai/code supports some agentic capabilities, but background sessions, subagent configurations, and scheduled autonomous execution are terminal-native.

If you have not installed Claude Code yet, Anthropic’s documentation covers the setup: docs.anthropic.com/claude-code. It’s a fifteen minute install. Once Claude Code is running, every build step in this article is natural language. You will not be writing configuration syntax by hand. You will be telling Claude what you want and letting it build the files.

Your 201 work is already the spec

Use the context and skills from the paid template in the last article as the prereq for your agent buildout.

The context file you filled out was not just for claude.ai Projects. The business layer, ICP definitions, deal stage field names, filter logic, team roster with CRM owner IDs, and output standards you wrote in that document are the exact information an agent needs to do its job autonomously.

In Claude Code, the context file becomes a CLAUDE.md: a plain text document that lives in your project directory and loads automatically at the start of every session. Moving your 201 context file into that format requires no manual work. Open Claude Code and tell it this:

Paste your filled out document. Claude generates the CLAUDE.md. That’s it!

The skill file you built in 201, specifically the weekly deal review with its HubSpot field references, Red/Yellow/Green scoring logic, and three-section output format, becomes the foundation for your first subagent. A subagent in Claude Code is a reusable configuration: a YAML file that defines what the agent does, which model it uses, and what tools it can access. You do not write the YAML yourself. Tell Claude this:

Claude generates the configuration. The MCP connections you set up in 201 carry over directly. HubSpot, Fireflies, Slack, Apollo: the connections the agent needs already exist. You are not rebuilding anything. You are wiring up what you already have.

The three agent types

Claude Code has three agent modes worth understanding for a GTM operator. Each maps to a different task type and a different level of oversight.

Background sessions are persistent processes that run independently of whether you have a terminal open. Close your laptop and the agent keeps working. For a RevOps leader, this is the right architecture for scheduled recurring tasks: the Monday pipeline review, the nightly CRM hygiene scan, the Thursday WBR prep. The task runs on its schedule, posts its output to Slack, and waits for the next trigger. No human involvement required unless the output flags something that needs attention.

Subagents are reusable configurations with a specific scope: a defined system prompt, a specific model, and a specific set of tool permissions. A deal scoring subagent with read-only HubSpot access cannot accidentally update a deal stage. A prospecting subagent scoped to Apollo and HubSpot cannot touch Fireflies transcripts from unrelated accounts. Scoping permissions per subagent is both a governance decision and a cost control mechanism. An agent running on Haiku for a simple field check costs a fraction of one running on Opus for complex reasoning. Most GTM agent tasks run well on Sonnet. Specify the model in your natural language prompt when you ask Claude to build the configuration and it will set the field correctly.

Agent teams are the third mode, where an orchestrator agent dispatches worker agents that each handle a specific part of a larger task. A full account research team might have one agent pull firmographic data from Apollo, a second check Fireflies for prior call history, and a third score the account against the ICP criteria in the CLAUDE.md. The orchestrator assembles the final output. The ICP definition from the 201 context file is what the scoring agent applies. Every agent in the team draws from the same CLAUDE.md rather than carrying its own copy of the business logic.

For most RevOps leaders building their first agents, background sessions running single-purpose subagents are where to start. Agent teams are powerful and also the most expensive and hardest to debug when something goes wrong.

Cost and governance

In claude.ai web and desktop, you are in the conversation and can see everything Claude is doing. In Claude Code with background sessions, agents run whether you are watching or not. A subagent checking HubSpot once a day and posting to Slack is cheap. An agent team running five parallel sessions against three MCP connections is a different cost category. Running ten parallel agents consumes your Pro, Max, or Enterprise token quota ten times faster.

The model selection layer is where you control this. When you generate subagent configurations in natural language, specify the model explicitly. Sonnet for scoring and reasoning tasks. Haiku for simple field lookups and data formatting. Opus only when a task genuinely requires the highest reasoning capability. Defaulting everything to Opus is an unnecessary cost that compounds fast with background sessions.

Governance matters more than most operators initially expect. The core question: what should an agent be allowed to write to your CRM versus read from it. A pipeline health agent that reads HubSpot and posts to Slack is low risk. If it produces an incorrect output, a human reads it, catches the error, and you refine the prompt. An agent that updates deal stages, marks deals closed, or sends emails on behalf of a rep carries a different risk profile entirely. The principle is start read-only. Add write permissions only after the agent has run correctly in read mode long enough to trust its scoring logic against your actual data.

When you generate subagent configurations in natural language, specify permission scope directly: “read-only access to HubSpot” and “write access to Slack” are the instructions Claude uses to set tool permissions in the YAML. You do not need to understand the configuration syntax to enforce the right boundaries. You just need to be explicit in the prompt.

The paid deliverable below includes a natural language agent brief for the MEDDICC scoring agent shown in the next section, with annotations mapping each part of the brief back to the 201 context file section that feeds it, plus briefer brief templates for the pipeline health check and nightly CRM hygiene agent.

Agents I recommend you build

Pipeline and forecasting

Weekly pipeline health check. Queries HubSpot for all open deals, applies the Red/Yellow/Green scoring from the context file, posts the three-section output to Slack before the Monday team call. This is the direct extension of the 201 deal review skill. Lowest lift, highest immediate value.

Pipeline coverage monitor. Runs daily as the quarter progresses, tracks coverage ratio against the target in the context file, posts a one-line alert to Slack if coverage drops below threshold. Simple logic, genuinely useful as a quarter gets tight.

Deal velocity tracker. Flags deals that have been sitting in a specific stage longer than the average days-in-stage benchmark from the context file. Catches stuck deals before they slip the quarter.

Forecast accuracy agent. Compares committed deals to close probability by stage, surfaces reps who are consistently sandbagging or overcommitting. Draws from HubSpot deal data and the stage definitions already in the context file.

CRM hygiene

Nightly data quality agent. Scans for missing required fields by stage, duplicate records, contacts with no associated company, and deals with no activity. Posts a daily hygiene score to Slack. The required fields by stage are already defined in the 201 context file system layer.

Deal completeness agent. More targeted than the full hygiene scan. Specifically checks that every deal in Stage 3 and above has the required fields populated before the weekly review. Runs Monday morning before the pipeline health agent so the health check does not flag fields that were actually just missing.

Call intelligence

Post-call MEDDICC scoring agent. Triggered by a new Fireflies transcript appearing for a deal in the pipeline. Pulls the transcript, scores against the MEDDICC criteria in the context file, identifies the specific gaps, and posts a coaching note to Slack tagged to the deal owner. Requires Fireflies MCP.

Weekly objection pattern agent. Runs Friday afternoon across all call transcripts from the week. Surfaces the three most common objections by deal stage. Useful for enablement work and for spotting messaging gaps.

Prospecting

Inbound ICP scoring agent. Runs nightly against new HubSpot contacts created that day. Scores each one against the ICP criteria in the context file. Marks high-fit contacts in HubSpot and posts a summary to Slack. Requires HubSpot MCP.

New account research agent. When an SDR books a discovery call and a new deal is created in HubSpot, the agent assembles an account brief: company overview from Apollo, any prior Fireflies call history, ICP fit score against the context file, known competitors. Posts to Slack before the call.

Retention and expansion

Churn risk agent. Weekly scan of accounts within 120 days of renewal. Checks HubSpot for health score, last activity date, NPS if tracked, open support tickets. Checks Fireflies for sentiment signals in recent calls. Posts a ranked risk list to Slack. Requires HubSpot and Fireflies MCP.

Renewal prep agent. Triggered 90 days before a contract renewal date. Assembles a full account brief: ARR, expansion history, champion engagement, open issues, competitive exposure from recent calls. Posts to the CSM and AE assigned to the account.

Reporting

WBR prep agent. Runs Thursday evening. Pulls the week’s pipeline movement from HubSpot, applies the fiscal quarter context and coverage target from the context file, and assembles the narrative arc for Friday’s revenue review. Posts a draft to Slack for the RevOps leader to review before the meeting.

Building the MEDDICC scoring agent

Read more

The typical pattern is querying Claude the way you would query a smarter Google, except with better follow-up questions. One session, one task, no persistent context. The output is only as good as what you explained in that window. Close the tab and everything resets. Open a new conversation and start over.

The 201 move is different. It is building a configured working environment that Claude inhabits whenever you start a conversation. That environment has three layers: a context file that tells Claude what it needs to know about your business, skills that encode how you want recurring tasks executed, and MCP connections that give Claude live access to your tools. Each layer compounds the others.

This is not a setup-once-and-forget configuration. It is a working environment you refine over time, and it gets materially better the more specific you make it. A generic setup produces generic output. A properly configured environment produces output you can send.

A new AI for GTM course starting next week. There’s still time to join.

Enroll

The three layers

To get Claude working for your GTM use cases I suggest setting up at least these three: Context, Skills, and MCPs. These are specific to the Claude ecosystem.

Think of it this way. Context files are what Claude knows. Skills are what Claude does. MCPs are what Claude can reach. Operate with all three configured and Claude functions less like a smart text generator and more like a second operator who already knows your business.

Most GTM operators building with Claude today have partial versions of all three. They have a Project with some documents uploaded, a handful of prompts they reuse, and maybe one or two connections active. The gap between that and a properly configured environment is not technical complexity. It is specificity. The question is not whether you have these layers. It is whether what you have built is specific enough to be useful at the task level.

Before going deeper on each layer, it is worth being precise about which Claude product you are working in, because the mechanics differ enough to matter.

In claude.ai, the web and desktop app, context files live as Project Knowledge: documents you upload inside a Claude Project that persist across every conversation in that project. Skills are cloud-synced files you configure once in Settings and that are available across all your projects on any device. MCP connections are OAuth-based connectors you activate in your account settings, covering the tools covered later in this article. This is the surface this article is written for, and it requires no technical setup beyond logging in and configuring your project.

Claude Code, the command-line tool, works differently on all three layers. The context file equivalent is a CLAUDE.md file that lives in your project directory and loads automatically at the start of every session. Skills are local SKILL.md files stored in a .claude/skills/ folder, and they can include executable scripts that run against live data rather than just instructions. MCP connections are configured via a command-line setup and can include locally hosted servers that do not require an official OAuth connector. Claude Code is considerably more powerful for operators who are comfortable working in a terminal and want to build custom automations, but it carries a steeper ramp. The Maven GTM AI course covers Claude Code in its own dedicated module, including how to build the CLAUDE.md, skill library, and MCP stack from scratch for a RevOps workflow.

The desktop app sits in between. It inherits the same cloud-synced Projects, Skills, and MCP connectors as the web app, but it can also connect to locally hosted MCP servers that are not yet available as official OAuth connectors. For operators who want to connect a tool like a custom data warehouse or an internal API, the desktop app is the path in without going all the way to Claude Code.

For the rest of this article, web and desktop are interchangeable. Everything that follows applies to both

The context file

The context file is the foundation. For claude.ai users, this lives as Project Knowledge: documents you upload to a Claude Project that persist across every conversation in that project.

Most operators write one document and call it done. They describe their company, sketch their ICP, maybe note their sales methodology. That is a start, but it is missing a layer that determines whether Claude can actually execute work rather than just understand it. The business layer tells Claude what things mean. The system layer tells Claude where to find them and what they are called in the tools it will connect to.

Let’s take a real example but I will mask the operator and the company. Let’s call him Marcus Webb, Director of Revenue Operations at Vantyx (fictitious company), a contract intelligence platform targeting mid-market legal and finance buyers. His context file covers both areas.

The business layer captures everything Claude needs to reason about his world. His ICP includes firmographic specifics: 250 to 2,500 employees, B2B focused, at least one dedicated legal or contracts function, more than 500 active contracts as a strong fit signal. It also includes behavioral signals that indicate real intent: companies coming off a failed CLM implementation, companies where the CRO has a board-level mandate on revenue predictability, companies that have recently closed a large enterprise deal and are now managing contract volume manually. His MEDDICC definitions are Vantyx-specific. Metrics anchors to a concrete claim: average customers reduce contract cycle time from 18 days to 6 days and recover 8 to 12 percent of ARR in year one from missed renewals. His deal stage definitions specify what required fields must be populated at each stage for a deal to be considered complete for pipeline review purposes. His output standards tell Claude exactly how to write for his VP of Sales: direct, data-first, no hedging, finding then implication then action.

The system layer is what most operators skip, and it is the difference between a context file that helps Claude think and one that helps Claude act.

This is where Marcus documents how his mental model maps to his actual CRM. Stage 3 in his language is Evaluation. In HubSpot, that is the field dealstage with value evaluationqualified. Required fields at that stage are amount, closedate, champion_name, competitor, and demo_completed. A stale deal is defined as last_activity_date more than 21 days ago on any deal not marked closedwon or closedlost. His three AEs are named with their HubSpot owner IDs so that “pull the Commercial pipeline” becomes an executable query. Custom properties like contract_volume and security_review_status are defined with their field names and the values that signal risk.

The reason this matters becomes clear the moment Claude has an MCP connection to HubSpot. Without the system layer, Claude can discuss pipeline risk intelligently but cannot pull the actual deals that meet Marcus’s criteria. With it, Claude queries live data, applies his definitions, and returns results already filtered and labeled in the terms he uses with his team.

The guiding principle for what belongs in a context file: include everything that is universally true about your business and nothing that is task-specific. Workflow steps, output templates, and step-by-step instructions do not belong here. They belong in skills!

Skills

A skill is a reusable task instruction you build once and invoke consistently. The difference between a skill and a prompt is persistence and reliability. A prompt disappears at the end of a session and produces different output depending on how you phrased it that day. A skill runs the same way every time, references your context file automatically, and can be triggered either by name or by Claude recognizing that it matches your request.

For Marcus, the most valuable skill is his weekly deal review. The skill specifies the exact HubSpot fields to pull, the precise criteria that make a deal Red, Yellow, or Green (not general risk language but specific logic: “dealstage is proposalmade or later and economic buyer has not been documented in deal notes”), the required fields by stage, and the output format in three named sections. Section 1 is a two to three sentence headline summary including pipeline coverage against the 3.5x target. Section 2 is a paragraph for every flagged deal, leading with ACV and close date, naming the specific MEDDICC gap, and closing with a single concrete recommended action. Section 3 is a brief listing of clean deals. The skill knows it is writing for Dana Flores, his VP of Sales, and calibrates tone accordingly.

The most important element of any skill is the description. Claude uses the description to decide whether to invoke the skill at all. A vague description like “review deals and flag risk” will misfire. A description that names the specific trigger conditions, the data it pulls, and the intended output produces reliable invocations across different ways of asking for the same work.

Skills get their own dedicated module in my Maven GTM AI course, including how to build them from scratch, how to validate they are doing what you intended, and how to structure a library that compounds over time. For this article, the principle to carry forward is this: if you are writing a skill that could apply to any company, you have not written a specific enough skill. Every data source, every scoring rule, every output instruction should reflect your business, your CRM schema, and the person reading the result.

MCPs for GTM operators

An MCP connection is what gives Claude live access to your tools rather than relying on what you paste into the conversation. In claude.ai, these are called connectors, and most of the ones that matter for GTM operators are available today via OAuth with no technical setup required.

The tools worth connecting now. HubSpot gives Claude read and write access to your full CRM: contacts, companies, deals, engagement history, and custom properties. Attio provides over 30 tools covering records, lists, notes, tasks, and meetings, with read operations auto-approved and write operations requiring confirmation before firing. Apollo gives Claude access to a 230 million-plus contact database and can search, enrich, create records, and add prospects to sequences inside a single conversation. Fireflies connects your meeting transcript library so Claude can surface objections, themes, and deal-level signals across any date range you specify. Slack lets Claude search messages and channels, which is underrated for surfacing deal context that never makes it into the CRM.

Two tools worth understanding before connecting. Clay.com launched as a connector in January 2026 and is read-only: Claude can query contacts and pull account details from data already enriched in your Clay workspace, but it cannot trigger Clay’s enrichment waterfall from inside a conversation. Enrichment still runs in Clay’s interface first. Gong announced MCP support in October 2025, initially focused on Salesforce and Microsoft Copilot rather than Claude. Community-built servers that access Gong’s API do exist, but there is no native OAuth connector in claude.ai today.

Two tools on the watch list. Salesforce’s hosted MCP server is in beta as of late 2025, enterprise-gated and built primarily around their Agentforce framework. Gong’s native Claude connector is coming but has not shipped. For both, the honest advice is to check again in two quarters.

One practical note: each active connector consumes context. Connect the tools relevant to the work you do in a specific project, not every tool you own.

The GTM context file starter kit below includes a pre-structured template for both the business and system layers, with annotated examples drawn from the Vantyx scenario above. Download, customize with your own ICP, CRM schema, and deal stage definitions, upload to a Claude Project, and you have a configured working environment in under thirty minutes.

Read more

The individual metrics we’ll cover are going to be familiar with you. What has changed is the relationship between them. A board that used to evaluate growth rate and call it a day now wants to understand how that growth is funded, what it costs at the margin level, how many people it requires, and whether the customer base is getting stickier or more fragile. Five metrics now carry the conversation: net revenue retention, burn multiple, ARR per FTE, gross margin trajectory, and Rule of 40 (or 60, depending on your operating model).

I’m teaching a new AI for GTM course starting next week. There’s still time to join.

Enroll

Each of these metrics existed before. The difference is how they’re weighted, what the targets look like, and how boards are using them together to read the health of a revenue organization.

Net revenue retention: the north star metric

Net revenue retention measures what your revenue would look like if you never signed another new customer. Every company already tracks it. What shifted is how central it’s become to board level evaluation.

The Revenue Operations Alliance surveyed 35 CROs this year and found NRR named as the primary revenue efficiency metric by more than a quarter of respondents. It’s the single most cited north star metric heading into 2026. The reason for that elevation isn’t complicated. New logo acquisition has become harder, slower, and more expensive across the market. Revenue growth at public software companies dropped from 57% in 2023 to 27% in 2025.

What does good look like?

McKinsey’s analysis of over 100 B2B SaaS companies puts top quartile NRR at 113%. That’s the floor for a company that wants to be in the conversation about premium valuation. The same research shows a meaningful segment gap: enterprise accounts with ACV above $100K average 118%, mid-market runs at 108%, and SMB lands at 97%. If your customer mix skews downmarket, that context matters for how you present the number. A 105% NRR at a company that’s 80% SMB is a very different story from 105% at a company with large accounts, and boards sophisticated enough to ask about NRR are usually sophisticated enough to ask about the mix.

The outliers worth paying attention to are consumption based businesses. Snowflake reported 125% net revenue retention in Q4 of fiscal year 2026 on $4.68 billion in annual revenue. Datadog ran approximately 120% NRR on $3.43 billion in 2025 revenue. Both companies are consumption priced, meaning customers pay for what they use, with no fixed seat count. Expansion happens inside the product as usage grows, with no renewal negotiation required. Revenue scales automatically when customer workloads scale. That’s the structural advantage consumption pricing creates, and it’s reshaping what the expansion motion looks like operationally for companies that adopt it.

For SaaS Capital’s 2025 benchmarking research on bootstrapped companies at $3 million to $20 million ARR, the median NRR sits at 104%, with the 90th percentile at 118%. The companies getting to 115% or higher are almost always the ones who’ve built expansion mechanics into the product itself and don’t depend entirely on a sales led upsell motion to drive it.

One more thing worth flagging. A 100% NRR can mask a serious structural problem. A company churning 20% of its customer revenue annually and replacing it with 20% expansion is in a precarious position, even though the net number reads as neutral. The components matter as much as the aggregate. Boards that know what they’re looking at will ask about gross revenue retention alongside NRR. That’s a question worth getting ahead of in the board presentation.

Burn multiple: capital discipline becomes mandatory

Burn multiple measures how much cash a company burns to generate each dollar of net new ARR. David Sacks at Craft Ventures popularized the metric, and in 2026 it has become, for many investors, the primary screening metric for capital efficiency. In 2025, 56% of seed investors and 83% of Series C and later investors named it a critical evaluation metric. That’s up 31 percentage points from 2022.

The benchmarks by stage are now well established. Seed and pre-seed companies average 2.5x to 3.4x, which reflects the reality of building before product-market fit is confirmed. Series A median sits at 1.2x. Growth stage companies at $25 million to $50 million in ARR target 1.4x, with top performers running below 1.0x. At $100 million or more in ARR, the expectation moves to at or below 1.0x, and the best performing quartile at that scale maintains burn multiples below 0.8x.

The Series B mental model, as described by multiple investors this year, is worth understanding directly: a growth rate plus profitability margin above 40, paired with a burn multiple below 2x. Companies that don’t meet both conditions face meaningful fundraising friction, regardless of how the individual numbers look in isolation. Above 2.0x at any stage past Series A is worth surfacing before investors raise it.

AI native companies have a structural advantage here that shows up in the data consistently. Their burn multiples run 0.8x to 1.2x at growth stage, outperforming traditional SaaS at nearly every ARR band. The reason is architectural. Companies that build on AI from the start automate more of their product development, customer support, and operations from day one, which compresses operating costs without compressing revenue growth. A company that doesn’t need to hire a 15-person support team because AI handles tier one resolution is structurally different from one that builds the support headcount first and then adds an AI layer on top of it later.

The practical implication for revenue leaders is that burn multiple is increasingly being read in tandem with ARR growth rate. A company growing at 50% with a 1.0x burn multiple is a fundamentally different financial profile from one growing at 80% with a 3.0x burn multiple. Both have strong growth. One is generating durable, capital efficient revenue. The other is buying growth at a cost that compounds against the balance sheet. Boards that understand the metric can tell the difference.

ARR per FTE: the productivity pressure

ARR per FTE has existed as a metric for years, but it’s receiving more board attention in 2026 than at any prior point. The shift is partly a function of tighter capital markets and partly a function of AI native companies rewriting expectations for what’s possible.

The median private SaaS company generates approximately $130,000 in ARR per employee. That number has climbed since 2022 as companies have leaned out headcount while maintaining or growing revenue. High Alpha’s 2025 SaaS Benchmarks Report, drawing on data from over 800 companies, shows later stage businesses touching nearly $400,000 in ARR per employee, approaching the productivity levels historically associated with public companies. ICONIQ’s benchmarks put best in class at $350,000 for companies at $20 million to $50 million ARR and $400,000 for companies above $50 million.

Those numbers look different when you put the AI native outliers next to them. Cursor crossed $2 billion in annualized revenue in early 2026 with approximately 300 employees, putting ARR per FTE at roughly $6.7 million. Lovable reached $100 million in ARR in eight months with 45 people, approximately $2.2 million per employee. Gamma crossed $100 million ARR with about 50 employees, roughly $2 million per FTE. Shopify, operating at much larger scale, doubled its ARR over three years while cutting 30% of its workforce, tripling its ARR per employee to approximately $1.3 million. These are outliers and worth naming as outliers, but the existence of companies generating $1 million to $6 million per employee is reshaping what boards consider acceptable at the upper end of the performance range.

Bessemer’s data from the State of AI 2025 report puts the contrast between cohorts in stark terms. AI Supernova companies, the fastest growing cohort by their categorization, run approximately $1.13 million in ARR per FTE. Their Shooting Star cohort, which represents the more typical AI native benchmark at year one, runs $164,000. The gap shows how much the operating model is being restructured at the frontier.

The metric boards are actually tracking is the trajectory, not just the spot number. A company moving from $180,000 to $260,000 in ARR per FTE over two years is telling a fundamentally different story from one holding flat at $180,000 despite adding headcount. The direction matters because it shows whether AI tooling and process automation are compounding into the operating model or remaining as a surface level addition that doesn’t change productivity.

High Alpha’s research identified engineering as the function hit hardest by headcount reduction, with 42% of companies reporting cuts. Support and marketing followed. The underlying mechanic is consistent across all three: AI tooling is absorbing work that previously required human labor, which means the same output can be generated with a smaller team. The parallel question for revenue leaders is whether that pattern applies to the go-to-market motion itself. Companies that have restructured their GTM around agent assisted outbound, automated pipeline qualification, and AI assisted territory management are seeing ARR per quota carrying rep rise in the same way ARR per employee has risen company wide.

Gross margin trajectory: the newest boardroom conversation

Gross margin used to be a relatively stable number in the SaaS P&L. AI changed that. Every model call, every inference, every embedding generates a marginal cost that traditional SaaS didn’t carry. That cost lives in COGS. As AI features become central to products, the cumulative effect on gross margin has become material enough that boards are now treating it as a managed metric with its own trajectory, not a fixed assumption that gets handed to finance and forgotten.

ICONIQ’s 2026 State of AI report tracks gross margins for scaling stage AI B2B companies and shows a clear glide path: 41% in 2024, rising to 45% in 2025, and reaching an expected 52% in 2026. Bessemer’s Shooting Stars, the AI native cohort growing at Q2T3 trajectory, run approximately 60% gross margins after custom model development and refined pricing. Supernovas, the fastest growing cohort, operate at approximately 25%, trading gross profit for adoption and market share. Traditional SaaS benchmarks hold at 70% to 90%.

The inference cost component is the one most revenue leaders have underestimated. ICONIQ’s data puts inference at 23% of total revenue at scaling stage AI companies. Cloud Capital’s Q4 2025 CFO survey found that 89% of CFOs report rising compute costs negatively impacted gross margins over the prior 12 months. SaaStr Fund data shows a portfolio company at $100 million in ARR modeling $6 million in incremental inference costs for the next 12 months. The product isn’t broken. Staying competitive requires running more capable models that cost more to serve. The Mavvrik 2025 State of AI Cost Governance Report found that 84% of enterprises report AI infrastructure costs eroding gross margins by 6% or more.

The revenue implications for CROs are more direct than many realize. Gross margin determines how much room a company has to invest in sales and marketing, customer success, and R&D. A company operating at 52% gross margin has significantly less room per revenue dollar than one at 80%, even if both are growing at the same rate. That constraint shows up downstream in CAC payback calculations, in burn multiple, and in Rule of 40. Compression at the gross margin line compresses everything connected to it.

The SaaS CFO frames the diagnostic clearly: if you can’t answer what your AI gross margin is, you’re managing this blind. That’s where the board conversation has moved. A CRO who presents growth figures with no visibility into the compute cost structure connected to those figures is presenting an incomplete picture. The expectation, increasingly, is that revenue leaders understand the cost of serving customers at the AI layer and can speak to the pricing and packaging decisions that protect margin as usage scales.

The most visible operating challenge is pricing design. A single aggressive user running AI features at high volume can generate more compute cost in a month than typical users generate in a quarter. Consumption pricing addresses part of this by tying revenue to usage, but it introduces complexity in how NRR gets calculated and forecasted. Hybrid models that combine a subscription base with usage based components are showing the strongest results on both fronts. High Alpha’s 2025 data shows that 53% of SaaS companies still price AI via subscription, while hybrid models deliver the highest NRR. The companies that have built pricing mechanics to protect gross margin as AI usage scales are the ones whose gross margin trajectory shows improvement year over year.

Rule of 40 (or 60): the synthesis metric

Rule of 40 is the sum of a company’s revenue growth rate and its free cash flow margin. A score above 40 indicates a company is generating efficient growth relative to its cost of capital. It remains the standard benchmark for evaluating scaled SaaS businesses, and the IPO bar reflects that. Companies that went public or received favorable late stage marks in 2025 and 2026 typically cleared $100 million in ARR, growth above 30% year over year, NRR above 115%, gross margin above 72%, and Rule of 40 above 40.

Rule of 60 is emerging as a separate benchmark for AI native companies with a specific operating model. The arithmetic connecting it to the prior four metrics is worth walking through.

If a company operates at 80% gross margin, there’s substantial room to invest in operating expenses while maintaining positive free cash flow margin. At 55% gross margin, that room shrinks considerably. To hit Rule of 40 with a compressed gross margin, the FCF margin component starts from a lower base, which means the growth rate component has to carry more weight. Rule of 60 is what the math looks like when you combine the growth rates AI native companies are actually achieving with the leaner operating models and high ARR per FTE that make those growth rates possible without burning capital at unsustainable multiples.

High Alpha’s 2025 benchmark data shows the median Rule of 40 across all ARR bands sitting below 40%. Upper quartile companies are at or above 40% across every ARR band. The gap between median and upper quartile is where most of the competitive distance in a given market is created over time. For early stage companies, Rule of 40 performance is more forgiving. Past $50 million ARR, sitting below 40% consistently is worth diagnosing and addressing directly.

The practical framing for revenue leaders is that Rule of 40 (or 60) is the synthesis metric. It doesn’t stand alone. A high score built on strong growth and deeply compressed margins is a different business from the same score built on moderate growth and strong FCF. The board wants to understand which components are carrying the metric and how durable each component is.

Reading the scorecard as a system

The shift in how boards evaluate revenue leaders is as much about the systems level reading as it is about any individual metric. None of the five numbers tell the complete story in isolation. They tell the story in combination.

A strong NRR paired with a deteriorating burn multiple suggests the expansion motion is working but the cost structure is getting out of control. A clean burn multiple with weak NRR suggests capital discipline without retention quality. Strong ARR per FTE with declining gross margin suggests operational leverage is real but compute cost is eating into it. A high Rule of 40 score built entirely on growth with compressed FCF margin suggests the efficiency component will come under pressure as growth decelerates.

The Revenue Operations Alliance data identifies three pressure points consistently named by CROs as their biggest revenue cycle bottlenecks: lead-to-opportunity conversion, forecasting accuracy, and quote-to-cash speed. Each of these connects to the scorecard above. Slow lead-to-opportunity conversion puts more pressure on NRR to carry the growth narrative. Forecasting inaccuracy undermines burn multiple credibility when the board compares actuals to plan. Quote-to-cash friction slows expansion velocity, which is a direct input to NRR for accounts trying to grow their usage.

The board conversation in 2026 is rarely “what’s your Rule of 40.” It’s “walk us through the model.” That question has five inputs, and the revenue leader who can move fluently through all five, with targets, actuals, and the active management decisions that explain the gaps, is the one who owns the narrative.

Building the board narrative

Read more

That gap matters because the rep prepping for a renewal call on Tuesday morning doesn’t paste a customer’s MSA into ChatGPT because they haven’t read the policy. They paste it because the policy didn’t think about that moment.

Cursor learned this in public. In April 2025, the AI code editor’s own customer support bot invented a login policy that didn’t exist, telling paying users their Pro subscriptions were now limited to a single device. Customers cancelled, the story spread across Reddit and Hacker News in hours, and the cofounder spent a public thread apologizing and committing to label AI generated responses going forward. An AI company tripped on its own AI in front of the developer audience that was supposed to trust it most.

The pattern inside most companies is quieter. A signed contract pasted into a personal account. A discount threshold included in a prompt about pricing strategy. A Gong transcript run through a summarizer the customer never consented to.

A GTM AI policy is a different document than the company wide one Legal owns. It names the artifacts your team touches, the tools they use, and the moments where they reach for AI without thinking. Without all three pieces, the document fills a folder while reps make calls in the dark.

This is my attempt to put one together for you as a starting point!

If you’re feeling behind on this, you’re not alone. The regulatory floor is moving faster than most policies can keep up with, and my own playbooks on this may be rewritten in a year. The point isn’t to land on the perfect document. It’s to ship one your team can actually use.

Approved tools and the licensing question

The first decision in any GTM AI policy is which tools your team can use. Most policies stop at a list of names. The good ones name the account type too.

Citi runs the most visible version of the right model. The bank rolled out generative AI tools to roughly 175,000 employees across 11 countries, paired with a peer led network of more than 2,000 AI Champions who sit inside business units and help colleagues adopt the tools. They paired that grassroots network with mandatory prompt training and two firm approved tools, Citi Assist for policy and process queries and Citi Stylus for document summarization. The lesson for revenue teams isn’t the scale. It’s the structure. Sanctioned tools, peer led adoption, explicit data boundaries, and training that closes the gap between using the tool and using it well.

Moderna handled the licensing question by letting the people who would use the tool influence the choice. Before standardizing on ChatGPT Enterprise, they ran user testing across their internal mChat instance, Microsoft Copilot, and ChatGPT Enterprise. Net promoter score decided. Within two months of company wide rollout, employees had built 750 custom GPTs across the business. That outcome required them to license enough seats that experimentation was actually possible. A pilot of twenty seats wouldn’t have produced 750 GPTs.

Pfizer took a different path. Their internal generative AI platform, Charlie, was purpose built for marketing and sales content creation and review. Some companies will license, some will build, and a GTM policy needs to handle both. If your company is building, the policy says which workflows route through the internal tool and which still go to the licensed external one. If you’re licensing, the policy names the enterprise tier and the SSO requirement.

The non-negotiable rule across both patterns is the account type. Harmonic Security analyzed 22 million enterprise AI prompts and found that roughly 17% of sensitive data exposures happened through personal accounts of the same tools that existed at the enterprise tier. Same product. Same model. Different audit trail, different training defaults, different consequences. Your policy says the company sponsored account through SSO, every time, no exceptions. The personal Gmail login to chatgpt.com is a different tool with the same logo.

Where experimentation happens

A policy that bans without enabling produces shadow AI. A policy that enables without structure produces chaos. The way out is to define the spaces where experimentation happens, with different rules in each.

A sandbox is a low stakes environment for individual experimentation. The boundaries are structural rather than supervisory. Synthetic or scrubbed data only, internal only outputs, no customer facing artifacts, no review gate. A rep wants to test a new prospecting prompt against a fictional account profile. A CSM wants to see if Claude can summarize a sample call recording. A marketer wants to draft three subject line variants on a generic product. The sandbox lets that happen without anyone asking permission. The cost of being wrong is zero because nothing leaves the building.

A tiger team is the structured counterpart. It’s a chartered cross functional group, typically five to eight people drawn from SDRs, AEs, CSMs, marketing, and RevOps. They run approved experiments on real workflows, on a weekly cadence, with a documented graduation path. An experiment graduates when the team can show measurable lift, repeatable usage, and a workflow others could adopt. It retires when it can’t.

Snowflake ran this pattern visibly. Their internal GTM AI Assistant started narrow with a single data scientist, expanded to a pilot group, and reached general availability with weekly adoption reports shared with sales leadership. By the end of their first year, they reported north of 90% adoption across their primary GTM personas. Their engineering team’s reflection in writing was that the work turned out to be a product activation and change management problem more than a technical one.

Moderna’s 750 GPTs in two months tell the same story from a different angle. That outcome wasn’t accidental. They paired open access with a structured environment for sharing what worked, normalized AI experimentation as part of every role, and gave internal builders visible recognition.

The policy section that covers this is short. Here is the sandbox, here are the rules. Here is the tiger team, here is the charter. Here is how something graduates from sandbox curiosity to tiger team experiment to sanctioned workflow.

Data classification with GTM artifacts

Most data classification frameworks were built for a world where the classes were public, internal, confidential, and restricted, and the artifacts were spreadsheets and email attachments. The frame still works. The artifacts are different.

Public data is what you’d put on the website. Marketing copy after legal review, published case studies, the pricing tiers on your pricing page. Anything in this tier can flow into any sanctioned AI tool, including the consumer ones, without additional control. The risk is zero because the data is already public.

Internal data is what your team sees but customers don’t. Internal Slack threads, deal review notes, win loss summaries written for internal consumption, your sales playbook. This tier can flow into your enterprise sanctioned tools through SSO. It cannot go to a personal account. It cannot leave through a connector that hasn’t been approved.

Confidential data is where most GTM artifacts live. CRM records with named accounts and contacts, call transcripts and recordings, prospect emails, signed and unsigned MSAs, order forms, security questionnaire responses, ROI models, and pipeline reviews. This tier requires the enterprise tier of the AI tool, the company SSO, and additional rules about retention and connectors that the next section covers. Pasting this data into a personal account is the thing that gets you on a call with the GC.

Restricted data is the smallest tier and the highest stakes. Customer payment information, regulated data covered by HIPAA or PCI DSS, board level financials, competitive intelligence under NDA, and the most sensitive contract clauses. Restricted data does not touch generative AI tools without explicit approval from Legal and Security. The policy names a specific approval path. Email a designated alias, get a written response, log the use case.

The classification table belongs at the front of the policy, on a single page, with the actual artifacts named in plain language. Reps don’t read frameworks. They read tables. When the rep prepping for a renewal call asks themselves “can I paste this,” they should be able to find the answer in under thirty seconds.

Connected accounts and the connector caveat

The next layer is the connection itself. When a rep links Claude or ChatGPT to their email, calendar, or CRM, two rules have to be true.

The first is account identity. The connection runs on the company sponsored account, through SSO, every time. A personal Gmail login that happens to share a domain with the work account is the wrong configuration. The connection has to flow through the same SSO path that every other corporate tool uses, because that’s where the audit trail and the offboarding path live. When the rep leaves, IT revokes the SSO and the AI tool’s connection dies with it. A personal connection survives offboarding by definition, and the data it touched does too.

The second rule is inherited access control. If Salesforce enforces sharing rules so an AE only sees their own accounts, the AI connection has to respect that. If your CRM uses row level security or territory based visibility, the connection inherits those rules. The failure mode is connecting through a service account that runs as an admin and quietly exposes data the user couldn’t have queried directly. That’s a privilege escalation, with all the legal weight that label carries.

The connector caveat is harder and more important. Most connectors, including the ones built on the Model Context Protocol pattern, pull samples. They surface the most recent N records, or whatever a single API call returns, or what fits in the context window. They are excellent for “summarize this account,” “draft a follow up to this thread,” and “find the three most recent emails from this contact.” They are wrong for “score my territory by expansion potential,” “tell me which 50 accounts to prioritize this quarter,” and “forecast pipeline coverage for next quarter.”

The principle is straightforward. If the answer depends on having seen the full population, run the analysis against the warehouse, not through a connector. Connector AI is a retrieval tool. Population level decisions belong to structured queries, scored consistently, with the model seeing everything. Confusing the two is how revenue leaders make confident decisions on bad evidence.

Output authority and human review

A working policy distinguishes between what AI can draft and what AI can send. Drafting is open. Sending is gated.

The gate’s strictness scales with the audience. AI can draft an internal Slack message and the rep can send it without review. AI can draft an outbound prospect email and the rep should review it before sending, particularly for substantiation of any claim about your product or theirs. AI can draft contract language, and that draft does not leave the building until a human has read every word.

The reasoning is grounded in real failures. Air Canada’s customer service chatbot hallucinated a bereavement discount that didn’t exist in the airline’s published policy, and a Canadian tribunal forced the airline to honor what the chatbot promised. The court was unmoved by the argument that the chatbot was a separate entity. The company said it, the company owns it. The same logic applies when an AI drafted email goes out under your AE’s signature with a commitment your product can’t keep.

The Federal Trade Commission settled with Air AI Technologies in March 2026 for $18 million, with a ban on selling AI sales tools, applying the substantiation standard the agency has used in other enforcement contexts to AI capability claims. The lesson reaches further than AI vendors. Any claim your reps make in writing, AI assisted or otherwise, has to be substantiated. The fact that a model wrote it is no defense.

The policy language for this section is operational. For each major output type, name who has authority to send without review (internal communications), who needs a peer review (outbound to prospects), and who needs Legal review (contract language, security questionnaire responses, regulated data assertions). When in doubt, the rep escalates. A two hour delay in sending is cheaper than a chatbot promising a refund the company has to honor.

Recording, transcription, and embedded AI

Your first AI policy probably covered what employees put into AI tools. The second wave of risk comes from what AI tools take out of employees without anyone deliberately putting anything in.

A bot joins the meeting. The transcript runs in real time, summarizes the call, and stores the result on a vendor’s servers under terms IT may not have read. The conversation might have been a competitive deal review, an internal pricing escalation, or a candid discussion of a customer at risk. None of that was meant to live as a searchable permanent record outside the company’s perimeter.

The policy names approved transcription tools, the ones with enterprise contracts, data residency commitments, and zero day retention defaults. It also names a do not record list. Performance discussions, attorney client privileged conversations, internal pricing strategy sessions, deal escalation calls with Legal or Finance, and exec strategy sessions involving material non public information. The category exists because some conversations should never become a permanent searchable record.

The embedded AI question is the quieter version of the same problem. Salesforce Einstein, HubSpot Breeze, Gong AI, Outreach Smart Email Assist, and LinkedIn Sales Navigator AI all ship features that turn on by default in tools your team already uses. Your policy needs an explicit position on each. What’s allowed by default. What requires an opt-in flow. Which embedded features got reviewed by Security and which are running because the vendor pushed an update. The audit happens once a quarter and the answers go in a register.

Incident response and policy maintenance

Every GTM AI policy needs an answer to the question: “I think I just leaked something. What do I do?”

The answer fits on one page. There’s a designated alias or Slack channel that gets monitored. The rep messages it within 15 minutes of realizing what happened. The first response is triage. What was pasted, into which tool, on which account. The next step is preservation. Screenshot the conversation, pull the chat history if the tool allows it, log the timestamp. Then containment. Delete the conversation if deletion is real for that tool, revoke any active sessions, and rotate any credentials that may have been exposed.

The escalation path is short. RevOps logs the incident. Security reviews. Legal gets involved if the data was customer confidential or regulated. Raising it carries no penalty. The policy treats early disclosure as the right move regardless of what happened.

The maintenance cadence is quarterly at a minimum, faster when something material changes. New tool category in the stack. New regulation crossing into enforcement. Internal incident that revealed a gap. The review checklist runs through eight questions. Has the approved tools list changed? Have any vendors changed their training defaults? Have any embedded AI features been added to the existing stack? Have any team workflows graduated from tiger team to sanctioned? Has the data classification matrix added artifacts? Have any incidents revealed gaps? Have regulatory obligations shifted? Does the policy still fit on the pages reps will actually read?

What this is for

The point of all this is the rep on Tuesday morning. The MSA is in their downloads folder. The renewal call is at 11. They have an idea for a question Claude could answer if it could see the contract. The policy in their head is what decides what happens next. If that policy is twelve pages of legal language they read once during onboarding, the MSA goes in. If the policy is eight clear sections that named this exact moment, the rep pastes the redacted version into the sandbox, gets the answer, and walks into the call sharper than they were.

Sanction the work that’s already happening. Give experimentation a place. Make the rules legible. The rest follows.

Paid subs! A template with the full policy drafted, plus the data classification matrix, decision tree, sandbox and tiger team charter, incident response workflow, and quarterly review checklist. Change the company name and the approved tools list. Use it as a starting point to get a policy out the door.

Read more

But guess what! AI is moving SO QUICKLY that all of those recommendations are woefully outdated.

A meaningful share of my top recommendations changed.

• Five entirely new use cases entered the framework, including multi-agent workflows, computer use, real time call coaching, deep research, and knowledge retrieval.

• One provider’s input pricing went up 43%. Another dropped output costs 77%. A new budget tier model launched and reshaped the routing layer.

• The right answer for high volume data enrichment shifted from a Chinese provider to an American one for US teams with data residency requirements, and the cost lines for both options now sit close enough that the choice is a policy decision rather than an economic one.

Seventy five days and basically everything I recommended changed.

Insane pace for new product launches.

If you’re feeling behind on AI. Don’t worry. I do too!

The companies pulling ahead in GTM AI are the ones who built their architecture assuming this would happen. They abstracted model calls behind internal interfaces. They version controlled their prompts. They instrumented cost per workflow rather than per provider. They negotiated contract terms that preserved their ability to swap providers when the economics shifted, and the economics shifted.

Let’s talk about how to build that architecture, why economics has overtaken capability as the dominant variable in GTM AI deployment, and what flexibility actually looks like as an operational discipline.

GTM AI is in its experimentation era. Far too early for the deployment era

A deployment era is when you pick the right tool, install it, train people on it, and reap returns for years. A maturity era is when the technology is mostly settled and the value comes from proper implementation. AI in GTM is in neither. It is in an experimentation era, where capabilities are still being discovered, prices reset on a quarterly cadence, and what is best in class for a use case in March can be middle of the pack by June.

Klarna is the most public cautionary tale. In 2024, the company committed to AI for customer service, ended hiring across the function, and publicly announced its chatbot was doing the work of 700 humans. By spring 2025, CEO Sebastian Siemiatkowski was telling Bloomberg the company was rehiring because the AI approach had produced “lower quality” service and the cost optimization had compromised the customer experience. The pattern is documented across the broader market. Research from Orgvue and Forrester found that 55% of companies that executed AI driven layoffs regret the decision. Menlo Ventures’ enterprise research shows that only 16% of enterprise AI deployments qualify as true agents capable of planning, executing, and adapting.

This is what an experimentation era looks like. High variance in outcomes. Frequent reversals. Mature implementation patterns still emerging. No one has a comprehensive playbook because the underlying technology shifts faster than playbooks can be written.

I would know. I build AI systems for companies and am very open to my clients. My playbooks may be completely rewritten in a year. In fact, maybe even sooner than that! But the alternative of doing nothing is also not an answer. Because the counterfactual of your competitors gaining share over you will get you canned with the Board.

The implication for architecture is direct. An architecture optimized for experimentation looks different from one optimized for deployment. It assumes the model will change. It assumes the price will change. It assumes the prompt that works today will need to be retuned for the next generation of model. It separates the workflow logic from the model so that swapping providers is a configuration change rather than an engineering project. It instruments cost and quality at the workflow level so the team can detect drift and respond. It treats the provider as a vendor whose contract should be renegotiable rather than an architectural primitive baked into every line of integration code.

Architecture built for experimentation compounds the benefits of every model release, every price drop, and every new capability that lands. Each market shift becomes leverage on the existing stack rather than a tax that requires reopening last year’s decisions.

The three commitments of architecture for experimentation

Architecture for experimentation rests on three commitments. None of them are technically sophisticated. They are operationally sophisticated, which is the harder kind.

The first commitment is model abstraction. The workflow code should not call provider SDKs directly. It should call an internal interface that translates a generic request into whatever provider is currently configured for that workflow. The pattern is well established outside of GTM. Microsoft positions Azure AI Foundry as an open platform for orchestrating AI apps and agents with multiple models and frameworks. Vercel’s product strategy is built around helping teams swap providers without rewriting application code. Kong has positioned its API gateway product as the control plane for AI traffic, which is essentially the same pattern at the network layer rather than the application layer. The principle is consistent across all of them. Treat the model as a service that can be replaced without touching business logic. Inside RevOps, this matters because the most expensive part of model switching is rarely the API call itself. It is the prompt rewrites, the parameter retuning, the integration code, and the regression testing triggered when you change providers. Abstraction makes those costs scale with the number of workflows rather than the number of integrations.

An example: a lead scoring workflow built two ways.

Without abstraction, a typical setup looks like this. A Zap or n8n workflow fires when a new lead enters HubSpot. The workflow has an HTTP node that calls api.anthropic.com/v1/messages directly, with the Anthropic API key, model name claude-sonnet-4-6, and a payload formatted with Anthropic’s specific message structure (system prompt at top, content array, max_tokens parameter). The response parsing logic expects Anthropic’s response format. The same pattern is repeated in twelve other places across the stack: the BANT scorer in Clay, the QBR summarizer in a Python script on a cron job, the outbound personalization step in the SDR sequence builder, the ticket router in Zendesk, and so on. Each integration is a direct call to a specific provider’s specific endpoint, with hardcoded model names and provider-specific payload shapes scattered across the team’s automation tools.

When Haiku 4.5 launches and the team wants to move lead routing to it (because routing doesn’t need Sonnet’s reasoning and Haiku is a fifth of the cost), the work is real. Someone has to find every place lead routing happens, change the model name, retune temperature and max_tokens because Haiku responds slightly differently, rewrite the prompt because the system message convention changes, update the response parser if the output format shifted, and regression test all of it on production-like data. If the move is from Anthropic to OpenAI rather than within the family, the work multiplies because the API shape itself differs. This is why most teams don’t switch even when the economics say they should.

With abstraction, the same workflow calls an internal endpoint instead. Something like internal-ai.company.com/score-lead with a generic payload: the lead record, the scoring rubric ID, and a workflow identifier. Behind that endpoint sits a thin service the RevOps or GTM Engineering team owns. The service holds a config file that maps workflow identifiers to providers and parameters, like:

score-lead          → anthropic/claude-sonnet-4-6, temp=0.0
route-lead          → anthropic/claude-haiku-4-5, temp=0.0
parse-meddpicc      → anthropic/claude-opus-4-7, temp=0.1, thinking_budget=8000
enrich-account      → deepseek/v4, temp=0.0
competitive-brief   → google/gemini-3-1-pro, temp=0.2

The service translates the generic request into whatever the current provider expects, makes the call, parses the response, and returns it in a shape the workflow already understands. Switching lead routing from Sonnet to Haiku is a one-line config change. Switching from Anthropic to OpenAI on a workflow is a config change plus a prompt regression test, no integration code touched. Cost telemetry, cache hit tracking, and per-workflow attribution all live in the service, which is also where you implement quality benchmarks and A/B testing against challenger models.

This is what GTM Engineers are actually building inside companies that are doing this well. Cargo and similar GTM infrastructure platforms package the same pattern as a product. Teams not ready for a platform usually start with a small internal service, often a single Python file deployed on AWS Lambda or a Cloudflare Worker, that fronts every model call.

The second commitment is prompt and parameter management. Prompts and parameters carry as much organizational knowledge as a CRM schema or a routing rule, and they should be treated with the same operational seriousness. They live in version control. They have owners. They have test suites that run on representative inputs and check for regressions when the prompt changes or the model behind it changes.

The parameter set itself is also moving.

Claude Opus 4.7, released this month, deprecated the temperature, top_p, and top_k parameters entirely, replacing them with an effort level and adaptive thinking. Teams that hardcoded temperature values across their integrations got 400 errors the first time they pointed a workflow at the new model. Teams that captured those decisions in one place changed a config row. Most RevOps teams I work with have prompts and parameters buried in scattered Zaps, embedded inside no code automation tools, copy pasted into n8n nodes, and stored in personal Claude projects that no one else can access. When a team member leaves or a model changes, that institutional knowledge is fragile or lost. The tuner I rebuilt this month is itself an artifact of this principle. Each row records the recommended model, the parameter settings (or, for Opus 4.7, the effort level), the max tokens, and the cost tier for a specific use case. When the underlying model market shifted, the tuner was easy to update because the relevant decisions were captured in one place rather than scattered across fifty integrations.

The third commitment is cost observability per workflow. The unit of cost in production AI is the workflow, not the API call. RevOps leaders who can answer “what does our MEDDPICC parsing workflow cost per month, broken down by input tokens, output tokens, and cache reads” are positioned to make smart cost decisions. RevOps leaders who get a single bill from each provider and have no way to attribute spend to use cases are not. This is the same hygiene most ops teams practice for SaaS spend, applied to AI. Without it, the cost optimization techniques discussed below are guesswork.

In practice, this means tagging every API call with a workflow identifier (using the metadata fields both major providers support), logging the input tokens, output tokens, cache reads, cache writes, and calculated cost to a table the team owns, and building dashboards that report cost per workflow, cost per record, and cache hit rate over time. Teams running an AI gateway get this nearly for free because every call already passes through one place. Teams that haven't built a gateway yet can get most of the value by populating the metadata field on each call and pulling monthly usage exports from each provider into a single sheet. The minimum viable version is a few hours of work. The full version pays for itself the first time an alert catches a runaway prompt loop before it generates a $4,000 surprise on next month's invoice.

Economics is the dominant variable

In the early phase of GTM AI, the dominant variable for most workflows was capability. The question was whether the model could do the task at all. That question is mostly settled now for the use cases on the framework. Sonnet, Opus, GPT-5.4, Gemini 3.1, Haiku 4.5, and DeepSeek V4 can all do lead scoring, BANT assessment, and outbound personalization with quality acceptable for production. The variation across models on these tasks is real but small enough that economics has overtaken capability as the deciding factor for most workflows.

Economics in 2026 is no longer a single number. You can assemble a stacked discount system. Three levers compound to produce per workflow costs that vary by an order of magnitude depending on architectural choices.

The first lever is tier selection. Inside the Anthropic family, Haiku 4.5 runs at one dollar per million input tokens and five dollars per million output tokens. Sonnet 4.6 runs three times that. Opus 4.7 runs five times the input price relative to Haiku. The same task can run on any of the three. The right tier depends on task complexity. The strongest model in the family is rarely the right default. Lead routing on Haiku produces classification quality that is not meaningfully worse than Opus for the same work, at a fifth of the cost. Treating Opus as the default for everything is the AI equivalent of putting all CRM workflows on the most expensive Salesforce SKU because the salesperson recommended it.

The second lever is prompt caching. Stable system prompts, scoring rubrics, persona libraries, and battlecards get cached after the first call and read at a 90% discount thereafter. A practitioner published an accounting on Medium of going from $720 a month to $72 a month on a customer support workflow by enabling caching on the static portions of his prompt. Anthropic’s own documentation references customer cases of 85% cost reductions on RAG based systems. The math is straightforward. If 70% of the input tokens for a workflow are stable system prompt content, enabling caching cuts the input bill by roughly 60% before any other optimization. For high volume scoring, classification, or content generation workflows, this is the single highest leverage cost optimization available.

The third lever is the Batch API. Asynchronous workloads where a 24 hour turnaround is acceptable run at half the cost. Overnight scoring, weekly QBR prep, monthly content batches, and bulk enrichment jobs are natural fits. Real time call coaching and ticket routing are not. The decision is per workflow, and the discount stacks with caching.

Stacked properly, these three levers can drop the effective cost of a high volume workflow to 20 to 30% of the published list rate. Without stacking, the same workflow runs at full sticker price. The same lead scoring workflow at 5,000 leads per month can cost $40 or $8 depending on whether the team has built caching into the prompt structure and turned on batch processing for the daily enrichment job. RevOps leaders who treat AI as a SaaS line item with a fixed unit cost are systematically overpaying.

What flexibility looks like in practice

Architecture for experimentation is mostly an operational discipline. Six practices distinguish teams that handle the model market well from teams that don’t.

1. Quarterly model review cadence

2. Challenger model A/B testing

3. Model agnostic prompt design

4. Contract terms that preserve optionality

5. Quality instrumentation

6. Switching readiness drills

The first is a quarterly model review cadence. Once per quarter, someone owns walking through every GTM workflow, checking whether the model behind it is still the right call, and updating the configuration where it isn’t. The cadence is matched to how fast the model market actually moves. Annual is too slow. Monthly is overkill for most use cases. Quarterly is the rhythm that catches the meaningful shifts without consuming the team. The review should produce a written log of what changed and why, so the institutional memory of model decisions accumulates over time.

The second is challenger model A/B testing. Production workflows benefit from running 5 to 10% of traffic against an alternative model at any given time. The challenger generates real performance data on actual workloads, which is far more reliable than benchmark scores published by labs. When a new model releases, the challenger slot makes the evaluation a configuration change rather than a project. Teams that have abstracted their model calls properly can rotate the challenger weekly with no engineering work.

The third is model agnostic prompt design. Prompts written to exploit one model’s idiosyncrasies become switching costs. Avoid provider specific reasoning tags, system message conventions that differ across providers, and memory features that bind the workflow to one provider’s stack. Write prompts that work across at least two providers and verify they do. The discipline costs a small amount of upfront optimization but pays back the first time the team needs to switch.

The fourth is contract terms that preserve optionality. Long term volume commits at peak prices are a common lock in vector. The published prices have been dropping faster than any reasonable commit term can amortize. Negotiate flexibility into the contract. Push for usage based pricing. Avoid multi year exclusivity unless the discount is dramatic enough to offset the optionality cost. Sales reps lead with annual commits because the math favors them. The model release cycle has shortened to roughly six months, which means a two year exclusive at March 2026 prices is in effect agreeing to overpay for the second half of the contract.

The fifth is quality instrumentation. Cost optimization without quality measurement produces silent regressions. Every workflow that has been cost optimized should also have a quality benchmark that runs on a representative sample of inputs. The benchmark is what protects against the failure mode where someone swaps in a cheaper model and degrades the output without anyone noticing for two months. The benchmarks do not need to be elaborate. A pinned set of 50 to 100 representative inputs with expected output characteristics is enough to catch most regressions before they reach customers.

The sixth is switching readiness drills. Once per quarter, run a small drill where you switch a single workflow to a different provider and see how long it takes. The first drill exposes everything that is fragile. The second one is faster. By the third or fourth, switching becomes a routine operation rather than an emergency response. Teams that have never switched anything in production should expect their first attempt to take five times longer than they planned. That gap is itself the most useful information the drill produces.

The lock in failure modes to avoid

The failure modes that kill flexibility are mostly mundane. Each one creates switching cost that compounds over time and quietly raises the bar for moving off a provider.

Prompts tuned to specific model idiosyncrasies. Some models respond to specific reasoning prompts (”think step by step before answering”), specific output formats (XML tags rather than JSON), or specific role conventions (”you are a helpful assistant”). Prompts tuned around these idiosyncrasies often fail when moved to a different provider because the new model interprets the cues differently. Generic, instruction first prompts move better.

Hard coded provider SDKs throughout the codebase. Every place in the integration code that calls a provider’s SDK directly is a place that needs to change when you swap providers. The cost of switching scales with the number of those call sites. Wrapping every provider call in an internal client is the standard mitigation, and it pays off the first time you switch anything.

Long term volume commits at peak prices. Provider sales reps lead with annual commits because the math benefits them. Given the current model release cycle, a multi year commit at today’s prices is functionally agreeing to overpay for the second half of the contract.

Vendor specific orchestration features. Memory features, file search, project workspaces, and managed agents are all useful, and several are deeply tied to a specific provider’s ecosystem. Building a workflow that depends on these features creates real switching cost when a different provider’s economics or capabilities pull ahead.

Skills concentration. If everyone on the team is fluent in one provider’s tooling and no one has built anything on another, the team’s collective ability to evaluate alternatives is limited. Cross training across at least two providers per workflow type is cheap insurance.

Once these accumulate, the architecture stops being flexible regardless of how many abstraction layers sit underneath. The discipline is recognizing each one as it arrives and choosing not to take it on unless the value is large enough to justify the lock in.

The model market keeps moving

The 75 days between the two editions of the tuner are not an outlier. The next 75 days will produce new pricing, new model generations, new use cases, and almost certainly some surprises that no one in the GTM AI space is currently forecasting. Teams that have built architecture for an experimentation era will absorb each shift as an upgrade to existing workflows rather than a multi quarter project. They will benefit from price drops without renegotiating contracts. They will adopt new use cases without rebuilding their stack.

The architecture is not technically sophisticated. Model abstraction. Versioned prompts. Per workflow cost observability. Three commitments that any RevOps team can implement in weeks. Combined with the operational practices described above, quarterly review, challenger testing, switching drills, they convert the model market’s movement from a risk into a source of compounding leverage on the existing stack.

The GTM teams that win the next two years of AI will have built architecture that makes model selection a recurring decision they execute well, on a cadence, with instrumentation that tells them when to move. Stay liquid.

For paid members: this week’s deliverable is the GTM AI Model Tuner workbook, the same artifact I rebuilt this month. Six tabs covering the current model recommendations across twenty plus GTM use cases, parameter reference for temperature and reasoning effort by task type, side by side model comparison with current pricing, a cost estimator that calculates monthly spend per workflow with cache hit and batch API levers, and a quick start guide for the four highest ROI workflows. The April 23 edition includes the full diff against the February 7 edition so you can see where the recommendations shifted and why. Download the workbook, plug in your own volumes, adjust the model selections to fit your data residency policy, and use it as the operating tool for the architecture this article describes.

Read more

Everett Berry, Head of GTM Engineering at Clay, built a different structure. Clay’s GTM engineering function splits into two teams. Forward deployed GTM engineers work directly with customers on implementation. Internal GTM engineers, operating under Osman Sheikhnureldin, build and maintain the automation that powers Clay’s own sales motion. That internal team runs in two week sprints, takes tickets from across the business, and ships twice a month with release notes. It operates like product engineering, with version control and explicit prioritization. And notably, Clay lets individual reps use whatever meeting tools they prefer, Granola, Attention, Gong, whatever fits their personal workflow. There is one hard requirement. The data has to flow into Clay, where the internal team can transform it. Experimentation happens at the edge. Standardization happens at the data layer.

Both companies reject the default that most RevOps leaders are watching unfold inside their own organizations right now, where every AE spins up personal projects in Letter AI, Claude, Gumloop, Cursor, and whatever else landed in their inbox this quarter. Both models produce strong outcomes. They look different in practice. The question worth answering is which model fits which kind of company, and what governance looks like when experimentation is the point.

Why the default is chaos

Accessibility collapsed the barrier to building. A seller with a browser, an email address, and a credit card can ship a working workflow in an afternoon. They can connect it to a CRM through OAuth, feed it transcripts from their calls, and start sending outputs to prospects before anyone in IT knows it exists. That is genuinely new. The last time RevOps faced something comparable was when sales engagement platforms gave every rep the ability to write their own sequences, and the governance lessons from that era mostly got ignored.

The consequences compound quickly. Duplicate work shows up across teams as three different AEs build three different versions of an account research workflow, none of which talk to each other and none of which reuse the good parts. Prompts touch CRM data without review, which means sensitive account information, competitor intelligence, and deal terms flow through services no one has evaluated. OAuth tokens persist long after the experiment ends, creating non human identities with persistent access that nobody is tracking. And none of it connects to outcomes, which means when someone asks whether any of this AI work is driving revenue, the honest answer is that nobody knows.

The scale of the problem is now documented. Rubrik’s 2026 Zero Labs research found that 86 percent of respondents expect AI agents to outpace their organization’s security guardrails within the next year, and only 23 percent claim full visibility into the agents operating in their environments. Okta reports that 80 percent of organizations have already experienced unintended agent behavior. IBM’s Cost of a Data Breach report found that shadow AI now accounts for 20 percent of all breaches and adds roughly $670,000 to the average incident cost. Gartner predicts that 40 percent of enterprise applications will feature task specific AI agents by the end of 2026, up from less than 5 percent at the start of 2025.

That is not a security problem RevOps can punt to IT. Agents in the GTM stack touch deal data, customer communications, and pipeline. When they misbehave, they do it inside the revenue engine.

Three operating models

Three operating models are emerging for how companies structure AI in GTM. Each has a real example, a set of conditions where it works, and a failure mode that tends to show up when the conditions change.

The first is pure centralization. A dedicated applied AI or GTM engineering team owns every build. Sellers submit requests, describe use cases, and consume what the central team produces. Owner is the clearest public example. The conditions that make it work are specific. Owner runs a high volume SMB motion with a relatively uniform ICP, which means use cases are shared across reps rather than highly idiosyncratic. The company invested early in third party and first party data, which gives the central team a foundation to build on. And Owner had the talent density to staff a dedicated applied AI function, which most companies do not. Where pure centralization breaks is when the motion becomes more varied, when sellers have legitimate domain knowledge the central team lacks, or when the central team becomes a bottleneck and reps go build in the shadows anyway.

The second is pure federation. Every team, and often every individual seller, experiments independently. There is no central registry, no shared infrastructure, no vetting, and no attribution back to outcomes. This is what most companies land in by accident. It is the model the Slack thread that started this piece was describing. A small amount of federation is productive, because domain experts closest to the problem often have the best ideas. A lot of federation without any connective tissue produces exactly the traffic intersection metaphor that senior operators keep reaching for. Work duplicates, good ideas die with the person who built them, risk accumulates, and leadership cannot answer basic questions about what is running or what it is producing.

The third is hub and spoke. A central team owns infrastructure, standards, the approved skill library, observability, and attribution. Business units and individual builders own use case discovery, domain knowledge, and iteration within the boundaries the hub defines. Clay is a hub and spoke organization. Zapier, based on what Lindsay Rothlisberger has shared publicly about their approach to AI skill governance, is evolving toward the same structure. Dataiku’s research across its customer base found that companies that successfully scale AI are three times more likely to use hub and spoke than any other structure, and Microsoft’s Cloud Adoption Framework explicitly recommends that mature AI organizations transition from centralized center of excellence models to advisory groups that set guardrails while frontline teams own delivery.

Hub and spoke is not a compromise between the other two. It is a different architecture that treats central control and distributed experimentation as complementary rather than opposing forces. The hub makes experimentation safer and cheaper. The spokes make the hub’s work relevant to what sellers actually do.

A decision framework

Five factors determine which operating model fits a given company at a given stage. Growth stage, motion complexity, data foundation, internal AI fluency, and risk tolerance.

Growth stage matters because the right structure at 20 reps is wrong at 200. Early stage companies with a small GTM team and a single motion can run pure centralization successfully, because one or two builders can cover the surface area. Once the team grows past roughly 50 GTM headcount or splits into multiple segments, centralization starts to create queue time, and queue time pushes builders underground.

Motion complexity is about how much variation exists across deals. A high velocity SMB motion where every deal looks similar rewards centralization, because the same workflow serves many reps. A mid market or enterprise motion where every deal has unique stakeholders, procurement dynamics, and technical requirements rewards federation, because the seller knows things the central team cannot possibly capture in a generic workflow.

Data foundation is the precondition Kyle Norton emphasizes before any of this matters. If the CRM is a mess, if call transcripts are not captured systematically, if account data is not enriched consistently, no operating model will save the company. Centralization is particularly hard without a data foundation, because the central team spends all its time fixing data quality instead of building. Hub and spoke works better in this environment because the hub can focus specifically on the data layer while spokes build on top of it.

Internal AI fluency determines how much guardrailing is needed. A company where most sellers have genuine AI fluency, can write usable prompts, and understand what a model is doing can run with lighter central control. A company where AI fluency is concentrated in a handful of people needs more centralization, not because federation is philosophically wrong but because most people cannot safely build alone yet.

Risk tolerance is the last factor. Regulated industries, companies with sensitive customer data, and organizations with active compliance exposure cannot tolerate federation. The risk surface is too large. Companies with less regulatory exposure can absorb more experimentation in the spokes, because the downside of a bad prompt is smaller.

A decision that feels ideological, centralized or federated, becomes empirical once these factors are laid out. Most mid sized SaaS companies with mixed motions, reasonable data, patchy AI fluency, and moderate risk exposure end up at hub and spoke. That is not a coincidence. It is what the factor analysis produces.

The governance control plane

The phrase agentic governance layer has been floating through RevOps conversations for months without a clear definition. The practical answer is a governance control plane with four concrete layers, and each layer has a specific owner and a specific output.

The first layer is a registry. A skill, prompt, and workflow registry that captures what exists, who owns it, what systems it touches, what data it handles, and what vetting status it has. This is the inventory problem. Anthropic shipped Skills in October 2025 as a way to package reusable workflows, and enterprise customers can now provision skills across an organization. The MCP registry pattern is doing the same thing for tool connections. These are registry primitives RevOps can adopt. The output of this layer is a living document that answers the question: what AI workflows are running in our GTM stack right now, and who owns each one.

The second layer is identity and access. Agents operating on behalf of sellers need scoped permissions, not the seller’s full CRM access. Okta and Frontegg have both published patterns for treating agents as first class identities with their own credentials, validity windows, and revocation paths. In a GTM context, this means an AE’s account research agent should not have write access to the pipeline, a marketing agent should not have access to individual deal data, and every agent should have a revocation path when the experiment ends. The output of this layer is that every AI workflow has a scoped identity and a clear off switch.

The third layer is observability. Fiddler, Kore.ai, Dynatrace, and IBM have all shipped agentic observability products in the last 12 months that capture traces, tool calls, decision flow, latency, cost, and output quality. RevOps does not need to build this from scratch. What RevOps does need is to connect the observability data to something sellers and leaders actually care about. A dashboard that shows which workflows are running, how often, with what error rate, at what cost, and with what downstream effect on deals. The output of this layer is a running picture of what AI is doing inside the GTM engine.

The fourth layer is attribution. This is where the governance conversation connects to revenue and where RevOps has a natural advantage. Attribution asks whether the workflow that researches accounts is actually producing better meetings, whether the agent that drafts follow ups is producing better response rates, whether the skill that summarizes calls is producing better next steps. Without attribution, AI in GTM is a cost center that nobody can defend. With attribution, it becomes a measurable input to pipeline and revenue. The output of this layer is a feedback loop from workflow to outcome that tells leadership which investments to scale and which to retire.

Those four layers together are the governance control plane. None of them exist in isolation. The registry feeds the identity layer. The identity layer feeds the observability layer. The observability layer feeds the attribution layer. A company that builds all four in sequence has an operating system for AI in GTM. A company that builds only some of them has fragments.

What the hub owns versus what the spokes own

The clearest way to make hub and spoke work in practice is to draw a sharp line between what the hub controls and what the spokes control, and then stick to that line even when it is tempting to expand central authority.

The hub owns infrastructure, standards, the approved skill and workflow library, the observability platform, the attribution model, and security. These are the pieces where consistency matters more than domain knowledge. Nobody needs three different observability platforms, and nobody needs a skill library that is different in sales versus customer success.

The spokes own use case discovery, domain knowledge, adoption, iteration, and advocacy. These are the pieces where proximity to the problem matters more than central control. A sales manager running an enterprise team knows what a good multithreading workflow looks like. A demand gen lead knows what account scoring signals actually predict intent. Pulling that knowledge into the hub and rebuilding it centrally loses the nuance that made it valuable.

Clay’s approach captures the spirit well. The internal GTM engineering team maintains the core infrastructure, which is Clay, Snowflake, Salesforce, and Gong, and the Slack app that GTM engineers interact with most of their work through. But when it comes to individual preferences around meeting tools or note taking, the team explicitly declines to dictate. The rule is that the data flows back into the central system. The method is up to the person. That is the operating principle that makes hub and spoke work at scale. The hub is strict about the things that need to be consistent and generous about the things that do not.

When the line gets blurred, two failure modes show up. If the hub claims too much territory, queues form, builders go underground, and the hub’s approval process becomes the bottleneck it was designed to prevent. If the spokes claim too much territory, the registry falls out of date, observability goes dark, and the attribution model breaks. The operating model depends on both sides respecting the boundary.

A phased rollout

Most companies cannot move from the current chaos to a mature hub and spoke control plane in a single quarter. The transition takes staged work across four phases, and the phases should not overlap because each one depends on the one before it.

Phase one: discover and inventory. The first job is to build the registry. Run a structured discovery across sales, marketing, customer success, and RevOps to identify every AI workflow, skill, agent, and prompt that is currently in use. This includes workflows built in Zapier, n8n, Gumloop, or similar platforms, skills created in Claude or ChatGPT projects, and agents deployed through any vendor tool. The goal is not to approve or reject anything yet. The goal is to produce a complete picture. Expect this to take three to six weeks and to surface more work than anyone expected.

Phase two: vet and publish. Once the inventory exists, start vetting. Use a lightweight scorecard that evaluates each workflow on five dimensions: data sensitivity, business criticality, usage volume, demonstrated value, and risk surface. The top workflows get promoted into an approved library with documented ownership, usage guidelines, and enablement. The bottom workflows get deprecated. The middle ones go into a sandbox tier where experimentation continues but with observability turned on. Publish the library in a place sellers will actually look. Zapier’s approach of running a dedicated Slack channel plus a shared folder of approved skills is a reasonable pattern. Expect four to eight weeks for the first vetting pass.

Phase three: instrument. With a library in place, turn on the observability and attribution layers. Pick three to five workflows that matter most and instrument them end to end. Capture usage, quality, cost, and downstream effect on deals. This is where RevOps earns back the visibility that got lost during the experimentation phase. It is also where the business case gets built, because attribution data will show which workflows deserve more investment and which need to be retired. Expect this phase to run continuously once started, but the first wave takes roughly a quarter.

Phase four: evolve from gatekeeper to advisory. The final phase is where the hub changes posture. Early on, the hub has to be a gatekeeper because standards, tooling, and skills are still being established. Once those foundations exist, the hub should move toward an advisory role that sets guardrails and enables spokes to build within them. This is the Microsoft Cloud Adoption Framework’s explicit recommendation, and it matches what Clay, Zapier, and other mature organizations have actually done in practice. The shift is hard for hub leaders who have spent months building control, but it is the move that prevents the hub from becoming the next bottleneck.

Common failure modes

A few failure modes show up often enough to be worth naming. Over centralization that produces bottlenecks and pushes sellers back underground, which reproduces the original problem under a different name. Under governance that announces a policy without building the infrastructure to support it, which is the cheapest and most common failure because a policy document takes a day and a control plane takes a year. Tools without standards, where the company buys an observability platform or a governance product and expects the tool to do the work that only an operating model can do. And standards without attribution, where the hub publishes rules but cannot prove that any of the approved work is producing revenue, which makes the whole function politically vulnerable the first time a CFO asks what it costs and what it produces.

What RevOps should actually do this quarter

The governance conversation tends to drift into abstraction, so here is the concrete version. Run an inventory of every AI workflow in the GTM stack in the next three weeks. Start a channel where sellers can share what they are building, because visibility follows contribution. Vet the five highest volume workflows against a simple scorecard and publish the approved versions in a shared space. Instrument one workflow end to end so there is at least one real attribution example by the end of the quarter. Publish the operating model even if it is incomplete, because an imperfect published model produces better behavior than a perfect unpublished one.

The reason this falls to RevOps rather than IT or enablement is that every layer of the control plane maps to something RevOps already owns elsewhere. The registry is an extension of the tech stack documentation RevOps already maintains. The identity layer is an extension of the CRM permissions model. The observability layer is an extension of the pipeline visibility work RevOps has done for years. The attribution layer is the core RevOps competency, applied to a new input. None of it is unfamiliar territory. It is the familiar work applied to a surface that has grown faster than the function has adapted.

The organizations getting this right are not choosing between control and experimentation. They are building the hub that makes experimentation productive and the spokes where experimentation actually happens. Kyle Norton’s centralization and Everett Berry’s engineered GTM function are two points on the same trajectory, one further along than the other, both heading toward the same place. The companies still stuck in the traffic intersection are stuck because they have not yet built the operating system that makes the intersection legible.

Paid members get the full operating kit: a CoE charter you can adapt to your company, a workflow registry, vetting scorecard, observability dashboard, RACI matrix, and rollout tracker, plus a technical implementation guide covering RBAC configuration across Salesforce, HubSpot, Gmail, and Slack with a build-versus-buy decision tree.

Read more

Three stakeholders, one question, three genuinely different information needs. And in most companies, none of them can be answered with confidence because the data infrastructure was never built to support the analysis.

This is not a failure of intent. It is a sequencing problem. Companies build their CRM and quoting infrastructure around the needs of a single-product sales motion, then grow into multi-product organizations before the data model catches up. Win rate is a single number. Revenue is one ARR line. Product mix lives as line items in a quoting tool that does not connect cleanly back to closed won or closed lost status in the CRM. The questions the board starts asking in year three of the multi-product journey require infrastructure that ideally gets built in year one.

Understanding what each stakeholder actually needs is the first step. Understanding the measurement stages required to answer those needs is the second. The gap between where most companies are and where they need to be is where RevOps earns its value.

The question behind the question

Boards ask about bundling strategy because they are trying to evaluate the durability of the revenue model. A company with one strong product can grow through volume. A company building a multi-product platform is making a different bet: that customers who buy more products will stay longer, expand further, and generate NRR above 100% at higher rates than single-product customers. The board wants evidence that this thesis is holding. The metric they are really asking about is NRR segmented by product cohort, specifically whether multi-product customers are retaining at a materially different rate than single-product customers and whether that gap is growing as the product portfolio matures.

CROs use the same words but mean something operationally specific. They want to know whether bundles are a sales accelerant or a sales complicator. Are bundled deals closing at higher average contract values? Are they taking meaningfully longer to close, and if so, by how many days on average? Are reps having to discount further on bundled configurations to get buyers to accept the full package, or is the bundle creating perceived value that actually reduces price sensitivity? Which product combinations show up most consistently in won deals, and which combinations are getting stripped out during procurement? These questions require deal-level data segmented by bundle configuration, not just overall win rate.

CPOs want different signal altogether. They want to know what is winning in market and what is getting used after the deal closes. A competitive win that involved all three products in the bundle is meaningfully different from a competitive win where the buyer was primarily evaluating the core product and accepted the other two because they were included in the price. The CPO also cares about post-sale activation: a bundle win followed by dormant modules is a retention risk at renewal and an expansion blocker. Understanding which products are being activated versus which are sitting unused requires connecting usage data to the commercial record in a way most CRM data models do not support.

Each of these information needs requires progressively more sophisticated measurement infrastructure. Companies tend to discover this gap when the board starts asking questions. The smarter path is to build ahead of the question.

Stage one: Flat visibility

At stage one, win rate is a single company-wide number. There may be some slicing by segment, by rep, or by deal size, but product-level visibility does not exist in any reliable form. Revenue is total ARR. Bundles exist only in the quoting tool as line items on opportunities. Nobody has formally defined what a bundle is in the data model. When someone asks a product-level question, the answer comes from a custom report that takes several days to produce, relies on inconsistent tagging, and generates enough doubt that leadership reverts to anecdote.

This is the right starting state for a single-product company. It becomes a problem the moment a second product ships and commercial questions start requiring product-level answers. Most companies operate at stage one significantly longer than they should because the gap is invisible until someone important asks a question that exposes it.

The tell is usually a board meeting. Someone asks which products are driving win rate improvement, or whether the new product launch is converting into won deals at the expected rate. RevOps pulls the data, realizes the opportunity records do not have reliable product line information, and produces an answer qualified by so many caveats that nobody trusts it. That meeting is usually the catalyst for the stage one to stage two transition.

Stage two: Product-line win rates

Stage two requires two foundational decisions: a clean product taxonomy and an opportunity data model that connects line items to win/loss outcomes. Neither is technically complex. Both require organizational discipline to build and maintain.

Product taxonomy means defining which strategic product lines exist and mapping every SKU in the catalog to one of them. Most companies reach stage two with a product catalog that has grown organically: SKUs for every pricing variation, every contract duration, every custom configuration that came up during a negotiation. Before any useful product-level analysis is possible, someone has to collapse that catalog into a manageable set of strategic categories and maintain that mapping as the catalog evolves. This is a RevOps governance decision, and it is probably the most underrated prerequisite in the entire measurement progression. Without it, every downstream analysis requires manual reconciliation that nobody trusts.

Once the taxonomy exists, the opportunity data model needs to support it. In practice, this means opportunity products or line items being recorded consistently on every deal, tagged to strategic product lines, and maintained through the close. The failure mode at this stage is adoption: sales reps who do not log line items produce deals that cannot be analyzed by product, which creates reporting gaps that accumulate quietly until someone notices the analysis is broken.

With stage two infrastructure in place, CROs can see win rate by product line, average deal size by product, and sales cycle length segmented by which products were present in the deal. They can calculate attach rate over time, meaning what percentage of new deals include a given product, and whether that percentage is trending in the right direction. They can identify which products appear most consistently in won deals and which appear more often in deals that ultimately go to a competitor.

The board gets ARR mix by product line at stage two. They can see whether the product strategy is gaining commercial traction and how new product lines are growing as a share of new bookings. What they still cannot see is NRR segmented by product cohort. That requires stage three.

Stage three: Bundle economics

Stage three is where bundle measurement becomes a formal discipline. It requires the ability to classify each deal by its bundle configuration: which products were sold together, in what combination, and at what pricing relative to standalone. Once that classification exists, the organization can calculate win rate by bundle configuration, average deal size by configuration, sales cycle length by configuration, and discount rate by configuration.

The bundle classification logic has to be explicitly designed. A bundle must be defined. Which product combinations constitute a strategic bundle versus a standalone deal where the customer happened to add a module? Most companies have two or three natural bundle configurations that represent their intentional packaging, and everything else is either a standalone deal or an opportunistic add-on. Codifying those configurations as a formal field on the opportunity is what makes stage three analysis possible.

With that classification in place, the CRO can answer the actual question they have been asking. If bundled deals close at 40% higher ACV but require 30 additional days in the sales cycle and 12% more discount, that is a real tradeoff that can be modeled and optimized. If bundled deals are closing faster than standalone deals because the package simplifies the buyer’s decision, that is evidence the packaging design is working. If certain bundle configurations consistently show up in lost deals, that is a signal worth investigating. These are not questions answerable by intuition. They require stage three measurement.

The board gets what it actually wants at stage three: NRR segmented by product cohort. This is the analysis that lets leadership evaluate whether the multi-product strategy is producing durable revenue. Box has publicly reported that multi-product customers generate 125% NRR compared to 90% for customers with no add-on products. That cohort-level NRR differential is the clearest possible evidence that a platform strategy is working. It is also a stage three output. Calculating it requires clean product attachment data at the account level, connected to renewal and expansion outcomes over time.

Samsara has built its investor narrative around the same measurement. The company reports that 62% of large customers use three or more products, up from 54% two years prior, and that large customers generate 120% NRR. The directional story is that multi-product adoption is compounding, and that higher product depth correlates with higher retention. That is a specific, verifiable data point that requires stage three infrastructure to produce. HubSpot reports similarly: over 35% of Pro-plus customers by ARR use four or more hubs, up 7% year-over-year, and the company’s historical NRR peaked at 115% during the period when multi-hub adoption was accelerating most rapidly. The correlation is observable because the measurement exists.

At stage three, the CPO also gets meaningful input for the first time. Win rate by bundle configuration tells them which product combinations are winning in competitive situations. Combined with competitive loss data tagged to specific configurations, it becomes possible to identify which combinations are creating differentiation and which are getting stripped out by buyers who do not see the value in the full package.

Stage four: Usage-correlated revenue

Stage four connects product usage data to the commercial record. It is no longer enough to know what a customer bought. The organization wants to know which products are actively in use, which are dormant, and how usage patterns predict expansion, stagnation, or churn at the account level.

This is the measurement capability that gives CPOs real signal on whether product investment translates to customer outcomes, and whether bundle wins are genuine platform wins or one-product wins with dormant attachments. A customer who bought three modules and uses all three is a different retention and expansion story than a customer who bought three modules and has had two of them sit idle since onboarding. Stage four measurement makes that distinction visible before it becomes a renewal problem.

CrowdStrike has built module adoption tracking into its standard investor reporting. In its most recent fiscal year results, the company reported that 67% of customers use five or more modules, 48% use six or more, 32% use seven or more, and 21% use eight or more. Those numbers are tracked and published every quarter. The progression over time is the primary evidence that the Falcon platform strategy is working: customers are not just buying modules, they are activating them, and the rate of deeper adoption is growing. At the prior fiscal year end, those rates were 64%, 43%, 27%, and the addition of the eight-module tier as a tracked metric reflects the maturation of the platform itself.

That level of reporting does not come from checking a box. It requires a measurement system that tracks module activation at the customer level, aggregates it across the subscription base, and produces numbers that are auditable enough to put in earnings releases. That is stage four measurement, and it requires connecting the product analytics layer to the billing and CRM systems in a way that most companies have not done.

Stage four is the most technically intensive transition because it typically means integrating a product analytics system or data warehouse with the CRM. But the questions it enables are categorically different from anything achievable at earlier stages. Customer health scoring becomes genuinely predictive. Expansion playbooks can be triggered based on module adoption milestones. Renewal risk models can identify accounts where product depth is low months before the renewal conversation.

What RevOps builds to move through the stages

The progression from stage one to stage four requires deliberate infrastructure decisions at each transition. None of them are primarily technology problems. They are data governance and process design problems, which puts them squarely in RevOps scope.

The stage one to stage two transition is a product taxonomy decision followed by CRM configuration and rep enablement. Someone has to decide what the strategic product lines are, collapse the existing SKU catalog into those categories, configure the CRM to enforce line item capture on every deal, and build reporting logic that aggregates opportunities by product line. The taxonomy decision is the hardest part because it requires product and revenue leadership to agree on what categories matter. The CRM configuration is straightforward once the taxonomy exists. The enforcement is ongoing.

The stage two to stage three transition is a bundle classification design project. It starts with product and revenue leadership defining which configurations are strategic bundles, formalizing those definitions as opportunity field values, and building the reporting logic to segment deal economics by configuration. The analysis itself is not complex once the classification field is populated. Getting it populated consistently across all opportunities requires field governance and usually some inspection cadence to catch deals that were not properly tagged.

The stage three to stage four transition requires a technical integration between the product analytics layer and the revenue data model. The output that RevOps needs is a standardized product adoption signal at the account level that can be used in health scoring, renewal risk models, and expansion playbooks. The integration design, the data model for surfacing adoption signals in the CRM, and the logic for translating usage events into account-level health signals are all RevOps infrastructure decisions, even if the engineering is done by someone else.

What it signals when companies get this right

The companies that report bundle and product metrics with confidence have made the infrastructure investment visible. When CrowdStrike publishes module adoption rates every quarter, those numbers are the output of a measurement system that could not exist without stage four infrastructure. When Samsara reports that multi-product penetration among large customers increased from 54% to 62% over two years, that data requires clean product attachment tracking connected to the account record over time. When HubSpot correlates multi-hub adoption with NRR improvement, the relationship is observable because someone built the data model that makes it observable.

These companies are not just reporting metrics for investor relations purposes. They are using those metrics internally to make product roadmap decisions, packaging decisions, and retention investment decisions. A CPO with stage four measurement has a fundamentally different conversation with the board than a CPO working from qualitative win/loss summaries. A CRO who can show bundle deal economics by configuration can make quota-setting and territory decisions with confidence that is not possible from aggregate win rate alone.

The measurement gap between where most companies are and where the questions being asked require them to be is not unique to any company or industry. It is a structural consequence of building CRM infrastructure for a single-product motion and then growing faster than the data model does. The companies that close that gap deliberately, starting with product taxonomy and opportunity discipline and progressing through bundle classification to usage-correlated revenue, are the ones whose executives can walk into a board meeting and answer the bundling question with data that nobody needs to qualify.

The infrastructure that supports that answer is not aspirational. It is a sequenced set of decisions that RevOps is positioned to make and own.

RevOps Impact members get the Bundle Performance Scorecard, an Excel workbook with pre-built frameworks for tracking win rate by product line, bundle configuration economics, attach rate cohorts by quarter, and NRR segmentation by product mix. Includes a stakeholder summary tab formatted for board and executive review.

Read more

Read more

Most RevOps teams are running the same three or four manual processes every week: reviewing the pipeline for stale deals, checking whether MQLs got worked within SLA, compiling a summary of what changed since last Monday. These are not strategic decisions.

They are maintenance tasks, and they consume time that should go toward designing better processes and systems.

The question every RevOps leader eventually reaches is not whether to automate these tasks. It is whether to automate them inside the CRM’s native workflow engine, where you are constrained by whatever triggers and actions the platform exposes, or whether to build a programmable layer that runs on a schedule, persists its own state, synthesizes what it finds into something a human can act on, and has a complete audit trail.

This article covers the architecture for the latter. It is a system where code built by an AI coding agent runs on a defined schedule, reads from your CRM and conversation intelligence stack, delivers outputs to the team via Slack, maintains a traceability log in GitHub for reversibility, and optionally routes a synthesized narrative to a human reviewer before anything reaches an executive audience. The three operational use cases this covers are MQL follow-up compliance, stale deal detection, and weekly pipeline change reporting. The same architecture supports any repeating GTM monitoring task you can define clearly.

Why native CRM automation falls short here

HubSpot workflows are well-suited for event-driven logic. A contact fills out a form, a workflow fires. A deal reaches a stage, a task gets created. That is the paradigm the platform is designed for: one object type, defined triggers, defined actions, within the logic the workflow editor exposes.

The constraints become visible the moment you need something different. A scheduled query that compares the current state of the pipeline against its state from seven days ago requires you to persist that prior state somewhere, which a CRM workflow cannot do natively. Cross signal logic that asks whether a deal has had no logged calls, no CRM notes, and no stage movement in the past 14 days is difficult to build cleanly in a standard workflow editor. Synthesizing multiple data points into a coherent narrative for a weekly pipeline brief is entirely outside what any CRM workflow engine is designed to do.

This is not a failure of any specific platform. It is a description of what trigger-action automation is built for versus what a revenue organization needs at a certain level of operational maturity. Anecdotes, a compliance tech company, documented a version of this constraint when building their internal GTM infrastructure. Their team found that HubSpot workflows hit a ceiling when they needed to orchestrate logic across their backend systems, so they moved that logic to GitHub Actions, which gave them better control over the execution environment and logging. The principle generalizes: when your monitoring requirements outgrow the trigger-action paradigm, you need a programmable layer that sits outside the CRM but reads from it.

The architecture

The system is organized around four components that work together: a code layer, an execution layer, a delivery layer, and a state layer.

The code layer is where the business logic lives. These are scripts that query the HubSpot API for MQLs created in the past 48 hours with no logged activity. Scripts that call the Gong or Fireflies API to identify deals where no calls have been logged in two weeks. Scripts that compare this week’s pipeline value by stage against last week’s snapshot. Each script is scoped to a specific operational question with a specific output format, and all of it lives in a version-controlled repository.

The execution layer is GitHub Actions, which runs those scripts on a schedule using cron syntax. Monday morning at 8am, the pipeline delta script fires. Tuesday and Thursday, the MQL compliance check runs. Every morning, the stale deal alert executes. The schedule is version-controlled YAML, which means any change to when or how often something runs goes through the same review process as any other code change. There is no configuration drift, no undocumented schedule living in someone’s head.

The delivery layer is Slack. Outputs from each run go to the channel the relevant team already reads. MQL compliance failures go to the sales channel. Stale deal alerts go to the sales manager. Pipeline changes go to the RevOps and sales leadership channel. The messages are formatted to be readable at a glance: affected records with direct CRM links, owner names, and a plain statement of what the system found.

The state layer is a JSON file that lives in the GitHub repository itself. Each time the pipeline delta script runs, it writes a snapshot of the current pipeline to that file and commits it. The next run reads that file to understand what changed. Because this file is version-controlled in Git, you have a complete history of every snapshot. If a run produces unexpected output because of a data anomaly in the CRM, you can check out that commit, read what the system saw, and if necessary restore to a prior state. This is the audit trail.

Credential management and access design

The HubSpot API key, the Gong credentials, the Fireflies token, the Slack webhook URL: none of these belong in the code. They live in GitHub repository secrets, which GitHub Actions injects into the runtime environment as environment variables. The repository contains no credentials. The gitignore is configured to ensure no local environment file ever gets committed by accident.

This matters for reasons beyond security hygiene. When you build a system that touches your CRM and conversation intelligence stack on a schedule, you want confidence that no credential exposure can propagate through the codebase. GitHub Secrets are encrypted at rest, scoped to the repository, and accessible only during a workflow run. The pattern applies regardless of which APIs you are integrating.

It is also worth distinguishing between read and write access at the API permission level. Most monitoring use cases require only read access. The MQL compliance check reads contact records. The stale deal alert reads opportunity activity. The pipeline delta reads deal stages. Only workflows that write back to the CRM, such as logging a flag field or creating a task, require write-scoped tokens. Maintaining separate read and write credentials reduces the blast radius if something goes wrong, and it forces a design discipline: if a workflow needs write access, that is a deliberate choice with its own review, not a default.

The traceability log

The traceability log is the part of this architecture that most teams skip, and it is the part that saves you when something goes wrong. When a monitoring script fires and produces unexpected results, you need to understand what state the system was in when it ran. When an alert goes to Slack based on what turns out to be stale data, you need to trace exactly which API call returned what, and when. When a sales leader asks why the pipeline delta showed a $340K drop on Monday morning, you need an answer that does not require rerunning the query and hoping the CRM data still matches.

The log captures three things: the timestamp of each run, the raw output of each API query, and the delta between the current and prior states. It is appended on each run and committed to the repository as part of the workflow. That commit history is your audit trail. To understand what happened on any given day, you check out that commit and read the log. To reverse to a prior state, you restore the prior snapshot file. This is exactly how software engineering teams manage state in CI/CD pipelines, and the same discipline applies to revenue operations infrastructure.

GitHub’s own agentic workflow research, published by the GitHub Next team in early 2026, built the same logging principle into their framework from the start: every workflow run leaves a visible, inspectable artifact, and any write operation must pass through an approved output mechanism before it takes effect. Revenue operations infrastructure should work the same way.

Use case 1: MQL follow-up compliance

MQL follow-up compliance is the most common use case for this kind of system and the one where RevOps teams are most likely to rely on manual spot-checks that happen inconsistently or after the fact.

The compliance script queries HubSpot for all contacts that transitioned to MQL status in the past 48 hours and have no logged activity since that transition: no calls, no CRM emails, no tasks marked complete. It computes the time elapsed since the MQL transition and compares that against the defined SLA. In most B2B SaaS environments, that SLA is somewhere between two hours and 24 hours for the first touch, depending on the motion and the lead source.

Any contact that fails the compliance check produces a Slack message in the relevant channel. The message includes the contact name, the company, the time elapsed since MQL transition, the assigned owner, and a direct link to the HubSpot record. No report needs to be run. No spreadsheet gets compiled on Friday afternoon. The information arrives where the team already works, at a cadence that reflects the SLA.

The traceability log records every run: which contacts were flagged, which cleared, and the timestamp of each evaluation. Over time, that log becomes a data source for a different kind of analysis. Which reps consistently have follow-up compliance gaps? What time of day do failures cluster? Do certain lead sources correlate with slower follow-up? The log answers those questions without requiring anyone to build a separate report.

Use case 2: Stale deal alerts

Stale deal detection is a problem that most pipeline management tools address in some form. Momentum, for example, built a configurable staleness rule system that monitors deal activity and prompts reps to close or update deals that have gone quiet. Clari surfaces similar signals through its pipeline inspection interface. Both approaches are designed to make invisible deal risk visible.

The programmable layer here operates on the same principle but gives you full control over the definition of stale. The script queries HubSpot for open deals above a defined ACV threshold that have had no activity in a configurable number of days. Activity includes Gong-logged calls pulled via the Gong API, Fireflies-transcribed calls pulled via the Fireflies API, HubSpot notes, emails, or stage changes. The more conversation intelligence signals you pull in, the more accurate the staleness definition becomes. A deal where the rep sent a check-in email but no call has happened in 21 days should be treated differently from a deal with zero touchpoints in the same period, and the script can be written to reflect that.

The Slack alert for a stale deal includes the deal name, the current stage, the time since last activity, the ACV, the close date, and the assigned AE. Sales managers receive a channel notification each morning with everything that crossed the staleness threshold overnight. The threshold is not hardcoded in the script. It is a configuration variable that lives in the repository and can be updated by changing one line of YAML. When the team agrees that the definition of stale should change, that change is a code commit with a clear record of who changed it and when.

Use case 3: Weekly pipeline changes

The pipeline delta use case requires the state layer explicitly, which is what makes it more architecturally interesting than the other two. The script runs Monday morning. It reads the current state of the pipeline: every open deal, its stage, its ACV, its close date, its assigned owner. It then reads the snapshot stored in the log file from the prior Monday and computes the delta.

The delta is the set of differences: deals that moved forward, deals that slipped stages, deals that closed, deals that were added to the pipeline, deals whose close dates changed, deals whose ACV was revised. Each category has a clear definition, and the logic for computing it is explicit in the code.

The output is a structured Slack message that reads like a brief for a sales leader: X deals moved forward, Y deals slipped stages, Z deals closed won, the total pipeline value changed by $N. It is readable in under 60 seconds. A sales leader who has three minutes before their Monday review call gets a complete picture of what moved and what did not without needing to pull a report or ask RevOps to compile one.

The comparison logic is transparent. If the delta looks wrong, you can open the log, look at both snapshots side by side, and trace the discrepancy. That transparency is a structural advantage over a BI tool or a CRM report that recomputes on the fly with no record of what it showed the last time.

The synthesis layer

The three use cases above each produce structured, readable outputs. But they are still operational data: flagged records, counts, amounts. The synthesis layer is where a model reads across all three outputs and produces a narrative that a business leader can act on without decoding the underlying data.

A synthesis prompt structured around those three data sources might produce something like: “Follow-up compliance dropped below 80% for the third consecutive week, concentrated in the enterprise segment. Four late-stage deals went stale this week with a combined ACV of $420K. Pipeline coverage for Q2 dropped from 3.1x to 2.7x, driven primarily by two deals that slipped to Q3 and one deal that was removed from the pipeline following a competitive loss.” That is a different kind of output than any individual script produces on its own. It requires cross-dataset reasoning, and it produces language that translates operational signal into business context.

The synthesis script runs after the individual monitoring scripts complete. It reads their outputs, passes them to the model with a structured prompt, and produces a draft. The draft is not published automatically. That is where the human-in-the-loop step comes in.

Human-in-the-loop approval

The synthesis output is not the end of the workflow. Before it reaches an executive audience, a human reviewer reads it and decides whether to send it as-is, edit it, or flag it for investigation. The approval mechanism is a Slack message sent to a designated reviewer containing the draft summary and two inline actions: approve to send, or flag for revision. If the reviewer approves, the summary goes to the executive channel. If they flag it, it returns to the RevOps owner with a note.

This matters for two distinct reasons. The first is accuracy. Synthesized outputs from a model can misread the data, particularly in edge cases involving how records are categorized in the CRM or how deal activity is attributed across multiple systems. A human reviewer catches those errors before they reach an audience where they would erode trust in the system. The second reason is accountability. When an executive receives a pipeline brief, there is a person whose judgment stands behind it. That accountability does not exist if the system publishes directly.

The design principle here is widely recognized in software infrastructure. GitHub’s Agentic Workflows research explicitly built read-only defaults and human approval gates into its write operation model. The same logic applies to revenue operations: AI systems that produce consequential outputs should have a human checkpoint before those outputs take effect.

A phased approach to building this

The order of operations for building this system matters because each layer depends on the one below it. Trying to build synthesis before the individual monitoring scripts are reliable produces a system that amplifies bad data rather than surfacing useful signal.

Phase one is monitoring and alerting. Build a single script against a single data source, run it locally, verify the output is correct, and then move it into a GitHub repository with a GitHub Actions workflow file and a scheduled cron trigger. Add the API credentials to GitHub Secrets. Run the first scheduled execution and debug from the GitHub Actions log. When that one script runs reliably and delivers to Slack, add the second and third use cases. The infrastructure does not change. Only the business logic does.

Phase two is state persistence. Once monitoring scripts are running reliably, layer in the traceability log. The pipeline delta use case requires this from the start, so it naturally drives the implementation. Write the first snapshot, verify the file commits to the repository correctly, and run two consecutive executions to confirm that the delta computation produces a correct diff. At this point you have a system that monitors, alerts, and maintains an auditable state history.

Phase three is synthesis and approval. With clean, structured outputs from all three monitoring scripts, write the synthesis prompt. Run it manually against a week’s worth of logged outputs to validate that the narrative is accurate and readable before scheduling it. Then add the Slack approval workflow and test the full path: monitoring scripts run, synthesis runs, draft arrives in a reviewer’s Slack, reviewer approves, summary goes to leadership.

Each phase is independently useful. A team that builds phase one and stops has still eliminated a substantial amount of manual monitoring work. Phases two and three add analytical capability and executive communication infrastructure on top of a working operational foundation.

What this makes possible over time

The immediate value is time recovered. RevOps stops compiling manual reports. Sales managers receive Monday briefings without building them. MQL compliance issues surface in real time rather than at the weekly pipeline review.

The longer-term value is operational discipline with a measurable data set behind it. When compliance checks run automatically and their results are logged, you accumulate records over time. That data shows whether your SLA definitions are realistic, whether certain reps or segments consistently underperform, and whether pipeline hygiene is improving or degrading quarter over quarter. None of that longitudinal analysis is possible when checks happen manually and inconsistently.

The architecture also scales horizontally without structural changes. Once the execution layer and delivery layer are in place, adding a new monitoring use case means writing a new script and adding a workflow file. A team that starts with three scripts can grow to eight or ten over a quarter. The underlying infrastructure does not get more complex as the use case count grows.

The paid deliverable for this article is a GitHub starter kit for RevOps Impact members. It includes a complete repository structure, three working GitHub Actions workflow YAML files (one per use case), Python script templates for each monitoring function with placeholder API integration points, the traceability log schema, a Slack message formatter, and a step-by-step setup guide for configuring GitHub Secrets and API credentials. A practitioner with basic Python familiarity and an existing HubSpot setup should be able to get the first workflow running in a single afternoon.

Paid members: The doc below is the complete build guide for members. It includes the full repository structure, all three GitHub Actions workflow YAML files, Python script templates for each use case with API integration points, the traceability log schema, the synthesis prompt template, the Slack approval Block Kit payload, the secrets setup reference table, and a three-phase launch checklist. It is designed so someone with basic Python familiarity and an existing HubSpot setup can have the first workflow running in a single afternoon. Or… if you’re handy with it. Just shove it into Claude Code and go from there.

Read more

The function has spent the better part of a decade building its credibility by speaking fluent CRO: pipeline coverage, stage conversion, sales velocity, net revenue retention. Those are the right metrics for a function that coordinates go-to-market execution, and they have earned RevOps a seat in many rooms where it previously had none.

But the language stops short of the boardroom, and specifically short of the CFO. The CFO is running a different calculation. At PE-backed SaaS businesses, pre-IPO companies building toward profitability milestones, and public companies managing margin expectations from investors, the scoreboard is EBITDA. Earnings before interest, taxes, depreciation, and amortization. Operating profitability.

RevOps practitioners generally understand what EBITDA is. What most have not fully internalized is how much of it they actually influence. The go-to-market function is the single largest cost center in a SaaS business. Sales and marketing expense at public SaaS companies averages around 50% of revenue, and the range among high-growth companies runs considerably higher. Okta, during a period of aggressive expansion, invested over 65% of revenue in go-to-market. Analysis of 73 SaaS companies that went public between 2017 and the early 2020s found that sales and marketing at roughly 50% of total operating expense represents a realistic median, with fast-growing companies pushing closer to 80% of opex into the GTM function. The exact percentage varies by stage, motion, and average contract value. The directional truth holds regardless: in B2B SaaS, the company’s largest cost concentration lives inside the function that RevOps architectures and governs.

That creates a direct line to EBITDA. If RevOps owns the efficiency architecture of a cost center representing half or more of total operating expense, then the decisions RevOps makes about structure, process, technology, and measurement carry consequences that flow directly into operating profitability. There are three levers through which this happens. The first two are familiar to most practitioners, even if they rarely get framed this way. The third receives less attention than it deserves.

Revenue efficiency as a margin input

The standard RevOps value narrative lives in this lever: better conversion rates, shorter sales cycles, higher net revenue retention, more accurate territory coverage. Improving these metrics increases revenue without requiring proportional increases in headcount or spend. In EBITDA terms, the growth component of the profitability equation improves without a corresponding increase in operating costs. Revenue efficiency improvements are margin expansion, even when they get reported as CRO wins.

The mechanics are straightforward. A sales cycle that closes 30 days faster means the rep capacity already on payroll generates more bookings per quarter. A conversion rate that improves from 18% to 22% at the opportunity-to-close stage means the same pipeline investment produces more revenue. A retention rate holding at 110% net revenue retention means expansion from existing accounts is compounding rather than absorbing churn. Each of these is an EBITDA input, because the cost structure generating those outcomes stays roughly flat while the revenue output grows.

Deloitte research found that B2B organizations using RevOps were 1.4 times as likely to exceed their revenue goals by 10% or more compared to organizations that had not built the function. That is a revenue efficiency finding with an operating leverage interpretation. The companies getting more revenue out of the same GTM investment produce better EBITDA margins as a byproduct.

The cost structure lever

GTM technology sprawl is a near-universal condition in SaaS. Over 64% of companies report owning more than ten revenue tools, with at least half acknowledging meaningful functional overlap. The problem compounds because sales, marketing, and customer success teams often make independent purchasing decisions, resulting in duplicate capabilities, fractured data, and license costs that accumulate without clear ROI tracking.

RevOps owns the governance architecture that determines whether that sprawl exists or gets controlled. When a RevOps team conducts a disciplined tool audit, the savings are both operational and financial. Companies that merge SaaS contracts duplicating CRM or automation functions show 25 to 30% annual savings on that portion of the stack. For a company running two to three million dollars in annual GTM technology spend, that is a material EBITDA improvement from a single operational decision.

Gartner has consistently found that marketing leaders use only about a third of their available technology capabilities on average, while most organizations face pressure on technology budgets. Companies are paying full license cost for tools used at partial capacity, often because RevOps does not own the full vendor relationship or renewal calendar. When it does, the rationalization potential is significant.

The cost structure lever extends beyond technology. RevOps owns the operational processes that determine headcount productivity, and headcount productivity is a direct EBITDA input. A sales representative who takes seven months to reach full quota productivity creates a larger drag on operating expense per dollar of revenue than one who ramps in four months. Onboarding quality, playbook clarity, CRM usability, and enablement infrastructure all influence that ramp trajectory. The difference between a four-month ramp and a seven-month ramp, across a cohort of ten new hires, is an operating expense calculation.

Automation decisions carry similar weight. Routing logic that eliminates manual qualification steps, contract workflows that remove administrative friction from AE time, renewal processes that do not require customer success managers to chase information across disconnected systems. These determine how much labor cost is embedded in each dollar of pipeline produced. RevOps controls the architecture of those workflows.

The forecasting lever

This is the lever that gets the least attention and carries the most consequence.

Sales forecasting accuracy sits squarely in RevOps ownership. The methodology for how pipeline is staged, how probability is assigned, how weighted pipeline is calculated, how forecast calls are structured, how commit and best-case distinctions are defined. All of this flows from the processes and systems that RevOps builds and maintains. When the forecast is accurate, the business makes calibrated decisions about hiring, spend, and investment. When it is optimistic, the consequences accumulate on the operating expense side of the P&L in ways that are very difficult to reverse.

Gartner has found that fewer than half of sales leaders have high confidence in their own forecasts. Research from SiriusDecisions puts the proportion of sales organizations missing their forecast by more than 10% at 79%. These numbers describe the normal condition for most go-to-market organizations, and the operational consequences of systematic forecast inaccuracy are predictable. An overstated forecast generates overinvestment. Leadership sees a number in the pipeline model and makes resource decisions based on it. Hiring approvals get tied to revenue projections. Marketing spend gets planned against a bookings outlook. Infrastructure investments get approved based on a capacity requirement the forecast implies. When the revenue does not materialize, the spending already has. The headcount is on payroll. The campaigns have run. The tools have been purchased. EBITDA absorbs the gap.

The technology correction of 2022 and 2023 produced a set of public case studies that illustrate this mechanism with unusual specificity. Salesforce entered that period having grown its headcount from roughly 50,000 to nearly 80,000 employees in approximately three years, scaling in response to the demand acceleration the company was experiencing. When conditions shifted, CEO Marc Benioff wrote to employees that the company had “hired too many people leading into this economic downturn we’re now facing.” The restructuring that followed carried charges estimated between $1.4 billion and $2.1 billion, with approximately $800 million to $1 billion recorded in a single quarter.

Okta’s situation made the causal chain explicit. The company’s CEO wrote that Okta had entered fiscal 2023 with a growth plan based on the demand experienced in the prior year, and that this led the company to overhire for the macroeconomic reality that followed. Okta reduced its global workforce by 5% in early 2023, then made a second reduction of approximately 7% the following year as part of a broader restructuring focused on operating efficiency and profitable growth. HubSpot’s CEO characterized the situation in similar terms, noting that the company came into 2022 anticipating a slowdown from 2021’s pace but experienced a faster deceleration than expected. The workforce had grown more than 40% between the end of 2020 and early 2023. The layoffs that followed cut 7% of the company.

Each of these situations followed the same sequence. Demand signals were strong. Pipeline looked robust. Hiring and spending decisions were made based on those signals. The signals proved optimistic. The cost structure built on top of them had to be unwound at significant expense, in both restructuring charges and the less visible costs of institutional knowledge loss and recovery time.

RevOps owns the forecast methodology that generates the signals these decisions are built on top of. A RevOps organization that enforces stage exit criteria, models conversion rates against historical actuals rather than rep optimism, maintains clean CRM data, and pressure-tests the difference between commit and best-case pipeline is producing signals more likely to be accurate. A RevOps organization that allows pipeline inflation, accepts stale or unvalidated data, or does not hold forecast inputs to a consistent methodology is producing signals with more noise. The hiring decisions, marketing investments, and infrastructure approvals sit downstream. The forecast quality sits upstream, inside the processes RevOps governs.

The Rule of 40 as context

There is a metric that describes the intersection where RevOps operates, and it is the one investors and CFOs use most commonly to evaluate SaaS company health. The Rule of 40 states that a company’s annual revenue growth rate plus its EBITDA margin should equal or exceed 40%. A company growing at 30% with 10% EBITDA margins clears the threshold. A company growing at 50% with a negative 5% margin also clears it. The specific combination matters less than the principle: sustainable SaaS businesses balance growth and profitability, and the rule provides a single number capturing that balance.

Companies consistently clearing 40% command meaningfully higher valuation multiples. Analysis of public SaaS companies scoring above 40% on a weighted Rule of 40 basis shows median enterprise value to revenue multiples of approximately 12.4 times. The structural reason for that premium is operating leverage: businesses that demonstrate they can grow without requiring proportional cost increases to generate each additional dollar of revenue. That is precisely what disciplined RevOps infrastructure produces.

RevOps is one of the few functions in a B2B SaaS company with genuine operational leverage on both sides of this equation simultaneously. The growth rate component responds to revenue efficiency: pipeline quality, conversion rates, cycle time, expansion revenue. The EBITDA margin component responds to cost structure decisions: headcount productivity, technology spend, automation depth, ramp time, and the accuracy of forecasts that determine how the cost base gets scaled. Finance governs the margin denominator through budget oversight. Sales leadership governs the growth numerator through quota and coverage. RevOps, when it is functioning well, influences both.

What practitioners can take from this

A RevOps team that understands the EBITDA connection will prioritize forecast accuracy differently than one that views it purely as a CRO deliverable. Forecast accuracy determines whether the business makes spending and hiring decisions on reliable information. The methodology that produces accurate forecasts typically includes rigorous stage definitions, clean conversion tracking, historical actuals-based calibration, disciplined pipeline review. It is the same methodology that protects operating expense from being scaled on a faulty signal.

Technology governance looks different through this lens as well. Tool sprawl carries a direct line item consequence. License costs for underused tools, administrative overhead for redundant integrations, data quality degradation from fragmented systems eventually accumulate into real operating expense. Stack rationalization is compression of a cost center.

Process improvement projects carry a productivity ratio interpretation. Faster ramp times affect the revenue-per-employee metric directly. Better conversion rates improve the unit economics of every dollar the business spends on go-to-market. Automation that replaces manual administrative work reduces the labor embedded in each unit of pipeline produced.

The companies that made the most visible errors during the 2022 and 2023 correction did so in part because their cost structures scaled ahead of demand signals that did not hold. The methodology for how pipeline is staged, how probability is assigned, how weighted pipeline is calculated, how forecast calls are structured, and how commit and best-case distinctions are defined all flow from the processes and systems that RevOps builds and maintains. Renewal processes that do not require customer success managers to chase information across disconnected systems all reduce how much labor cost is embedded in each dollar of pipeline produced. Those forecasts, in a well-structured RevOps organization, belong to RevOps.

There is no clean counterfactual for what more rigorous pipeline methodology would have produced at those specific companies during an unusual macro period. Revenue conditions shifted in ways that were genuinely difficult to anticipate. But the organizations that build accurate forecasting infrastructure, maintain disciplined conversion tracking, and hold pipeline data to a high standard enter any correction with better information. They can respond earlier, size adjustments more precisely, and avoid the compounding cost of an overbuilt structure requiring correction at scale.

RevOps practitioners have built significant organizational credibility over the past decade by demonstrating that operational discipline translates into revenue outcomes. The translation of that argument into EBITDA terms describes the same work through the lens of the P&L that governs every resource decision in the business. The levers are already in RevOps hands. The framing is what most practitioners have not yet made explicit.

Members download the RevOps EBITDA Impact Calculator. Put in your ARR, your conversion rate, your average ramp time, and how far your forecasts typically miss. Get back a dollar figure showing what your RevOps function is actually worth to operating profitability across revenue efficiency, cost structure, and forecast accuracy. Includes a before-and-after Rule of 40 score. Four tabs, fully editable, pre-populated with SaaS benchmarks so it works on first open.

Read more

Getting both meetings right requires understanding what each one is actually trying to accomplish, who should be in the room, and what the outputs look like when done well. This article walks through the mechanics of each, where teams tend to go wrong, and how to structure both so they actually generate signal rather than status theater.

The core distinction

The WBR is an operational meeting. Its job is to keep the revenue machine running from week to week. It surfaces what’s working, what’s not, and what needs to be fixed before it becomes a bigger problem. The QBR is a strategic meeting. Its job is to explain what happened over the prior quarter, why it happened, and what the team is doing differently as a result.

These are fundamentally different cognitive tasks.

The WBR asks: are we on track, and if not, what do we do right now?

The QBR asks: what patterns emerged, what do they tell us, and how do we change course?

Mixing these together produces meetings where people argue about one rep’s pipeline on a Tuesday morning for forty-five minutes while the strategic question of why win rates are declining goes unaddressed.

The meeting rhythm also serves different functions within the organization. WBRs are primarily internal revenue team meetings. QBRs are cross-functional by nature and often include finance, product, and the executive team. The audience changes the story you need to tell.

The weekly business review

Amazon’s WBR is probably the most referenced version of this meeting in the tech industry, and for good reason. The company runs a structured weekly review across nearly every business unit with a defined pre-read document and a strict norm that no one reads slides out loud during the meeting. Time is reserved for discussion, not narration. That principle alone would improve most WBRs I’ve seen.

For a B2B SaaS revenue team, the WBR has a specific job: pulse check the pipeline, flag at-risk revenue, track activity execution, and resolve operational friction before it compounds. Here’s how I’d structure one.

Opening metrics (10 minutes)

Start with where you stand on the quarter’s number. This means current bookings vs. target as of the current week, pipeline coverage against what remains in the quarter, and a simple forecast update reflecting what’s changed since last week. The purpose is not to analyze these numbers yet. It’s to make sure everyone in the room has the same starting point before diving into detail. The forecast update should include a call from the RevOps lead on what’s changed, what’s at risk, and what’s accelerated. If there’s a meaningful delta from last week’s call, surface the reason explicitly.

Pipeline review (15-20 minutes)

This section covers deals currently active in the pipeline. The goal is not a rep-by-rep deal review, which most teams confuse for a WBR. That’s a coaching meeting, and it belongs in a separate weekly sales call. What the WBR needs is a view of pipeline movement at the stage level. How many deals advanced? How many stalled or slipped backward? What’s the concentration risk in late-stage pipeline? Are there clusters of deals expected to close this quarter that haven’t had meaningful activity in the last two weeks?

The WBR should also flag any deals that have been sitting in the same stage beyond the expected sales cycle average. If your average deal takes 45 days to move from stage two to stage three, and you have ten deals that have been in stage two for 60 days, that’s a signal worth discussing in the meeting. The discussion isn’t about blaming reps. It’s about whether there’s a systemic issue: a product capability gap, a pricing conversation that keeps stalling, a competitor that keeps showing up at the same stage.

Forecast integrity check (10 minutes)

Forecast accuracy is one of the most valuable lagging indicators RevOps can track, and the WBR is where you actively maintain it. This section should cover any deals that have moved in or out of the current quarter commit, along with the reason for the change. It should also flag any gaps between what CRM shows and what managers are calling verbally. If a manager is calling $200K in commit but the CRM shows $140K in stage four, someone needs to explain the delta.

Slippage from prior forecasts also belongs here. Deals that were in the prior week’s commit and didn’t close should be tracked explicitly. Not as a punitive measure, but because slippage patterns tell you something about how the team forecasts. Consistent optimism bias in one segment or one manager’s book is something you want to catch at week six of a quarter, not on the last day.

At risk revenue (10 minutes)

This is often the section that gets skipped in shorter WBRs, but it’s arguably the highest-value conversation in the meeting. At-risk revenue covers both open pipeline that may slip and existing customer revenue that may be at risk of contraction or churn. For teams with meaningful expansion or renewal responsibility, the WBR should include a quick view of any accounts with open red flags: support ticket escalations, low product adoption signals, executive sponsors who’ve gone dark, or contracts renewing within 60 days that haven’t started the conversation.

The point is not to resolve these situations in the WBR. It’s to surface them, assign an owner, and agree on a next action. A good WBR generates a short, specific action list from this section. If you leave without any owner on an at-risk account, the meeting wasn’t operational enough.

Activity and pipeline creation metrics (10 minutes)

The WBR should include a look at the activity metrics that feed the pipeline, not just the pipeline itself. This means new pipeline created in the prior week vs. target, outbound activity volume, inbound lead response times, and sequence or campaign performance if your team runs outbound at scale. These are leading indicators, and they’re the most actionable data in the meeting because they reflect decisions and behaviors you can change this week rather than this quarter.

Teams often skip this section because it feels granular. That’s the wrong read. If pipeline creation is trending below target in week four of twelve, you have enough runway to make a course correction. If you catch it in week ten, you don’t.

Operational and systems issues (5-10 minutes)

The final section of the WBR belongs to RevOps, and it’s specifically the plumbing. This is where you surface routing failures, CRM data gaps, tool outages, sequence errors, or any operational issue that’s degrading sales execution. Most of these issues are invisible to sales leadership unless someone surfaces them deliberately. A deal that didn’t route to the right rep, a sequence that sent the wrong email to a prospect, a territory overlap that’s generating conflict between two AEs. These aren’t big strategic issues, but left unaddressed they erode execution and create data quality problems that haunt you in the QBR.

WBR format principles

The WBR should run between 45 and 75 minutes. If it’s consistently running over, the problem is usually either scope creep (turning deal reviews into coaching sessions) or lack of a pre-read. The pre-read is the single most important operational lever for a high-quality WBR. Every attendee should have reviewed the metrics dashboard and the key updates before the meeting starts. Time in the room is for discussion, not data narration.

Attendees should include the RevOps lead, the head of sales (or their VP equivalent), the leaders of any SDR or BDR function, the head of marketing if there’s significant inbound, and the head of customer success if renewal or expansion revenue is material. The meeting doesn’t need the full sales team. It needs decision-makers.

One output document matters: the action list. Every open issue that surfaces in the WBR should leave with an owner and a due date. Ideally this is a short shared document that carries over week to week, so items from last week’s meeting are reviewed at the top of this week’s. This creates continuity and closes the loop on what was actually resolved.

The quarterly business review

The QBR operates at a different altitude. Where the WBR is about keeping the machine running, the QBR is about evaluating whether the machine is the right one, running in the right direction, at the right speed.

A well-run QBR answers four questions: What happened this quarter? Why did it happen? What are we changing? And are we set up to execute the next quarter? Everything in the QBR is downstream of those four questions.

Start with the number

Every QBR opens with final attainment. Bookings vs. target, new logo vs. expansion vs. renewal broken out, and net new ARR added in the quarter. These numbers should be presented with two comparisons: prior quarter and the same quarter in the prior year. A single data point tells you almost nothing. The trend is what matters.

Segment the attainment down to SMB, mid-market, and enterprise if your business runs multiple motions. A 97% quarter can hide an enterprise segment that was 130% and a mid-market segment that was 65%. Understanding where you’re over- and under-performing is more actionable than the aggregate number.

Waterfall analysis

If you take nothing else from this article about QBR structure, build the waterfall slide. It shows beginning pipeline, pipeline created in the quarter, deals won, deals lost, deals slipped, and ending pipeline in a single view. It’s the most powerful way to tell the story of a quarter because it shows both what happened to pipeline and why the number landed where it did.

Most teams show a static snapshot of pipeline and then show a win rate number separately. Those two views don’t connect. The waterfall connects them. If you started with $8M in pipeline against a $3M target and only hit $2.4M, the waterfall shows you whether the gap was driven by slippage into next quarter, higher-than-expected loss rates, or smaller average deal sizes. The cause matters for what you do next.

Pipeline and funnel analysis

After the waterfall, go a level deeper into funnel health. Stage-by-stage conversion rates tell you where deals are dying and whether that’s changing quarter over quarter. Average sales cycle length by segment shows whether deals are getting faster or slower to close, which has compounding implications for capacity planning. Average deal size trends reveal whether discounting is creeping up, whether the ICP is drifting, or whether there’s a mix shift in the business.

The question to answer in this section: were the conditions right for the team to succeed? Pipeline coverage entering the quarter, ICP fit in the pipeline, and lead quality all influence outcomes in ways that pure activity metrics don’t capture. If your team was set up to cover 2.5x against quota and they hit 94%, that’s a different story than if they entered at 1.8x coverage and hit 89%.

Forecast accuracy review

This section often feels uncomfortable, but it’s one of the most important diagnostic tools in the QBR. Commit accuracy at the rep level and the manager level shows you how well the team understands their own pipeline. If the delta between called and closed is consistently large, that’s a process problem, and it usually lives somewhere in how opportunities get qualified, staged, or reviewed.

Track slippage rate explicitly. What percentage of deals in the prior quarter’s commit pushed into this quarter? Chronic slippage is one of the most common signs of qualification problems or stage definition problems in the CRM. It often looks like a sales execution issue when it’s actually a RevOps process issue.

Win/loss analysis

Win rate overall should be compared against prior quarters, not just called out as an absolute number. Where this section gets genuinely useful is in competitor-level win rates. If you’re winning 60% of deals when you’re aware of a competitive situation and 38% when a specific competitor is involved, that’s actionable product and enablement input. If your average deal size in wins is significantly higher than in losses, that tells you something about your ICP fit and where the product resonates.

The most underanalyzed category in most win/loss reviews is “no decision.” Deals lost to no decision are almost never discussed as rigorously as deals lost to a competitor, but they’re often more informative. A no-decision outcome usually means the prospect didn’t believe the problem was important enough to prioritize, or the champion couldn’t build internal consensus. Both of those have direct implications for how you qualify, which personas you pursue, and what your economic justification materials need to accomplish.

Rep and team performance

Quota attainment distribution gives you a clearer picture of team health than average attainment. A team where 65% of reps are at or above quota is in a meaningfully different position than a team where 40% of reps are at quota but two large deals inflated the average. Show the distribution in bands: above 100%, 75 to 99%, 50 to 74%, and below 50%. That view tells you whether you have a tail problem, a middle problem, or a top performer concentration problem.

Ramp performance for new hires deserves its own lens. If your ramp model assumes full productivity at nine months and new hires are tracking at 40% of plan at month seven, you need to know that now, not when they miss their first full-quota quarter.

Capacity and coverage

This is where RevOps makes its most direct case to leadership. Current headcount vs. plan, open roles and their expected close dates, territory coverage against total addressable accounts, and whether the pipeline load per rep is appropriate for the current team size. If you’re carrying ten open AE roles against a headcount plan that assumed those roles would be filled by month two of the quarter, the capacity gap has revenue implications that need to be quantified and presented.

Process and systems health

RevOps owns this section of the QBR completely. It’s the credibility section, and most RevOps teams underinvest in it. CRM data quality scores, process compliance rates, tool adoption metrics, and automation performance all belong here. If 40% of closed opportunities are missing key qualification fields, that matters for next quarter’s win/loss analysis. If your routing automation misfired on 8% of inbound leads, that has revenue impact.

This section is also where you surface what you’re changing operationally next quarter. New scoring models, changed stage definitions, updated routing logic, or qualification improvements all get announced here, along with the expected outcome.

Forward-looking planning

The final third of the QBR should cover the coming quarter. Pipeline entering Q+1 and what coverage ratio that represents against the new quota target. Key initiatives, the owner of each, and the expected outcome. Hiring plan with realistic ramp assumptions. Risks that could derail execution before the quarter starts. And the specific asks that RevOps needs from sales, marketing, finance, and product to execute well.

One principle that improves QBRs significantly: name owners on every initiative. Vague organizational ownership (”we will improve data quality”) doesn’t generate accountability. A named owner and a measurable outcome (”Maria will implement the new required fields by week two of Q3, targeting 90% completion rates on closed won”) does.

How the two meetings work together

The WBR and QBR aren’t separate mechanisms. They’re the same operational system running at different time horizons. What surfaces as a weekly operational issue in the WBR should be feeding into the QBR analysis. If slippage was a recurring WBR topic in Q2, that pattern should show up in the Q2 QBR forecast accuracy review.

The most effective RevOps teams maintain a living issues log that carries from WBR to WBR through the quarter, and that log becomes one of the core inputs to the QBR. When you can show that a specific problem was identified in week three, discussed in WBRs through week eight, and resolved with a specific operational change, that’s a mature operating cadence. It demonstrates that the WBR isn’t just a status meeting. It’s a feedback loop.

The QBR, in turn, should generate the strategic inputs that change what gets tracked in the WBR. If the QBR reveals that no-decision losses are accelerating, the next quarter’s WBR should include a track on late-stage stall patterns. If the QBR shows that mid-market pipeline creation was 30% below target in Q2, the WBR gains a new standing agenda item on mid-market outbound activity metrics.

Where teams go wrong

The most common WBR failure is turning it into a deal review. Once the meeting becomes a venue for managers to coach reps on specific opportunities, it stops being a business review and starts being a performance management meeting. That’s a different meeting with a different purpose.

The most common QBR failure is presenting data without narrative. A QBR full of charts and metrics that no one has organized into a coherent story generates a lot of discussion but few decisions. The RevOps lead presenting the QBR should be able to summarize the quarter in three or four sentences before any slides go up: what the number was, whether it was good, what drove the result, and what’s changing next quarter. If you can’t do that, the QBR deck isn’t ready.

The second most common QBR failure is spending too much time on what happened and not enough on what’s changing. A reasonable split is 60% retrospective and 40% forward-looking. Teams that run 90% retrospective QBRs produce great historical analysis and no real action.

The operational foundation

Both meetings depend on the same underlying capability: clean, accessible data in a CRM that reflects actual sales activity. That sounds obvious, but the majority of WBR failures and QBR failures trace back to data problems. If your stage definitions are loose, your conversion rate analysis is meaningless. If reps aren’t logging activities in the CRM, your pipeline health scores are guesswork. If forecast categories aren’t consistently applied, your forecast accuracy review is measuring noise.

Before you invest in improving the format of either meeting, audit whether the underlying data is actually trustworthy. A well-structured WBR with bad data is still a bad meeting. The format matters, but the foundation matters more.

The WBR template for this issue gives you a structured pre-read dashboard and action tracker you can adapt to your team’s stack. It includes weekly metric snapshots, a pipeline movement tracker, a rolling slippage log, and an action item registry that carries forward week to week. Download the template 👇

Read more

The problem almost never lives in the methodology itself. MEDDICC is a well-proven framework for qualifying complex B2B deals, and the logic of tracking metrics, economic buyer access, decision criteria, decision process, implicated pain, champion strength, and competitive position is sound. The problem lives in the implementation layer, specifically in how the scoring infrastructure gets built, maintained, and enforced in Salesforce.

This article is about collapsing that implementation gap using Claude Code and a GitHub-based deployment workflow that any RevOps practitioner can operate without a Salesforce developer on retainer.

Why the standard implementation approach breaks

The typical MEDDICC build in Salesforce starts with an admin creating seven or eight custom text fields on the Opportunity object, grouping them on the page layout, and maybe adding a formula field that calculates a rough completion percentage. That’s the first hour. The next forty to sixty hours, spread across weeks, go toward building out validation rules to enforce stage gates, Apex classes to calculate weighted scores, dashboard components to surface deal health to managers, and the page layout adjustments that make the whole thing navigable for reps in the flow of a real sales conversation.

The weight of that build usually falls on whoever owns Salesforce in the RevOps function. If there’s a dedicated admin, it competes with every other project on their backlog. If RevOps is wearing the admin hat themselves, it means nights and weekends in a sandbox environment, referencing Apex documentation, and debugging formula logic that breaks silently.

Even when the build gets done well, the resulting org configuration lives nowhere permanent. Changes made through the Salesforce UI exist in the org and only in the org. If someone deletes a field, misconfigures a validation rule, or if the company ever migrates to a new Salesforce instance, the work disappears or has to be reconstructed from memory. There’s no source of truth, no version history, and no way to audit what changed or when.

This is the underlying architecture problem that Claude Code and Salesforce DX together solve.

What Salesforce DX and Claude Code actually give you

Salesforce DX is Salesforce’s modern development framework. Instead of making configuration changes through the Setup UI and hoping they survive, SFDX lets you represent your entire org configuration as code files stored in a project directory. Custom objects, custom fields, Apex classes, validation rules, page layouts, and permission sets all become structured files that live in a GitHub repository, get reviewed in pull requests, and get deployed through a defined pipeline rather than through point-and-click configuration that’s invisible to anyone who wasn’t watching.

Claude Code connects to that SFDX workflow through the Salesforce DX MCP server, which is Salesforce’s implementation of the Model Context Protocol. The practical effect is that Claude Code can query your org’s schema, generate correctly formatted metadata files for the Salesforce CLI to deploy, write Apex classes with correct syntax and bulkification patterns, and run sf commands directly against your org without you leaving the terminal. More usefully for practitioners who aren’t daily Salesforce developers, it uses the current sf CLI syntax rather than the deprecated sfdx commands that most AI assistants still hallucinate, because it’s connected to your actual org context rather than operating from training data alone.

The combination gives RevOps something that hasn’t existed before in an accessible form: a workflow where you describe what you want your MEDDICC implementation to do in plain language, Claude Code generates the Salesforce metadata and Apex logic to accomplish it, that code gets committed to GitHub, and deployment happens through a validated pipeline rather than direct org manipulation.

The architecture of a well-built MEDDICC scoring system

Before touching Claude Code, it helps to be clear about what you’re actually building. A complete MEDDICC scoring implementation in Salesforce has three distinct layers that need to work together.

The first layer is the data model. This means custom fields on the Opportunity object for each MEDDICC element, plus the fields that support scoring. A mature implementation distinguishes between the qualitative text fields where reps capture their notes (what are the customer’s success metrics, who is the economic buyer, what does the decision process look like) and the scoring fields that managers or automated logic use to rate the quality of what’s been captured. A simple implementation uses picklist fields rated one through five for each element, which can then roll up into a weighted composite score. A more sophisticated version uses formula fields that read the text fields and apply completeness logic, combined with manual confidence ratings that managers enter during deal reviews.

The second layer is enforcement logic. This means Salesforce validation rules that prevent opportunities from advancing past specific stages without minimum MEDDICC completion thresholds, and optionally Apex triggers or flows that fire when a field is updated to recalculate the composite score and alert managers when a deal’s qualification is deteriorating. The stage gate approach is where most implementations add genuine value, because it forces the qualification conversation to happen during the deal rather than as a retrospective data entry exercise.

The third layer is visibility. This means a report or dashboard component that surfaces MEDDICC health across the pipeline, ideally at both the individual deal level for rep coaching and the aggregate level for pipeline review. In Salesforce, this comes down to reports built on the Opportunity object using your scoring fields, and the Lightning record page layout configured so that the MEDDICC section and the composite score are visible without reps having to scroll.

Claude Code can generate the Salesforce metadata files for all three layers. The repo you’re about to build will contain each piece as a deployable file.

Setting up the project

The starting point is a Salesforce DX project initialized in VS Code or your terminal, connected to Claude Code, and linked to a GitHub repository. If you haven’t set up the Salesforce DX MCP server, you authenticate it once through the Claude Code settings, pointing it at your Salesforce CLI credentials. From that point forward, Claude Code can query your org’s metadata directly in the session.

The project structure that the RevOps Impact template repo provides follows the standard SFDX layout. The force-app/main/default/ directory is where all the deployable metadata lives, organized by metadata type. Custom objects go in objects/, Apex classes in classes/, validation rules in objects/Opportunity/validationRules/, and so on. The config/ directory holds the scratch org definition file that GitHub Actions uses when creating temporary test environments.

The CLAUDE.md file in the project root is where you capture context that persists across Claude Code sessions. For a MEDDICC build, this is where you document your scoring model decisions (are you using a simple completion percentage or a weighted model that treats Economic Buyer and Champion as more critical than Decision Criteria?), your stage gate rules, and your org’s specific naming conventions. Claude Code reads this file at the start of each session, which means you don’t have to re-explain your implementation decisions every time you open the project.

Building the MEDDICC fields and scoring logic

With the project structure in place and Claude Code connected to your sandbox, you start by describing the data model you want. A prompt like “create custom field metadata for all seven MEDDICC elements on the Opportunity object, including both a long text area field for qualitative notes and a one-to-five picklist field for scoring each element, following Salesforce naming conventions” will produce correctly formatted XML files in the objects directory that the SFDX CLI can deploy directly.

The composite score field is a formula field that reads the seven individual score picklists, converts them to numbers, applies any weighting you’ve defined, and outputs a total out of one hundred. This is where Claude Code earns its place in the workflow: you describe the weighting logic you want (champion and economic buyer weighted at twenty percent each, metrics and identified pain at fifteen percent each, decision criteria and decision process at twelve percent each, competition at six percent), and it generates the Apex formula or the formula field syntax correctly the first time. Anyone who has written a multi-condition formula field in Salesforce from scratch knows that getting the syntax right across seven nested IF and TEXT functions is tedious work that Claude Code handles in seconds.

The validation rules follow the same pattern. You describe the stage gate logic: no opportunity can advance from Discovery to Solution Alignment without the Metrics and Identified Pain score fields being populated. No opportunity can move to Negotiation without a composite MEDDICC score above sixty-five. Claude Code generates the validation rule XML files for each gate, with the error messages written in the language your sales team will actually understand rather than the Salesforce field API names that end up in most validation rule error messages.

If you want an Apex trigger that recalculates the composite score automatically when any individual score field is updated, rather than relying on a formula field, that’s a separate prompt. An Apex trigger handler follows a specific pattern in well-built Salesforce orgs, with a handler class that separates the logic from the trigger itself and handles bulk operations correctly. Claude Code generates this using the trigger handler pattern by default when you specify that the class should follow Salesforce best practices for bulkification, which matters because validation rules and scoring triggers fire across every record in a batch operation, not just one deal at a time.

Committing and deploying through GitHub Actions

Every file Claude Code generates gets committed to the GitHub repository before it touches a real Salesforce environment. This is the operational shift that makes the whole approach worth adopting. Your MEDDICC implementation is now a versioned artifact. If a field gets accidentally deleted from your Salesforce org, you can redeploy it from the repo. If a new CRO wants to adjust the weighting model, that change happens in a pull request with a clear record of what changed and why.

The GitHub Actions workflow in the template repo handles two scenarios. When you open a pull request against the main branch, the action authenticates against your sandbox org using an SFDX auth URL stored as a GitHub secret, runs sf project deploy validate against the changed metadata, and executes your Apex test classes. If validation passes, the pull request can be merged. When you publish a release, a separate workflow deploys to production.

Setting up the GitHub secret requires one command in your terminal: sf org display --verbose run against your target org, which surfaces the SFDX auth URL. You store that value in the repository’s secret settings, and the GitHub Actions workflow references it without that credential ever appearing in your codebase or workflow logs.

The Apex test class for your MEDDICC scoring logic is something Claude Code can generate alongside the implementation itself. A good test class for a scoring trigger creates Opportunity records with various combinations of MEDDICC field values, asserts that the composite score calculates correctly for each combination, and verifies that validation rules fire appropriately at each stage gate. Salesforce requires seventy-five percent Apex code coverage before any class can be deployed to production, and the test class handles that requirement rather than blocking your deployment.

The CLAUDE.md approach to maintaining the implementation

The CLAUDE.md file is what separates a one-time build from a maintainable system. For a MEDDICC implementation, your CLAUDE.md should capture the scoring model and weights so that Claude Code can generate consistent logic when you’re extending the system months later, the naming conventions you’ve adopted for fields and classes, the stage gate rules and the rationale behind them (which matters when a sales leader pushes back and you need to explain why the sixty-five percent threshold exists), and the branching strategy you’re using for the GitHub repository.

With a well-maintained CLAUDE.md, extending the system is a prompt rather than a development project. If your VP of Sales decides to add a Paper Process element to create a MEDDPICC variant, you describe that addition, Claude Code generates the new field, updates the composite score formula, adjusts the validation rules, and creates the test methods. The deployment pipeline handles the rest. The whole change takes less time than the original ad hoc implementation would have taken just to create the fields.

What this changes for RevOps

The value of this approach isn’t that it makes MEDDICC scoring in Salesforce faster to build the first time, though it does. The value is that it creates an implementation model that RevOps can own, maintain, and extend without depending on a developer or fighting for admin queue time.

Every revenue leader has experienced the version of this problem where a well-designed qualification system slowly degrades because changes require a ticket, the ticket waits two weeks, and by the time the fix ships, the sales team has already found a workaround. A GitHub-backed, Claude Code-assisted implementation changes the maintenance model: RevOps describes the change they want, reviews the generated metadata, and deploys through a pipeline that enforces testing before anything reaches production.

The repo scaffold in the RevOps Impact paid member resource gives you the project structure, the CLAUDE.md template with the MEDDICC-specific context already documented, the GitHub Actions workflow files for validation and deployment, and placeholder Apex classes with commented descriptions of what Claude Code should generate for each one. The intent is that you fork it, open it in Claude Code, and the article becomes the narrative layer on top of something you can actually run.

That’s the shift worth paying attention to. The qualification methodology has always been available. The infrastructure to enforce it has always been buildable. What’s changed is that the skill gap between knowing what you want to build and being able to build it has gotten small enough for RevOps to close it themselves.

My Research for this article includes:

MEDDICC in Salesforce — implementation patterns and failure modes

• https://www.demandfarm.com/blog/how-to-implement-meddic-in-salesforce/

• https://www.gorattle.com/blog/the-revops-guide-to-meddic-adherence-in-salesforce

• https://www.oliv.ai/blog/meddic-sales-methodology

• https://www.campfiresolutions.io/blog/implementing-meddpicc-sales-process-on-salesforce

Claude Code and Salesforce DX

• https://www.salesforceben.com/10-lessons-for-admins-using-claude-code-to-build-salesforce-flows/

• https://www.jthathapudi.com/blog/setting-up-salesforce-dx-mcp-with-claude-code-in-intellij

• https://developer.salesforce.com/blogs/2025/06/introducing-mcp-support-across-salesforce

• https://github.com/ehebert7/salesforce-claude-framework

GitHub Actions and Salesforce deployment pipelines

• https://developer.salesforce.com/blogs/2020/01/using-salesforce-dx-with-github-actions

• https://www.salesforceben.com/build-your-own-ci-cd-pipeline-in-salesforce-using-github-actions/

• https://www.kylecapehart.com/posts/github-actions/

GitHub repo👇

Read more

The problem Figma faced is not a Figma problem. It’s the default state for most SaaS companies at scale. Customer success teams manage dozens or hundreds of accounts simultaneously, and the information they need to identify expansion opportunities is fragmented across four or five systems that were never designed to work together. This is the post-sales data problem, and it is the central infrastructure challenge that separates CS organizations that find expansion opportunities reactively from those that find them systematically.

Where the signals actually live

To understand why this problem is so persistent, it helps to map where customer intelligence actually sits after a deal closes. Product usage data, how frequently accounts log in, which features they activate, how many users they onboard, whether they are approaching plan limits, lives in product analytics or in the application database itself. Support data, the tickets they submit, the escalation patterns, the product areas generating friction, lives in a separate ticketing system. CRM data, the contract terms, renewal dates, account owner history, previous expansion conversations, lives in Salesforce or HubSpot. Conversation intelligence, the QBR notes, the call recordings, the customer sentiment signals from executive interactions, lives in Gong or Chorus or a notes field that gets updated inconsistently.

This frankenstack is pretty much the standard architecture of a mid-market or enterprise SaaS company, and they mean that a CS manager who wants to know whether an account is ready for an expansion conversation has to manually pull information from at least three or four different places to get a complete picture. At the account volumes most CS teams manage, that manual process does not happen. CSMs work from what they remember, from the last QBR notes they can find quickly, and from the renewal date on the calendar. Expansion opportunities that are visible in product data but not surfaced to the people who could act on them simply go undetected.

The Insight Partners 2023 post sales GTM report put the structural consequence plainly: customer intelligence lives in too many places with no single institutional address, which makes it difficult to generate an accurate view of the customer, manage risk effectively, or identify expansion opportunities. That observation captures the core dysfunction. It is not that the data does not exist. It is that the data cannot be assembled into an actionable view without significant manual effort, and that effort is rarely built into how CS teams operate.

What expansion signals actually look like

Before solving the infrastructure problem, it is worth being precise about what an expansion signal is and why it differs from the health score most CS teams already have.

A health score aggregates lagging indicators. It tells you whether a customer is satisfied with the product today, based on NPS scores, support ticket volume, and login frequency. Those inputs matter, but they are not expansion signals. An expansion signal tells you something specific about near-term revenue potential. There are a few distinct types.

Seat utilization signals indicate when an account is approaching or has exceeded its current plan capacity. When a team that licensed fifty seats has forty-eight active users and is onboarding new hires, that is not a health metric. It is a sales conversation waiting to happen. The account is functionally over capacity and likely to need more seats within a quarter. Docker tracked exactly this kind of signal: when an account hit its maximum number of concurrent builds, an automated alert went to the account owner with context about what was happening, allowing the rep to frame the conversation around the customer’s real, demonstrated bottleneck rather than a generic upsell pitch.

Feature adoption signals indicate when an account has not yet activated capabilities they have already paid for, or when their usage patterns suggest they would get measurable value from a higher-tier plan. An account that has licensed a product primarily for one use case and is showing behavioral patterns consistent with a second use case is signaling cross-sell readiness without saying so explicitly.

Organizational spread signals indicate when a product that was licensed for one team is being used by people across multiple business units or departments. At Figma, this was core to their expansion model. When individual users from the same company signed up separately for the freemium product, those accounts needed to be connected to the parent company and surfaced to the account executive as a consolidation opportunity. Without automated infrastructure to do that work, it happened inconsistently or not at all.

Velocity signals indicate a sudden change in usage patterns, either a spike that suggests new adoption or a drop that suggests a problem. Both are actionable. A usage spike from a team that was dormant for two quarters might mean a new initiative is underway that creates expansion potential. A usage drop across a team that has been active for eighteen months is a retention risk that warrants outreach before the renewal conversation.

The infrastructure pattern that works

Companies that have solved the post-sales data problem tend to share a common architectural approach. Product usage data is captured at the event level, either through a customer data platform or directly from the application, and flows into a central data warehouse. The data warehouse is where the signal logic actually lives: the scoring models, the account hierarchy unification, the threshold calculations. Reverse ETL then pushes the processed data and derived signals from the warehouse into the CRM and CS platforms where teams are already working, along with the automated alerts and task assignments that translate signals into action.

Figma’s implementation is the clearest documented example. Their Sales Ops team built a unified account hierarchy in the data warehouse to connect individual users to their parent organizations, which solved the organizational spread problem immediately. They pushed product usage data into Salesforce through Census, their reverse ETL layer, so that account executives could see engagement levels across an account without leaving the CRM. They built a customer health score model from first-party product data rather than from lagging satisfaction metrics. And they set up automated workflows to notify account owners when customers reached key milestones or when usage patterns crossed thresholds relevant to expansion or risk. The Sales Ops team reported a tenfold improvement in sales team productivity once this infrastructure was in place, and crucially, that gain came almost entirely from eliminating the manual work of assembling customer context before every interaction.

The technical components of this architecture are now relatively mature and available to most SaaS companies without custom engineering. What remains difficult is not the data plumbing. It is the signal design: deciding which events to track, which thresholds are meaningful, how to weight different signals into a score, and how to route alerts to the right person given the account’s tier and motion. That design work is where most CS operations fall short, and it is where a post-sales GTM engineer earns the investment.

Why the health score is not enough

Many CS teams have invested in health scores and believe they have solved the problem. They have partially solved a different problem. Health scores are defensive instruments. They tell you which accounts are at risk so you can intervene before churn. That is genuinely valuable, but it does not surface expansion opportunities in the way that product signal infrastructure does.

The distinction matters for how CS teams allocate time. A CSM working from a health score list will spend most of their attention on red and yellow accounts, the ones at risk of churning. A CSM working from an expansion signal system can simultaneously identify which green accounts have the product usage patterns that indicate they are ready for a growth conversation. Those two workflows require very different data, and most health score implementations do not surface the second kind at all.

The practical consequence is that expansion revenue gets discovered mainly through renewal conversations and periodic QBR cycles rather than through systematic signal detection. At accounts with annual contracts, that means potential revenue sits uncaptured for months while usage patterns that would have justified an expansion conversation were visible in the product data but invisible to the CS team.

Evaluating your own architecture

There is a straightforward way to assess whether your current post-sales infrastructure can surface expansion signals reliably. It comes down to four questions.

First, can a CSM see, within the tools they use daily, how any given account is using the product right now? If the answer requires opening a separate product analytics dashboard, logging into a second system, or requesting a report from a data analyst, the signal is not operationalized. It exists somewhere, but it is not reaching the people who could act on it.

Second, does your CS or sales team receive an automated notification when an account crosses a usage threshold that indicates expansion potential? Seat utilization approaching a plan limit is the clearest example. If that event happens and no one is alerted, the organization is leaving timing to chance.

Third, is your account hierarchy in the CRM accurate at the organizational level? For PLG companies especially, individual users from the same company often exist as disconnected records with no link to a parent account. If the CRM does not reflect organizational reality, expansion conversations about consolidation or broader adoption are functionally impossible to run systematically.

Fourth, how are expansion signals currently routed? When a product event indicates that an account might be ready for a growth conversation, does a specific person receive a specific task, or does the information exist in a dashboard that someone has to remember to check? Routing is where most signal implementations break down in practice. Data visibility without workflow automation produces dashboards that inform rather than action.

If the honest answer to most of these questions is that your team lacks the infrastructure, that is not a failure of the CS team. It is a design problem. Customer success managers are not product data engineers, and the expectation that they will manually assemble cross-system context for a hundred accounts is the root cause of why expansion revenue is discovered inconsistently at most companies. The infrastructure work to fix it is a RevOps and engineering responsibility, not a CSM accountability.

The scale problem

One reason expansion signal infrastructure has not been prioritized the way pre-sales pipeline infrastructure has is that the cost of not having it is hard to see. A company without good outbound signal infrastructure sees a measurable shortfall in pipeline. A company without good post-sales signal infrastructure just has expansion revenue that arrives when it does, concentrated in renewal cycles, rather than consistently throughout the year. The revenue still comes in. It is just less than it could be, and that delta is nearly impossible to quantify without knowing what signals were missed.

The clearest proxy for the problem’s size is NRR. Companies with net revenue retention above 120 percent are almost universally running systematic expansion motions rather than relying on CSM relationships and renewal timing to surface upsell opportunities. When High Alpha’s 2024 SaaS benchmarks report documented that the share of ARR coming from expansion grew from 28.8 percent in 2020 to 32.3 percent in 2023, it reflected a structural shift in how durable SaaS businesses generate growth. Expansion revenue is no longer a secondary motion. At the companies with the strongest unit economics, it is a primary one, and those companies have built the infrastructure to run it as such.

The infrastructure Figma built starting in 2018 is now table stakes for a well-run SaaS business above a few hundred accounts. Getting there requires a clear technical architecture, deliberate signal design, and someone with the capability to build and maintain both. The second article in this series covers what that playbook looks like in practice: which signals to prioritize, how to build the scoring model, and how to design the routing logic that turns product data into revenue action.

Paid members get access to a new template:

• Signal infrastructure audit - The four diagnostic questions from the article turned into a scored self-assessment with red/yellow/green scoring

• Expansion signal catalog - Reference sheet listing the four signal types (seat utilization, feature adoption, org spread, velocity) with example triggers and recommended actions

• Signal routing design - A worksheet for mapping which signals go to which team (CSM, AE, or automated motion)

• Account data quality audit - A quick tool to assess CRM account hierarchy health

Read more

The infrastructure behind these workflows is built and maintained by GTM Engineers. The first article in this series covered what the role is, where it sits in the org, and how it relates to RevOps. This piece focuses on what GTM Engineers build for marketing teams specifically, and how the signal infrastructure they create is reshaping the way pipeline gets generated. For marketing leaders evaluating whether to invest in this function, understanding the practical applications is where the conversation should start.

The signal landscape for marketing

GTM Engineers work with six broad categories of signals, each with distinct marketing applications.

Website visitor identification is the most common starting point. Companies like Factors.ai use waterfall enrichment across multiple data vendors to identify up to 75% of anonymous website visitors at the account level, compared to the 8 to 10% industry standard. When a visitor hits a pricing page, competitor comparison page, or integration documentation, the GTM Engineer’s system captures the account, checks it against ICP criteria, and routes it to the appropriate marketing workflow.

Champion job change tracking is widely considered the highest converting signal in B2B. Roughly 20% of CRM contacts change jobs each year. When a former customer or power user moves to a new company, a well built system detects the move, checks whether the new company matches ICP criteria, enriches the record with current firmographic data, and triggers a coordinated response. Segment’s sales development team automated this process after years of SDRs doing it manually through LinkedIn, and saw immediate pipeline impact.

Hiring signals reveal company priorities and budget allocation in real time. A company posting for three Salesforce administrators when they’re currently running HubSpot could be evaluating a migration. Vanta layers CISO job postings alongside their other signals because a company hiring its first dedicated security leader is a strong indicator that compliance tooling purchases will follow. Each job posting reflects a decision that already passed internal budget approval, which makes hiring data one of the more reliable public signals available.

Funding and corporate event signals correlate with increased technology purchasing. Series B and later rounds, acquisitions, leadership transitions, and new office openings all tend to precede tool evaluation cycles. These signals are widely available through Crunchbase, press coverage, and SEC filings.

Third party topic intent tracks when accounts show surging research activity around topics relevant to your product category. Bombora aggregates this data from a cooperative of 5,000+ B2B publisher websites, and platforms like G2 and TrustRadius provide category level research signals. This data reveals early to mid funnel buying behavior that is difficult to detect through your own properties alone.

Product usage signals apply to companies with PLG or hybrid motions. Trial signups, feature adoption patterns, usage thresholds, and expansion indicators all feed marketing workflows for conversion and upsell campaigns.

Bloomberry’s analysis of 1 million B2B software purchases found that companies adopting enterprise AI tools, making recent tech stack changes, and rapidly growing headcount were the strongest predictors of future software purchasing. The research also found that individual signals carry moderate predictive value, while signal combinations produce significantly stronger results. An account showing topic surge on G2, a pricing page visit, and a recently hired champion represents a fundamentally different targeting opportunity than any one of those signals in isolation.

What GTM Engineers build for marketing

The signal categories above are inputs. What GTM Engineers construct with those inputs are marketing systems that run continuously and adjust automatically based on account behavior.

Dynamic audience sync is one of the most impactful builds. When a contact visits a pricing page or shows research behavior, the GTM Engineer’s system adds that contact to a LinkedIn ad audience. These audiences update in real time as signals change, so ad spend stays concentrated on accounts showing active interest. Vector, a contact level intent platform, reports that signal based ad audiences produce 3%+ click through rates, which is a meaningful improvement over standard B2B campaign benchmarks. The automation runs both directions: when a signal expires (the account stops showing research behavior), the contact gets removed from the audience, which keeps spend efficient.

Suppression list automation solves the perennial problem of marketing to existing customers or open opportunities. A GTM Engineer builds a system that syncs CRM data to ad platforms continuously, ensuring that accounts with active deals, closed won customers, and contacts on do not contact lists are excluded from paid campaigns automatically. The underlying complexity is significant: it requires real time data flow between the CRM, the ad platform, and the signal layer, with logic that handles edge cases like accounts with both an open opportunity and a separate expansion target.

Triggered nurture sequences mapped to research behavior represent another common build. When an account consumes content about a specific use case, the system enrolls relevant contacts in a nurture track tailored to that topic. When an account visits competitor comparison pages, a different sequence activates that surfaces differentiation content and relevant case studies. The GTM Engineer constructs the detection logic, the routing rules, and the integrations between the signal source, the CRM, and the marketing automation platform.

Coordinated multi channel responses bring these individual components together. A single signal, such as a champion joining a new company, can trigger ad enrollment for the new account, a personalized email from the account executive referencing the existing relationship, a Slack notification to the sales team with a pre built account brief, and an update to the CRM record. Companies like Rippling and Cursor run these coordinated plays regularly. The GTM Engineer’s role is to build the orchestration layer that connects the signal source to every downstream action and ensures the timing, sequencing, and personalization logic holds together reliably.

Why this matters for pipeline economics

The financial pressure driving investment in signal infrastructure is straightforward. The 2025 Benchmarkit report found that companies are spending roughly $2 in sales and marketing to earn $1 of new ARR, a 14% increase from the prior year. CAC is rising across the board, and the traditional response of adding headcount or increasing ad budgets faces diminishing returns at most growth stage companies.

Signal infrastructure changes the math because it redirects existing spend toward accounts showing active buying behavior. Conversion rates improve because the targeting gets more precise, even when marketing budgets hold steady. Signal based outbound consistently produces 3 to 5x higher response rates than static list outbound, according to multiple practitioners building these systems. The improvement comes from reaching the right person at the right company at the right moment, which is a timing and targeting problem that signal infrastructure is specifically designed to solve.

For marketing leaders, this reframes the resource conversation. The investment in a GTM Engineer (or the agency equivalent) pays for itself through improved efficiency on existing spend, which is a more tractable budget conversation than requesting incremental campaign dollars. Verkada’s growth team, which reports to the CMO, uses GTM Engineers to automate roughly 80% of SDR workflows, which effectively scales pipeline generation capacity without proportional headcount growth.

The compound effect matters too. Every signal workflow a GTM Engineer builds continues running and producing pipeline after the initial build. A champion tracking system, once constructed, monitors your entire customer contact database indefinitely. An ad audience sync, once connected, optimizes spend continuously. The ROI calculation is heavily weighted toward ongoing value, which makes the initial investment in signal infrastructure increasingly favorable over time.

Building signals without the enterprise price tag

Most writing about signal based marketing assumes you’re purchasing Bombora at $30K+ annually, 6sense at $50K+, or a comprehensive Clay deployment. These platforms are powerful, and companies with the budget and team to operationalize them see strong results. For teams earlier in the signal journey or operating with leaner budgets, four of the six signal categories can be covered with publicly available data, low cost APIs, and automation scripts.

Hiring and funding signals are the most accessible. Serper, a Google Search API, charges $0.001 per search. A script that runs daily queries across your target account list looking for new job postings, funding announcements, and leadership changes costs pennies per day. For 1,000 target accounts monitored daily, the total Serper cost runs roughly $30 to $50 per month. PredictLeads offers a dedicated jobs dataset API at lower price points than full intent platforms, and Google Jobs indexes most major job boards. Pair these data sources with an LLM that classifies whether each job posting signals buying intent for your product category, and you have a functional hiring signal system for under $100/month.

Champion job change tracking has vendor options at multiple price points. LinkedIn Sales Navigator ($99/month) provides native job change alerts for saved leads. Apollo.io ($49/month for basic) surfaces job changes for contacts in your database. The coverage and automation from these lower cost options won’t match dedicated platforms like UserGems, which reports 95% match accuracy. For a team monitoring 500 to 2,000 champion contacts, these tools will still catch 40 to 60% of moves. The gap is in the downstream automation: Sales Nav tells you about the change and stops there. It doesn’t automatically enrich the new company, check ICP fit, or trigger a workflow. A GTM Engineer (or a RevOps professional building with Claude Code) fills that gap by connecting the data source to the CRM and marketing automation platform.

Website visitor identification is harder to replicate cheaply because it requires IP to company resolution databases. IPinfo ($99/month for their business tier) includes company data and provides a reasonable starting point. The identification rate will be lower than dedicated platforms, likely 15 to 25% versus 75%. It still captures the highest value visits when combined with UTM tracking and form enrichment for known visitors.

Product usage signals cost nothing beyond your existing analytics infrastructure. If you have a PLG motion, the raw data already exists in Amplitude, Mixpanel, or your data warehouse. The build is a script that queries your usage data for expansion indicators: accounts approaching usage limits, teams adding users rapidly, or feature adoption patterns that historically correlate with paid conversion. This is one of the most underutilized signal categories because it requires internal data engineering work that nobody has prioritized.

The one signal category that genuinely requires vendor investment is third party topic intent. Bombora’s value comes from their publisher cooperative, which is a proprietary data asset that cannot be replicated independently. The budget alternative is building a proxy for intent using search based monitoring. Serper queries for company names combined with competitor names, product category terms, or solution keywords can reveal which companies are actively publishing about or publicly discussing problems your product solves. Monitoring relevant subreddits, Stack Overflow tags, or industry communities for company mentions adds another layer at zero cost. The volume and precision will be lower than a dedicated intent platform. It still surfaces publicly visible research behavior that indicates active problem solving in your product category.

A practical stack covering five of six signal categories runs under $500/month: Serper for search based signals ($50), Apollo for contact enrichment and job change tracking ($49), IPinfo for visitor identification ($99), Crunchbase for funding signals ($29), LinkedIn Sales Navigator for champion monitoring ($99), and your own product data piped through automation scripts. The total comes to roughly $325/month, with room in the budget for additional API calls or supplementary data sources.

Where to start

The most consistent advice from practitioners building signal based marketing systems is to start with one signal and build a complete workflow around it before expanding. Teams that try to operationalize ten signal types simultaneously tend to fail at all of them because each signal requires its own detection logic, enrichment step, routing rules, and response playbook.

The two most common starting points are website visitor identification and champion job change tracking. Both produce a manageable signal volume (20 to 50 signals per week is a reasonable starting target), both show clear intent behavior, and both have obvious next actions when the signal fires.

Three criteria help determine which signal to prioritize. Volume matters because you need enough signals to learn what works while keeping the workflow manageable for your team. Intent level matters because signals showing deep research behavior (pricing page visits, competitor comparison activity, integration documentation consumption) convert at higher rates than casual browsing patterns. Actionability matters because every signal needs a defined response: who acts on it, how quickly, and with what message. A signal without a clear playbook is just noise.

Once you’ve selected your first signal, build the complete chain: detection (where does the signal come from and how do you capture it), enrichment (does the account match your ICP, and who are the right contacts), action (what marketing workflow triggers, and what does sales receive), and measurement (did this signal produce pipeline, and at what conversion rate). Proving that one signal reliably generates pipeline creates the internal case for expanding to additional signal categories.

Preparing your ops foundation

Signal infrastructure produces results proportional to the quality of the data and processes it connects to. A few operational elements need to be in place before signal workflows deliver consistent value.

Clean CRM data is the foundation. Signals that hit dirty records produce bad routing, duplicate outreach, and missed opportunities. A GTM Engineer’s audience sync is only as good as the suppression lists it references, and those suppression lists are only accurate if the CRM reflects current customer status, deal stages, and contact preferences. If your CRM completeness rate is below 80% on critical fields like email, company, lifecycle stage, and owner, start there.

ICP criteria need to be defined in a way that can be evaluated programmatically. A signal fires, and the system needs to decide within seconds whether the account qualifies for a marketing response. That decision requires firmographic thresholds (employee count, industry, revenue range, geography) that exist as structured data, which means the criteria live in your CRM or data warehouse as queryable fields.

Response SLAs between marketing and sales ensure that signals get acted on before they go stale. Practitioners recommend defining response windows by signal type. Champion job changes warrant 24 hour response times because the window of influence is short. Funding round signals can tolerate 72 hours because the resulting evaluation cycle takes months to unfold. These SLAs give both teams clear expectations and make it possible to measure whether the signal infrastructure is producing timely action.

The GTM Engineer builds the signal detection and automation layer. RevOps maintains the data quality, process governance, and measurement infrastructure that makes each signal actionable and accountable. Both functions are essential to making signal based marketing work reliably.

What comes next

Signal infrastructure is becoming a baseline expectation for marketing teams competing for the same accounts in crowded categories. The companies building these systems today are compounding their advantage with every workflow they deploy, because each automated signal workflow continues generating pipeline indefinitely after the initial build.

For most marketing teams, the practical path forward is to select one high value signal, build a complete workflow around it, measure the pipeline impact, and use those results to justify expanding the infrastructure. Whether that expansion takes the form of a dedicated GTM Engineer hire, an agency engagement, or continued self building with lower cost tooling depends on your team’s technical capacity and growth stage.

Paid members get the $500/month signal stack setup guide, including a six tab Excel workbook with ready to use Serper query templates, page level intent scoring matrices, champion response playbooks, signal combination weights, and escalation tiers with specific marketing and sales actions for each. The workbook pairs with working Python scripts for hiring signal detection, champion job change monitoring, and composite scoring, plus a complete workflow configuration template mapping every signal type to CRM properties, ad audience rules, and automation triggers. Open the Stack Overview tab and you'll have your implementation plan and budget breakdown in under a minute.

Read more

Wallet share is a simple concept in theory. You take a customer’s current ARR, divide it by what they could theoretically pay you, and you get a percentage. Low percentage means room to grow. High percentage means you have either succeeded or saturated. The hard part is the denominator. “What they could theoretically pay you” is not a single number with a single formula. It is a calculation that depends entirely on how you charge, and most B2B companies have not made that calculation explicit.

This article is about building a rigorous, practical approach to wallet share measurement across the pricing models you are most likely to encounter. The framework works whether you are a RevOps practitioner trying to build it for your own company or a revenue leader trying to understand where to focus a team of AEs.

Why ARR alone does not tell you where you stand

Revenue operations evolved from the recognition that a company’s commercial data deserves the same rigor applied to its operational data. We track pipeline coverage ratios, forecast accuracy, sales cycle length, and quota attainment. But most RevOps teams track ARR in a way that is fundamentally backward-looking. ARR tells you what a customer decided to pay in the past. It does not tell you what they could pay next.

Net revenue retention is the closest most companies get to a forward-looking signal. NRR above 100% means expansion is outpacing churn within the existing base. NRR below 100% means it is not. But even strong NRR numbers mask a critical question: expansion relative to what? If a customer is growing their contract by 15% per year but represents only 20% of their potential spend with you, that account is underperforming your opportunity regardless of how good the NRR looks.

Total Addressable Wallet, or TAW, is the theoretical maximum a given customer could pay you given their current business size, structure, and needs. Wallet share is the ratio of their current ARR to their TAW. A customer at 30% wallet share is an expansion candidate. A customer at 85% wallet share needs a different conversation, one about strategic alignment, referrals, upsell into adjacent products, or the terms of a long-term renewal.

The reason most RevOps teams do not calculate TAW is that it feels like guesswork. And without a clear methodology, it is. With one, it becomes a defensible estimate you can put in a CRM field, connect to a quota model, and use to run territory planning. The methodology starts with the pricing model.

The pricing model determines everything

B2B companies do not have one pricing model. They have several, often running in parallel across different product lines or customer segments. Each model implies a different TAW calculation, a different set of observable signals, and a different expansion motion. Getting wallet share right means knowing which model governs each part of each customer relationship.

Unit throughput models price on discrete events or outputs. Blend Labs, a mortgage origination platform, charges banks and credit unions a per-application or per-funded-loan fee. A regional bank processing 2,000 mortgage applications per month has a TAW ceiling defined by its origination volume multiplied by the per-unit rate. The RevOps question is: what is the bank’s total origination volume, and what share of those transactions flows through Blend? A customer with 5,000 monthly applications running 1,000 through your platform is at 20% wallet share. The TAW calculation here is straightforward because the unit of value is the same unit the customer already tracks for their own business purposes. Volume data is observable, at least directionally, from deal structure, renewal conversations, and public data sources.

Veeva’s OpenData product represents a more complex variant. Veeva sells pharmaceutical companies access to healthcare professional contact data, pricing by country based on the number of HCP records in that country. A pharma company expanding into five European markets pays a summed fee based on record counts per country. Their TAW ceiling is the total number of HCP records globally in markets where they sell. As that company enters new geographies, the TAW expands with them. This dynamic means RevOps teams at companies like Veeva need to track not just current ARR but also the customer’s geographic expansion plans, because that is the leading indicator of TAW growth.

Application and module count models are common in enterprise software where the platform covers a defined set of functional areas and each area is licensed separately. Imubit, an industrial AI company focused on oil refinery optimization, illustrates this clearly. Imubit deploys closed-loop AI optimization applications against discrete process units inside refineries: a fluid catalytic cracker, a reformer, a crude distillation unit, a blending header. Each is a separate application, and each delivers measurable margin improvement of roughly $0.30 to $0.50 per barrel processed through that unit. A refinery with 12 optimizable process units that has deployed three Imubit applications sits at 25% wallet share. The TAW is the total number of optimizable units multiplied by the contract value per application.

What makes this archetype particularly tractable for RevOps is that the ceiling is physically bounded. You can count the process units at a refinery. You can cross-reference Imubit’s own customer documentation, which cites Big West Oil and Monroe Energy as customers with multiple deployed applications. The expansion path is visible from outside the account.

Veeva Vault operates on the same logic in life sciences. Each Vault application covers a distinct regulatory or content management function: QualityDocs, Vault RIM for regulatory submissions, Vault Clinical for trial management, Vault PromoMats for marketing materials, Vault Safety for pharmacovigilance. A mid-size pharma company running two Vault modules with a regulatory and quality infrastructure that justifies four more has low wallet share by application count, regardless of what their ARR looks like in absolute terms. The expansion opportunity is hiding in plain sight.

Seat-based models are the most familiar to RevOps practitioners. The TAW formula looks simple: relevant headcount multiplied by price per seat. The complexity is in the word “relevant.” HubSpot’s Sales Hub, priced at $90 per seat per month at the Professional tier, is not relevant to every employee at a customer company. It is relevant to quota-carrying sales representatives, sales managers, and potentially sales operations professionals. At a 500-person company with 80 salespeople, TAW on Sales Hub is 80 times $90 times 12, not 500 times anything.

This matters because RevOps teams often define TAW loosely as total headcount. That overstates the ceiling, making wallet share look artificially low and driving misallocated expansion effort. The right denominator for seat-based TAW is role-specific headcount, which changes as the customer’s hiring plans evolve. A customer that has told you they are building out a 30-person enterprise sales team is signaling TAW expansion before it shows up as revenue. That conversation belongs in CRM as structured data, not in an email thread.

Salesforce represents the extreme of this archetype. Enterprise tier pricing has reached $500 per seat per month at the top of the stack, and Salesforce’s growth over recent years has been meaningfully driven by per-seat price increases rather than net new customers alone. Their shareholders see this plainly in the annual reports. For RevOps teams selling into organizations that run Salesforce, the competitive analysis has to account for how much budget is already committed to that line item.

Outcome and performance-based models create the most dynamic TAW calculations because the ceiling moves with the customer’s own results. PROS Holdings, which sells revenue management and CPQ software to airlines and B2B distributors, structures enterprise contracts to share in the margin improvement their platform generates. As a customer’s yield improves or their quote-to-win rate increases, the value of the platform grows, and in well-designed outcome contracts, the vendor’s revenue grows with it.

The RevOps challenge here is that TAW is not calculable from a fixed formula. A prospect’s current revenue base, their pricing maturity, and their willingness to link payment to performance all affect the number. What you can model is a scenario range: conservative case based on industry-average improvement rates, base case based on their current operational data, upside case based on the best outcomes their peer set has achieved. That range is more defensible than a single point estimate and more useful for forecasting.

Cass Information Systems operates a structurally similar model in freight audit and payment. Cass handles freight invoice processing and payment for large manufacturing and retail shippers, charging a percentage of the freight spend they manage. A customer routing $50 million in annual freight through Cass pays a take rate on that spend. As the customer’s business grows, TAW grows automatically. Cass processes over $40 billion in freight payments annually, which means their TAW across the customer base grows with the economy rather than requiring any deliberate expansion motion.

Site and location-based models are common in operational technology sold to multi-location businesses. Toast, the restaurant point-of-sale platform, prices on a per-location basis starting at $69 per month per restaurant, with additional modules layered on top. A restaurant group with 45 locations that runs Toast at 12 of them is at 27% wallet share by location count, and the TAW calculation is simply total location count times the monthly per-location contract value. Toast serves over 106,000 restaurant locations and tracks location expansion rate as its primary growth metric in investor communications. This is a clean, observable ceiling.

Samsara, the fleet and operations management platform, operates the same way but with vehicles and fixed assets as the unit. A logistics company with 400 trucks that has Samsara deployed on 150 is at 37.5% wallet share. TAW is total fleet size times contract rate per vehicle. Fleet size is generally discoverable through public records, customer conversations, or industry databases.

Transaction volume models are the defining structure of API-native businesses. Twilio prices SMS at $0.0083 per message sent or received in the US, with similar per-event pricing across voice, WhatsApp, and video. A company sending 500,000 customer alerts per month is paying roughly $4,000 per month on SMS alone. TAW is their total anticipated message volume across all channels times the applicable rate. Twilio’s consistently above-120% net dollar retention is not magic. It is the mathematical consequence of a pricing model where customer growth and vendor revenue grow together automatically. The challenge for RevOps teams at Twilio-type businesses is that TAW has no fixed ceiling. It scales with the customer’s own product engagement, which means the expansion signal is usage volume growth, not seat count or module gaps.

Snowflake operates the same way, charging on compute credits consumed and storage per terabyte. A data team running light analytical workloads pays far less than one running heavy transformation pipelines on large datasets, and Snowflake’s revenue grows as data volumes and query complexity increase. In Snowflake’s case, TAW is estimated by understanding the customer’s current data architecture and where it is heading, which is why their sales motion is so deeply technical.

AUM and portfolio-based models are concentrated in financial services technology. Addepar, the wealth management platform for RIAs and family offices, charges between 0.008% and 0.03% of assets under management. A firm managing $220 million in assets pays roughly $65,000 annually. TAW is AUM times the applicable basis-point rate. Addepar’s own research, published in a Sacra analysis of their business, shows they manage $7 trillion in assets across approximately 1,200 client firms. The RevOps complexity here is that AUM fluctuates with markets. A customer whose portfolio falls 20% in a down quarter is not using the platform any less, but their TAW shrinks mechanically. This creates a structural mismatch between the effort required to retain a customer and the revenue that customer generates, which means renewal conversations have to account for market conditions as an exogenous variable in the TAW calculation.

Record and data volume models price on how much data a customer manages within the platform. HubSpot’s Marketing Hub is the most visible example. Professional tier starts at $890 per month and includes 2,000 marketing contacts. Contacts above that threshold are charged in tiers. A company with 80,000 contacts in their database has a clearly defined TAW ceiling based on how many they are actively managing through HubSpot. ZoomInfo operates similarly, pricing on the number of records and contact exports a customer can access annually. Customers who are consistently hitting their export limits are the clearest expansion signal in a data volume model, because they are demonstrating that the contracted ceiling is below their actual need.

How to detect which model applies

Most companies know their own pricing model. The problem for RevOps is detecting it on the customer side when you are looking at CRM data rather than a pricing sheet. The signals are usually there.

Deal amount distribution tells you a great deal. If contract values cluster around predictable multiples of a base number, you are almost certainly in a seat or module model. If they spread across a continuous range, you are more likely in a usage or throughput model. Run a distribution of your ACV across your book of business and look at the pattern.

Line item structure in your CPQ or billing system is even more direct. If your quotes contain quantity fields that customers fill in with headcount or unit counts, you are in a seat or unit model. If quotes contain commitment tiers with overage clauses, you are in a usage model. If every quote is a flat platform fee, you are in a tier model. The structure of what you sell is the structure of your TAW formula.

Renewal versus expansion ratios within the customer base reveal the model behavior over time. Module and application models tend to show larger expansion jumps at discrete intervals, when a customer adds a new application rather than gradually increasing usage. Seat models show smoother, more incremental expansion correlated with the customer’s hiring cycles. Usage models show expansion that is continuous and correlated with the customer’s own product activity.

For customers where you do not have visibility into the underlying signals, the deal naming conventions your AEs use often encode the model implicitly. A deal named “Acme Corp - 45 Seats - Enterprise” is different from “Acme Corp - FCC Unit - Phase 2” in ways that tell you exactly which formula applies.

Building wallet share into the RevOps motion

Calculating TAW is not a one-time exercise. It is a data field that belongs in CRM, updated on a cadence, and connected to how you prioritize accounts, set quotas, and run renewals.

The practical starting point is a TAW field per account, ideally with a confidence score alongside it. A seat-based TAW calculated from a customer’s LinkedIn headcount has lower confidence than one calculated from a signed MSA that specifies headcount. An application-based TAW estimated from public documentation has lower confidence than one discussed explicitly in a QBR. Tracking confidence lets you know where to invest in better data and where to trust the estimate you have.

Account prioritization changes materially when wallet share is available. The accounts worth investing expansion effort in are those sitting in the 20% to 40% wallet share range, where there is meaningful room to grow and the customer has demonstrated value fit by continuing to pay. Accounts below 20% wallet share need diagnosis before expansion conversation: low share could mean the product is not being used, the champion has left, or the customer made a smaller initial commitment than expected. Accounts above 80% wallet share need a different conversation entirely, focused on retention, strategic partnership, or cross-sell into adjacent products.

Forecast accuracy improves when deals are cross-referenced against TAW. An AE projecting a $500,000 expansion on an account with a $600,000 TAW ceiling is sizing the deal correctly relative to what is available. The same AE projecting $1.2 million expansion on the same account is either miscalculating TAW, or there is a product or pricing change implicit in the deal that should be made explicit. Automated flags on deals that exceed TAW are a straightforward RevOps build that catches forecast errors before they propagate into the board-level number.

Churn risk signals also change shape through a TAW lens. A customer at 95% wallet share who is not showing signs of growth is not necessarily a churn risk, but they are a saturation risk. They have bought nearly everything they can buy at their current scale. If their business is not growing, your revenue from that account is effectively flat for the foreseeable future. If their business is growing, they need a conversation about the next product tier or the next product line, not just an annual renewal. The wallet share number surfaces this before the renewal lands on someone’s desk as a surprise.

QBR preparation becomes more targeted when wallet share is in the room. A customer at 30% wallet share needs a conversation about what gaps look like and what the path to the next application or module would require. A customer at 75% wallet share needs a conversation about their growth plans and how you can grow with them. Those are structurally different QBRs, and the difference starts with knowing the number before walking in.

What good looks like

The best wallet share implementations share a few characteristics. They treat TAW as an estimate with an explicit confidence tier rather than a precise number, because precision here is often false precision. They update the estimate on a quarterly cadence, or faster when a triggering event occurs: a customer acquisition, a hiring announcement, a new market entry, a product expansion on their side.

They connect TAW to quota assignment and territory planning. An AE given an account with 80% wallet share has less expansion capacity than one given an account with 25% wallet share, and compensation models should reflect that rather than treating all accounts as equivalent in their growth potential.

They build model-specific detection logic into CRM. If a deal has a quantity field with a value, it is a seat or unit deal. If it has a commitment tier and overage rate, it is a usage deal. Tagging deals at creation forces clean data from the start rather than trying to back-fill it later.

They also account for multi-model customers. HubSpot is the clearest example of why this matters. A single HubSpot customer can span Marketing Hub priced on marketing contacts, Sales Hub priced on seats, Service Hub priced on seats, and Operations Hub priced on seats. Each has a different TAW formula and a different ceiling. Total wallet share for that customer is the sum of four separate calculations, not a single number. Companies that sell multiple product lines at different pricing structures need to run TAW at the product-line level and roll it up to the account level.

Finally, the best implementations treat TAW as a living input to expansion planning rather than a reporting artifact. A customer who announces they are opening 15 new locations is signaling TAW expansion before the contract conversation begins. A customer who publishes a job posting for a new sales operations leader is signaling seat demand before an AE has dialed in. Connecting external signals to TAW estimates, systematically and not just in ad hoc account reviews, is what separates companies that catch expansion opportunities early from those that discover them at renewal.

The math behind wallet share is not complicated. Tracking AUM times basis points or fleet size times vehicle rate is not a difficult calculation. What is difficult is the discipline of deciding which formula applies to which customer, building that into CRM cleanly enough that it can be queried and acted on, and using it consistently enough that it becomes part of how your team thinks about accounts rather than a dashboard metric that gets referenced once a quarter.

The companies that do this well do not have better software than the ones that do not. They have made a decision about what information matters for account prioritization and built the habit of keeping it current. That is a RevOps decision first, and a technology decision second.

Paid member download: Wallet Share Calculator

This workbook does the math across all eight pricing archetypes covered in this article. Enter your current ARR and four account-level inputs, and it calculates Total Addressable Wallet, wallet share percentage, and expansion capacity instantly. The Portfolio View tab rolls up to 60 accounts into a ranked prioritization list with action signals built in. There’s also a Model Selector tab that tells you which archetype applies to a given customer and what data you need to calculate their TAW, plus a Reference Guide with the TAW formula, expansion signals to watch, and confidence scoring guidance for each model.

If you’ve been sizing expansion opportunities off ARR alone, this is the tool that shows you what you’ve been missing.

Read more

Compensation at top-tier companies now sits between $175,000 and $250,000, with Vercel, OpenAI, and LILT AI all posting roles above $220,000. ZoomInfo data shows hiring for the role has doubled year over year for the past two years, with peaks in January and July.

Companies like Rippling, Ramp, Verkada, Notion, Canva, Intercom, and Anthropic have all begun building dedicated GTM Engineering functions, and the pace is accelerating. This is a job category that barely existed in 2023.

The useful questions at this point are why it’s happening now, what it actually looks like inside the companies building it, and how to determine whether your organization is ready for it.

What a GTM Engineer Actually Does

The simplest way to describe the role is that a GTM Engineer identifies friction points across the buying journey and builds automated systems to eliminate them.

That might sound like RevOps or growth engineering, and it is related to both. The difference is in orientation. RevOps professionals manage and optimize existing systems: keeping CRM data clean, building dashboards, managing lead routing, and ensuring that sales, marketing, and customer success teams are aligned on process. GTM Engineers focus on building new automated infrastructure. They architect workflows, connect data sources through APIs, deploy AI agents for enrichment and outreach, and design programmatic campaigns that scale without adding headcount. Both functions are valuable. They serve different purposes within the revenue organization.

The role requires both technical skill and commercial understanding. These are people who can write Python and SQL, build custom integrations, and work with AI models, and who also understand pipeline metrics, sales cycles, and buyer behavior. They care about meetings booked and cost per opportunity.

Where the role lives inside an organization varies. At Ramp, it sits within a Growth Platform squad that runs two-week sprints, shipping internal prospecting tools and AI outreach flows alongside a separate Business Systems group that manages Salesforce. At Verkada, GTM Engineers report into the Growth team under the CMO, where their charter spans personalized ABM landing pages to automating the majority of SDR workflows. At Rippling, the function lives within both the international and US growth teams, running frequent experiments that include automating outbound and direct mail campaigns.

The common thread is that GTM Engineers operate like a product engineering team embedded within the revenue organization. They write specs, ship prototypes, run sprints, and measure outcomes.

The Forces That Created This Role

Three converging pressures explain why this function is emerging now.

The first is that the traditional SDR led growth model has hit diminishing returns. Customer acquisition costs have risen steadily across B2B SaaS. The average sales team spends a significant portion of its time navigating fragmented tools, syncing data between systems, and performing manual research. Inboxes are saturated. Cold outreach conversion rates have dropped. The economics of adding more reps to generate more pipeline have deteriorated to the point where many companies can no longer justify it.

The second pressure is the arrival of AI as a practical GTM tool. Tasks that used to require hours of manual effort (researching a prospect, enriching a lead record, personalizing an email, scoring intent signals) can now be automated in minutes. Realizing that potential requires someone with the technical ability to wire the systems together and the commercial awareness to know which problems are worth solving. The GTM Engineer is the role that combines both.

The third force is stack sprawl. The average GTM team now runs 15 or more tools: CRM, enrichment providers, sequencing platforms, intent data sources, analytics dashboards, and more. These tools often don’t communicate with each other. Data lives in silos. Personalization at scale becomes nearly impossible when every workflow requires manual intervention to connect inputs to outputs. GTM Engineers build the connective tissue between these systems, turning a collection of disconnected tools into a unified revenue infrastructure.

The result is a growing emphasis on systems led growth. Forward-thinking revenue leaders are starting to think in terms of leverage ratios: how much output per headcount dollar invested. GTM infrastructure is becoming a competitive advantage in its own right.

The RevOps Relationship

One of the most common questions about GTM Engineering is whether it replaces RevOps. The short answer is no. Almost every company that has built a GTM Engineering function already had RevOps in place first.

The longer answer requires some nuance.

GTM Engineering evolved out of RevOps. The earliest practitioners were RevOps managers, CRM admins, and growth-minded operators who began experimenting with automation tools and AI workflows. By late 2025, what started as ad hoc experimentation had matured into a formal engineering discipline. The trajectory mirrors how marketing automation evolved a decade ago, from scattered experiments into a permanent organizational capability.

An analysis of over 1,000 job postings found that nine out of ten responsibilities listed in GTM Engineer roles also appear in RevOps postings. The overlap is real. Both roles touch CRM systems, data enrichment, process design, and pipeline management. The distinction shows up in emphasis. RevOps job postings tend to lead with CRM ownership, treating it as the foundation of the role, and include explicit responsibilities around sales forecasting accuracy. GTM Engineering postings center on automation, integration, and optimizing outbound and prospecting systems.

The relationship model emerging at most organizations positions GTM Engineers as architects who design and deploy new automated workflows, with RevOps teams integrating those workflows into existing processes, monitoring performance, and handling ongoing optimization. The two functions are complementary.

There is a provocative counter-narrative worth noting. Some leaders in the space argue that if you were building a revenue team from scratch today, you would hire a GTM Engineer before a RevOps hire, and possibly before your first account executive. The logic is that a GTM Engineer paired with a founding AE and an outbound agency could build the foundational systems (target account lists, enrichment workflows, automated outreach) that would otherwise take a larger team to assemble manually.

Whether or not you agree with that view, the implication for current RevOps professionals is clear. Process documentation, tool administration, and manual data cleanup are increasingly automatable. The skills gaining value now, including systems design, AI orchestration, and rapid experimentation, are learnable, and the professionals who develop them will be well-positioned as this function expands.

In-House, Agency, or Both

The current state of GTM Engineering talent reveals where the market actually stands.

Roughly 45% of professionals who carry a “GTM Engineer” title today are agencies or consultants. There are over 120 agencies listed in just one major solutions partner directory, and likely many more operating independently. By one count, there are approximately three GTM Engineering agencies for every new full-time job opening posted in a given month.

This ratio reflects a practical reality. Most companies are curious about GTM Engineering but hesitant to commit to a full-time hire for a function that is untested within their specific context. They don’t yet know whether the ROI will justify the cost, how to evaluate candidates, or where the role should sit in the org chart. Agencies offer a lower-commitment entry point: faster deployment, pre-built processes, and the ability to prove out a concept before making a permanent investment.

There are legitimate advantages to starting with an agency. They bring cross-industry experience and can often launch workflows in weeks. For companies that need to test whether automated outbound, signal-based targeting, or AI-powered enrichment will move the needle, an agency engagement provides a faster path to initial data.

There are real risks to the agency model as well. Knowledge, architecture, and system logic tend to sit with the agency. If the relationship ends, the internal team is left reverse-engineering what was built. Agencies are structured around scopes of work and campaigns. A well-designed GTM Engineering function is an evolving operational layer. Those two rhythms do not always align well.

The trajectory is clearly moving toward in-house. Organizations are internalizing GTM Engineering capability the same way they internalized marketing automation. Companies like Notion, Intercom, and Canva are building hybrid models where RevOps, AI teams, and embedded GTM Engineers collaborate across sales, marketing, and product. The agency serves as a starting point, and the in-house team becomes the long-term investment.

A practical path that many companies are following: engage an agency to build the initial workflows and prove out ROI on a specific use case (automated outbound enrichment, signal-based targeting, inbound lead scoring). Use that engagement to develop internal understanding of what the function requires, what tools are involved, and what skills to hire for. Then bring the capability in-house with a clear mandate and measurable goals already validated through the agency engagement. This reduces the risk of hiring for a function you don’t yet understand while still building toward long-term ownership of the capability.

A Framework for Readiness

Not every company needs a GTM Engineer today. The role creates the most value at a specific stage and under specific conditions. Here is a practical framework for evaluating readiness.

Evaluate your growth stage. GTM Engineering creates leverage through scale. If your sales team is fewer than five people and you are sending fewer than a thousand outbound touches per month, automation will not meaningfully change your outcomes. The systems that GTM Engineers build become transformative when there is enough volume for automation to compound. The natural inflection point tends to be Series A and beyond, after product-market fit is established and the focus shifts to scaling a repeatable sales motion.

Audit your stack complexity. If your GTM technology stack includes ten or more tools that do not integrate cleanly, and your team is spending significant time on manual data transfer, enrichment, or routing between systems, you have the kind of problem a GTM Engineer is built to solve. The more fragmented your infrastructure, the higher the return on someone who can build the connective layer.

Assess your current ops foundation. Companies that succeed with GTM Engineering almost always have some RevOps foundation in place already. You need clean enough CRM data, defined sales processes, and a basic understanding of your ICP and pipeline stages. A GTM Engineer builds on top of that foundation. Asking them to simultaneously create the foundation and build advanced automation on it is a setup for slow progress.

Determine your motion type. GTM Engineering resonates most strongly in lower-ACV, higher-volume, sales-assisted motions where there is a clear need for programmatic plays that reach many prospects with relevant messaging. Companies running thousands of outbound touches per month across a broad prospect base will see the highest return. Organizations with a small number of high-value enterprise deals per year may find the automation economics less compelling at this stage.

Start with a defined problem. The most successful implementations begin with a specific, measurable friction point: lead response time is too slow, outbound personalization is impossible at current volume, account research takes too long, CRM data decays faster than the team can maintain it. Starting with a clear problem gives you a concrete way to measure ROI, whether you bring someone in-house or engage an agency first.

Preparing for Success

For organizations that decide to move forward, a few principles will improve your chances of getting real value from the function.

Pair GTM Engineering with RevOps. The companies getting the best results treat these as complementary functions. GTM Engineers build new automated systems. RevOps maintains, optimizes, and scales those systems across the organization. Collapsing both into a single role or a single hire creates bottlenecks.

Place the function close to revenue. GTM Engineers produce the best outcomes when they sit near the teams generating pipeline, whether that is Growth, Demand Generation, or Sales. Burying the function inside IT or a shared services team distances it from the commercial context it needs to be effective.

Invest in the data layer first. The maturity curve for GTM Engineering follows a predictable sequence. Phase one is data foundation: clean CRM records, reliable enrichment, deduplication. Phase two is data modeling: collecting signals that predict purchase intent or identify high-value accounts. Phase three is automated revenue systems: workflows that act on those signals at scale. Skipping phase one and jumping to phase three produces brittle systems built on unreliable data.

Expect iteration. The best GTM Engineering teams operate in sprints, running experiments, measuring results, and iterating quickly. The first version of any automated workflow will need refinement. The value comes from the speed of the feedback loop: deploy, measure, adjust, redeploy.

Budget for tools as infrastructure. GTM Engineers need access to enrichment APIs, automation platforms, data warehouses, and AI models. Treating tool spend as a foundational infrastructure investment allows the function to build durable systems. Project-level budgeting forces constant re-justification of resources and limits what the team can accomplish.

Hire for the hybrid skill set. The candidates who succeed in this role tend to come from RevOps, growth, or demand generation backgrounds and have taught themselves to code, build integrations, and work with APIs. Title history is less important than demonstrated ability to identify a GTM problem and build a technical solution to it. Many strong candidates will carry titles like “Growth Engineer,” “RevOps Engineer,” or “Marketing Developer” on their resumes. Look for evidence of systems thinking, comfort with ambiguity, and a track record of shipping automation projects that produced measurable revenue outcomes.

What Happens Next

This role grew to over 3,000 job postings in roughly two years. The companies defining the next era of B2B growth have already committed to it. The agency ecosystem is thriving, which means there are accessible entry points for companies that want to test the waters without a full-time hire.

The underlying forces driving adoption are durable. AI capabilities will continue to improve. Stack complexity will continue to grow. The pressure to do more with less will persist. The organizations that build this capability early will develop compounding advantages in data quality, outreach precision, and pipeline efficiency.

For RevOps professionals, this represents a significant career development opportunity. The core knowledge of CRM systems, data workflows, and revenue processes translates directly into GTM Engineering. Adding technical skills around automation, API integration, and AI orchestration on top of that operational foundation creates a profile that is in high demand and short supply.

For revenue leaders evaluating whether to invest, the framework above provides a starting point. Assess your readiness signals, pick a defined problem, prove the ROI through an agency or fractional engagement, and use that evidence to build the business case for a permanent function. The companies that have moved fastest on this started with small, focused experiments and expanded once results were clear.

The function is still young enough that best practices are forming in real time. For those willing to invest in the learning curve, that represents an opportunity to shape how the role works within their specific context and establish a playbook on their own terms.

Paid members get the full RevOps Claude Code Guidebook, including a pre-built CLAUDE.md template configured for revenue operations projects, MCP connection files for HubSpot and Salesforce, a 20+ prompt library organized by function, and two production-ready Python scripts for CRM auditing and lead scoring. Every file is designed to work within your first session. Download, customize the bracketed values for your environment, and start building.

Read more