Here’s what I mean. Gong records the call, transcribes it, and coaches the rep on that call. Clari looks across the pipeline and tells you which deals are at risk based on engagement signals. Both are good at what they do.

But what if you looked at both holistically to get an actual read on the deal. For example, what should happen by call six based on what happened in calls one through five? Does the deal stage in Salesforce reflect where it should be? Is this a common pattern for this particular rep and is that good or bad compared to the rest of the team?

So what does “AI in sales” look like? For many teams it’s giving Claude to the sales team to run a specific task. Help me prep for this call. Help me write this proposal. The rep shoves in a bunch of information in the chat window. What makes the most difference in my opinion is to feed it cumulative evidence. All calls, all research, all emails, all documents passed back and forth. Have it work with you as a strategist, analyst, and coach.

MEDDICC is a strong first use case

Go back to what MEDDICC actually asks you to track. Metrics, economic buyer, decision criteria, decision process, identified pain, champion, competition. You just can’t get all of it in a single call. A champion doesn’t get identified in one conversation, they get confirmed over three or four, as the person keeps showing up, keeps advocating internally, keeps answering your emails before the rest of the buying committee does. Decision process doesn’t reveal itself in one meeting either. It usually leaks out sideways, a comment about legal review in call two, a mention of a budget cycle in call four, a stray line about who actually signs in call five.

A tool that summarizes each call in isolation will flag “champion not yet confirmed” on call #5 even though the evidence for a champion has been sitting in the transcript since call #2. It’s not wrong, exactly. It’s forgetful. And forgetful in a system that’s supposed to be helping you remember is close to useless.

Once you stop treating each call as its own event and start treating the deal as a thing with memory, four capabilities open up that a call by call tool structurally can’t give you. Deeper and wider deal inspection across a full call history. Coaching that’s about the rep’s pattern across deals, not their performance on one call. Preparation for the next call that’s actually informed by everything before it. And a rep level view that tells you something about how a person is developing, not just how one deal is going.

None of this needs a platform vendor, but I totally understand if it’s just easier to buy a platform. Proper AI systems need an architecture, a framework to hang the evidence on, and the discipline to build the thing so it accumulates instead of resets. Let’s walk through what that looks like in practice.

A five level way to think about where you are

I’ll lay out a rough maturity curve. Not because you need to hit level four to get value, level two alone is already a real jump for most teams, but because it’s useful to know which rung you’re actually standing on before you decide what to build next.

Level zero is the status quo for most teams. Calls happen, notes get written if they get written at all, and the deal’s real state lives in a rep’s head until they leave the company and take it with them.

Level one is where most conversation intelligence tools sit today. Every call gets recorded, transcribed, and summarized. You get a scorecard, maybe a sentiment read, maybe a list of competitor mentions. This is genuinely useful. It’s also where the story usually stops, because the summary of call five doesn’t know anything about calls one through four.

Level two is cumulative deal state, and this is where the SHIfT gets real. Before the agent analyzes the newest call, it first builds a running picture from everything that came before, so it knows the champion was confirmed in call two and doesn’t need call five to prove it again. This is the deep and wide inspection you’re asking about. Deep, because a deal that’s five or six calls into a proposal stage has accumulated a lot of evidence that a single call summary throws away. Wide, because the analysis is now checking the full MEDDICC picture against the full call history, not just what happened to come up in the most recent conversation.

Level three is coaching, but coaching that’s actually looking at the rep, not the deal. Once you’re extracting the same structured evidence buckets, metrics, champion, decision process, and so on, across every deal a rep runs, you can roll that up. Not “how did this call go” but “how does this rep tend to build champions across their deals.” That’s a completely different coaching conversation, and it’s one a manager sampling calls at random almost never gets to have, because they’d need to remember six deals worth of detail to spot the tendency.

Level four is where accumulated state turns into preparation instead of just retrospection. If the agent already knows the deal cold going into call five, it can brief the rep before call six starts. Not a generic call prep template. An actual briefing built from what this specific buyer said in the last five conversations, what’s still unconfirmed, what objection came up twice and never got fully answered.

What deep and wide inspection actually catches

Let’s make level two concrete, since “cumulative state” can sound abstract until you see what it changes.

Imagine you have a deal in proposal stage with six calls behind it.

A level one tool analyzing call six in isolation is working from whatever got said in that one conversation, plus maybe whatever fields already exist in the CRM. If the rep didn’t explicitly restate the economic buyer’s name in call six, a naive scoring pass might flag it as a gap. It’s not a gap. It was nailed down in call two and confirmed again in call four. The tool just doesn’t know. It’s only looking at one call!

A cumulative system reads all six calls before it says anything about call six specifically. It builds a running assessment of every MEDDICC component first, then checks what’s genuinely still missing against what’s actually been said across the whole relationship. The practical effect is that your gap list gets shorter and more honest at the same time. Fewer false alarms about things that were already answered three calls ago. More real ones about things that have never come up at all, which is a much sharper signal for a rep or a manager to act on.

This also changes what “deep” means. A single call rarely contains enough for a manager to catch something like a champion who’s been quietly softening their language over three calls, more hedging, less certainty, the kind of drift that’s obvious across a stretch of conversations and invisible in any one of them. It’s exactly the kind of signal a system with memory is positioned to catch and a system without it structurally cannot, because there’s nothing to compare against.

Coaching that looks at the rep, not just the call

Once you’re pulling the same evidence categories out of every deal a rep touches, something else becomes possible that most coaching programs never get to. You can ask what this rep tends to do well and where they tend to come up short, across their whole book, not their last call.

Say a rep is strong at identifying pain early. Call one, call two, they’ve got real specificity on what’s broken and what it’s costing the buyer. But across a dozen deals, champions never seem to get much stronger after they’re first identified. The rep finds the person, gets an initial yes, and then never does the follow up work to build that relationship into an internal advocate who’s actually fighting for the deal in rooms the rep isn’t in. That’s not visible from any single call review. It’s only visible once you’re looking at the shape of a rep’s deals as a set.

This is the coaching conversation managers actually want to have and now it’s even better because you’re providing evidence. Not “you missed a question in this call.” More like “here’s a tendency across your last eight deals, and here’s what it’s probably costing you at the proposal stage.” Sales enablement has been trying to get to this kind of coaching for years with call libraries and manual scorecards. It’s slow, it depends on a manager remembering enough detail across enough deals, and it doesn’t scale past a handful of reps a manager can genuinely track in their head.

Prep before the call that hasn’t happened yet

Level four is the one that turns this from an analysis tool into something a rep actually uses before they need it, not after.

If the system already has a running picture of a deal after five calls, it can generate a brief before call six starts. Not “here’s what MEDDICC is missing,” which is retrospective and a little accusatory. More like a working document. Here’s what this buyer has said matters most to them. Here’s the objection that came up in call three and got a soft answer that never got revisited. Here’s the name that’s come up twice as someone the champion mentioned but the rep has never actually talked to.

That’s the difference between an audit and a briefing. An audit tells a rep what they did wrong. A briefing tells a rep what to walk into the next room already knowing. Reps read briefings. Reps tend to ignore audits, especially audits that show up after the deal’s already lost momentum.

The rep level rollup, and where the numbers get real

Pull all of this up one more level and you get something genuinely useful for a RevOps or enablement function specifically, which is a way to see how a rep is actually progressing against their ramp, not just their quota.

The average AE ramp time is at 6.2 months because of deal complexity and stakeholder count both climbing. Quota attainment across B2B SaaS sits in the low fifties on a good year. Those two numbers together mean sales organizations are running a ramp program that takes over half a year, aimed at a bar that half the team still won’t clear once they’re through it.

A per rep rollup built off the same deal level evidence gives you something ramp programs usually can’t, which is a signal that isn’t just “did they hit number in month four.” It’s closer to “is this rep’s champion identification getting sharper deal over deal, or is it flat.” That’s the kind of signal that tells you whether a rep is actually ramping or just getting lucky on a couple of deals, months before the quota number would tell you the same thing. If you’re the person building the ramp curve for a new cohort, that’s the difference between catching a stalled rep in month three and finding out in month seven when it shows up as a missed number.

None of this replaces a manager’s judgment. It gives the manager something to point at that isn’t just their own memory of who seemed sharp in the last forecast call.

AI infrastructure that learns

The system I run keeps a versioned memory layer in the same GitHub repo as the code, daily diffs, learning entries, snapshots of the instructions the generator is running on. This type of setup is what enables level three and four to be possible, because a coaching rollup or a call six briefing is only as good as the accumulated record it’s built from, and a record that isn’t versioned is a record you can’t trust six months in.

Anyway. Let’s get into what you could actually build.

The three roles, at minimum. A context builder that reads everything before the newest call and produces a running MEDDICC state. A generator that takes that running state plus the newest call and produces the actual analysis, gaps, next steps, evidence. And an evaluator that checks the generator’s output against a rubric before anything touches your CRM, so a bad run doesn’t quietly corrupt the deal record. I run the generator role on Sonnet 5, for what it’s worth, mostly because the reasoning gains on evidence extraction and gap identification are the part of this pipeline where model quality actually shows up in the output.

Again, the three roles are:

• The context builder

• The generator

• The evaluator

The rubric matters more than the model. Your evaluator is only useful if it’s checking for something specific. This is where humans make a huge difference with AI. You train the AI on what good looks like. Evidence quality, meaning does every claimed gap or confirmation trace back to an actual quote, not an inference. Component coverage, meaning did the generator actually check all seven MEDDICC components or just the ones that came up naturally. False gap rate, meaning is it flagging things that were already resolved earlier in the deal. Write the rubric before you write the generator prompt.

Deal prep is a separate generation pass, not a repurposed audit. Don’t try to make one prompt do both jobs. The rubric for “what’s missing” and the rubric for “what should this rep walk in knowing” are different enough that combining them produces a document that’s mediocre at both.

The rep rollup is a query, not a new pipeline. If you’re already extracting structured evidence per deal, the rep level view is a matter of grouping that evidence by rep and by month, not building new infrastructure. This is the part people tend to over engineer.

One honest caveat before you build any of this. A system that accumulates deal state is also a system that accumulates its own mistakes if nobody’s checking it. A bad context builder read in call two can quietly poison every analysis after it, since the whole point is that later calls build on earlier state. Review the learning loop’s output periodically. Don’t set this to fully unattended and check back in a quarter.

The paid deliverable for this edition is a build blueprint. It includes the three role prompts as editable templates, ready to adapt to your own MEDDICC or MEDDPICC rubric, a GitHub Actions cron file you can drop into a repo as is, the evaluator rubric spelled out as actual pass and fail criteria rather than vague guidance, and the rep rollup query structure. Open it and you have something to paste into a repo within the first few minutes, not a framework to fill out before you get anything usable.

Read more

Here are a few pricing models which you’ll come across:

• Pay as you go

• Uncommitted contract

• Committed contract

• Hybrid

Let’s dive into them.

What kind of contract are you actually selling?

There are four main contract structures in usage based and consumption pricing, and which one you’re selling determines the right comp mechanics to design your processes around.

Pure pay as you go

The customer pays as they consume, with no obligation and no contract floor. This pricing format is more common in self serve and SMB motions, and in early product stages where the goal is adoption before monetization. Reps get a flat acquisition fee, or monthly commissions tied to actual consumption as it accrues. There's no true up because there's nothing to true up, consumption bills as it happens.

Twilio is the canonical example. No monthly minimums on its core APIs, no contract required. You load credits and pay per message, per minute, per verification. Volume discounts kick in automatically at thresholds, no commitment attached. OpenAI and Anthropic run the same structure on their APIs: pay per token, no floor, no term. AWS Lambda is another: you pay per invocation and compute time, with no obligation to consume anything. These are products where the billable unit is easy to define and usage is genuinely unpredictable.

For compensation planning:

• Reps get paid a flat acquisition fee, or they receive monthly commissions on actual consumption as it accrues

• There is no true-up for the rep because there is nothing to true-up; consumption is billed directly as it happens

• The challenge is motivational. At close, there is nothing to book, and reps accustomed to a single large commission payment will struggle with the math of distributed monthly accruals

• The downside for customers is if usage spikes or elevates persistently then it presents an uncapped expense

Uncommitted contracts

Uncommitted contracts turn up in revenue share, digital media, fintech. Reps get paid on an estimated annual value at close, built from a scoring model using company size, historical usage, product fit signals, or they get paid on actual monthly consumption as it lands. Pay on estimate and there’s a true up at year end. The estimate is only as good as the data behind it, and without real consumption history for that account, it’s a guess with a dollar sign on it.

Shopify Payments works in this way. Merchants sign up under defined rate terms (2.9% plus 30 cents per transaction) with contractual pricing but no obligation to generate any particular GMV.

Again, for comp planning:

• Reps get paid on estimated annual value, which requires a scoring model using company size, historical usage data, and product fit signals, or on actual monthly consumption as it comes in

• If the company pays on estimated value at close, there is a true-up at the end of year one between what was estimated and what actually happened

• The problem is estimation accuracy. Without historical consumption data for the account, the estimate is a guess, and building a comp plan on guesses creates a reconciliation problem at year end that RevOps has to own

• The upside for customers is they can break out of a contract anytime. This is a downside for the vendor obviously but it creates pressure to provide the best product and experience.

Committed contracts (pool of funds)

Committed contracts are the dominant enterprise model. Customer commits to a spend, draws down against it, owes the full amount even if they underuse it. Reps get paid on the committed amount at close, same as a traditional booking. Buying into a pool of funds like this works a little like buying yourself a gift card. You've paid for a balance up front, and whether you spend it down to zero or leave money sitting there unused, the store already has your cash. The risk to watch is the same one that shows up with any gift card nobody spends. A customer who commits five hundred thousand and burns two hundred in year one isn't going to enjoy the renewal conversation, and by year two you've got a churn risk on your hands.

AWS Savings Plans and Enterprise Discount Programs offer this. The customer commits to a dollar-per-hour spend rate for one to three years and draws down against that commitment across any eligible service. GCP Committed Use Discounts work similarly. Datadog and Snowflake allow variable usage but steer customers toward committed arrangements. These products embed deeply into infrastructure, and usage tends to grow over time rather than peak unpredictably. Snowflake sells capacity contracts where the customer commits to a pool of credits and burns through them as queries run. New Relic's pool of funds model starts at $25K annual commit with full platform access drawn against that balance. Unused funds are charged at period end.

Some thoughts:

• Reps get paid on the committed amount at close, treated much like a traditional ACV booking

• If the customer under consumes the commitment, the vendor still collects the minimum, which means the rep’s commission stands without adjustment

• The risk to manage is the incentive to oversize commitments. A customer who commits $500K and burns $200K in year one is a difficult renewal conversation and a real churn risk by year two

Hybrid (tiered subscription with usage overage)

Hybrid pairs a base subscription with usage overage. Reps get paid on the base at close, plus commission on overages as they accrue, which pulls CS into the commission tail whether the plan accounted for that or not. Overage converting into a higher tier is where the real fight starts. Who gets credit, sales or CS. Decide that before it happens, not while it’s happening.

Datadog runs a prominent version. Its core monitoring product charges per host, but log management bills per GB ingested and APM charges per traced request. HubSpot and Salesforce both joined the hybrid list in 2025. HubSpot's structure gives every account a monthly credits allotment; features like Breeze agents consume credits when used, and accounts that exceed their credit limit are automatically upgraded to a higher tier for the rest of the commitment term. Salesforce layers Agentforce on top of its base seat licenses. With Salesforce you pay for the seats, then Flex Credits or the AELA for agent consumption on top. Clay does this to: it sells feature-gated subscription tiers but charges for data enrichment credits on top, so customers know their base cost but pay more as they extract more value.

Overage true-ups will be common here:

• Reps get paid on the base subscription value at close, plus additional commission on overages as they accrue in the billing cycle

• The commission events split across the initial close and ongoing expansion activity, so the plan naturally involves CS in the later commission tail

• Attribution becomes the challenge when overage converts to a higher-tier subscription. Who owns the upsell credit, sales or CS? Getting this decision wrong creates conflict that is very hard to unwind mid-year

Is the enterprise selling motion a budget sizing exercise?

Mostly, yes. Finance teams need something they can take to procurement, and pure consumption doesn’t give them one.

Salesforce found this out the hard way with Agentforce. Launched at two dollars per conversation. Enterprise procurement stalled, because nobody could plan around an open-ended variable cost. Salesforce moved to Flex Credits at ten cents an action, then landed on a per user license around a hundred twenty five dollars a month through the Agentic Enterprise License Agreement. The original pricing tracked value about as well as pricing can. Predictable pricing schemes is what finance teams can sign up for. Paying for credits creates heartburn in my honest opionion.

New Relic runs an annual pool of funds, committed spend starting at twenty five thousand, full platform access, drawdown against the pool. Same gift card logic as before. The rep sells the size of the balance, the customer gets a number they can budget against.

Sidebar, since I’m on the topic: half the material out there on consumption pricing is vendor content dressed up as thought leadership, written by people who’ve never run a comp cycle in their life. Don’t trust benchmarks you found in a sponsored whitepaper. Anyway.

The actual skill that matters here is consumption forecasting, not the close itself. A good rep helps the customer model realistic usage based on team size and adoption timeline before anyone signs. Size the pool too high and the renewal conversation gets awkward. Size it too low and you’ve left money on the table, plus handed CS a transaction heavy mid year expansion motion nobody staffed for.

What do you actually pay reps on?

Five approaches, and most comp plans built by committee end up unclear to the reps actually working under them.

• Paying on the committed amount

• Paying on actual consumption, distributed monthly

• Estimated commission at close with a year end true up

• Consumption run rate

• Incremental consumption above baseline

Paying on committed amount treats the commitment like a booking, which eases the transition for reps coming off a subscription plan. Same oversizing incentive as before shows back up here, same lever, different label. Some companies tie part of the commission to a ninety day adoption milestone, which at least gives the rep a reason to stick around after the ink dries.

Monthly consumption pays nothing at close, everything as usage accrues. Reps only collect when customers actually use the product, which kills off phantom bookings on commitments that never burn. The tradeoff shows up in the calendar. A rep who closes a big account in January doesn’t see real money until well into the year, and a new hire without a book can go months without a real paycheck. This can also be problematic if you have reps constantly monitoring if a customer is using the product. That’s the job of CS and product instead of your sales team. Having sales chase this is a collossal waste of time.

Estimated plus true up pays sixty to eighty percent at close, holds the rest, settles the balance at month twelve. Estimate three hundred, customer lands at two seventy, the held balance adjusts down. Land at three forty instead, the rep collects more at true up. The buffer’s built into the structure from day one, so there’s no hard clawback conversation waiting at the end of it.

Consumption run rate measures the annualized run rate at a point in time and commissions the growth between measurement points. Grow an account from eight hundred thousand to a million in run rate and the rep gets credited for that two hundred thousand the moment it registers, not dribbled out across the year. Works best on stable accounts. Seasonal or lumpy ones need a year over year quarterly comparison instead, since a monthly snapshot on a seasonal account is just noise wearing a suit.

Incremental consumption above baseline only commissions growth past where the account already was. Nobody’s crediting the rep for the eight hundred thousand the customer was already spending before the handoff. They’re crediting the two hundred thousand in new workload actually developed. Clean in theory, and it costs you real operational effort, since every account needs a clean baseline and every irregular one becomes a dispute RevOps has to settle.

Paying on the committed amount

For committed contracts, the cleanest approach is treating the committed spend like a traditional ACV booking. The rep closes a $300K annual commitment and commission is calculated and paid on $300K at close.

• This maps directly to what enterprise reps already know, which eases the transition from a subscription model

• The problem is the incentive to push customers toward commitments they cannot achieve

• Some companies address this by tying a portion of commission to consumption milestones in the first 90 days after close, giving the rep a financial reason to stay involved in onboarding rather than moving immediately to the next deal

Paying on actual consumption, distributed monthly

Reps get no commission at close and collect monthly as actual consumption accrues.

• Reps only collect commission when customers actually use the product, so there are no phantom bookings on commitments that never burn

• The rep is financially motivated to stay involved in activation and early adoption

• The challenge is timing. Reps who close a large new account in January do not see meaningful commission until well into the year. New hires without an existing book of accounts may go many months without building a commission base, and in competitive hiring markets that becomes a retention problem before it becomes a motivation problem

Estimated commission at close with a year-end true-up

Pay 60% to 80% of the estimated deal value at close, withhold 20% to 40%, and settle the full balance at the end of year one based on actual consumption.

• If the estimate was $300K and the customer consumed $270K, the withheld balance adjusts proportionally

• If the customer consumed $340K, the rep collects additional commission at the true-up

• This avoids the hard clawback problem by building the reconciliation buffer into the payout structure from the beginning. The rep expects the withheld 20% to 40% at month 12, not month 1

Consumption run rate

Rather than measuring total consumption over a period, you measure the annualized run rate at a point in time and commission on growth in that run rate.

• A rep who helps a customer expand consumption from an $800K annualized run rate to a $1M run rate gets credited for $200K of growth when that change happens, not spread across 12 months

• This gives reps a defined moment when expansion wins register in their commission, rather than watching a cumulative number inch upward across the year

• Run rate works well for accounts with relatively stable month to month consumption. For seasonal accounts or accounts with lumpy usage, quarterly comparisons against the same quarter the prior year are more accurate than monthly snapshots

Incremental consumption above baseline

This approach baselines a customer’s existing consumption pace and only commissions reps on growth above that baseline.

• You are not crediting the rep for $800K a customer was already spending before the territory assignment. You are crediting them for the $200K in new workloads they developed

• The advantage is precision in attribution

• The disadvantage is operational complexity. You need clean baseline data for every account, and accounts with irregular consumption create disputes that take RevOps time to resolve

Who owns expansion, and what does that mean for comp?

Most companies with usage based pricing split expansion and renewal responsibility between sales and CS. The typical approach is a handoff model where sales owns the account through some period after close, often six to twelve months, then CS takes primary responsibility for expansion and renewal. During the sales owned period, the rep gets credit for overages and expansions above the initial commitment.

A few companies run the whole-account model. At Snowflake, the account team retains ownership of the customer relationship long-term. At Atlassian, CS handles everything after close. Neither approach is wrong, but both require a comp plan built around the ownership model, not around a generic split that nobody fully committed to.

MongoDB made an interesting distinction. They pay commission on CS led expansion only when the CS team actively identified a new use case and drove adoption of it. Organic growth that happened without CS involvement does not generate a commission event. This is sensible in principle and operationally demanding in practice. You need a clear standard for what counts as CS led and a documentation process that runs before the revenue shows up, not after.

Get the handoff timing and ownership model settled before you build the plan. Changing it mid year is one of the more disruptive things a RevOps team can do to a sales org.

Do commission caps make sense in consumption models?

Fewer than fifteen percent of SaaS companies cap commissions at all, and for good reason. Capping the payout on the deal that just accelerated your whole company is a strange way to say thank you. Try telling a sales team you will cap their earnings and see what happens.

Consumption tracks forecast far more closely than bookings ever do. Nobody's closing a surprise ten million dollar deal in a usage model the way they might in a traditional enterprise motion, since revenue shows up as usage grows instead of landing all at once.

Which means the windfall problem caps exist to solve barely shows up in consumption models. Forecast something achievable and consumption tracks it closely, and the plan starts to feel like a salary with extra steps.

Give reps a straight booking quota too, not just the consumption number. That's what Snowflake does. A new logo still needs its own quota, and a big first year commitment still gets a real accelerator on top.

Windfall clauses are helpful. It gives management room to review commission above a set threshold, case by case, rather than punishing every rep who simply had a good territory.

Should you use clawbacks?

About half of SaaS companies use them. In subscription SaaS the trigger is usually a cancellation inside ninety to a hundred twenty days, some of the at close commission coming back.

Consumption models shift the mechanics depending on which approach you picked. Pay on actual consumption and there’s nothing to claw back, the commission only ever existed because the revenue did. Customer churns, the monthly payments just stop. Pay on a committed booking where the customer underconsumes, the company still collects the minimum, so the rep’s commission never moves.

The real clawback exposure lives in the estimate at close model, and estimates go wrong for reasons that have nothing to do with the rep lying. Sometimes the AE genuinely misjudges usage because the customer’s own team doesn’t know it yet. Sometimes the account reorganizes eight months in and consumption resets from scratch. Sometimes a new SKU ships mid year and nobody updated the scoring model to account for it. Sometimes it really is just an optimistic number that didn’t hold. The sixty to eighty percent at close structure exists precisely because most of those reasons are nobody’s fault.

Claw back too aggressively and you’ll train your reps to sandbag every estimate, which is the rational move in a world where guessing high creates debt. Better to design the plan so that incentive never exists.

Even a clawback that never actually fires does work just by sitting there. A rep who knows an inflated number gets corrected at year end pays more attention getting it right the first time.

How do you set quota in a consumption model?

Quota setting in consumption models is harder than in bookings models because the external benchmarks are thinner. For subscription SaaS, there are years of data on what a good AE quota looks like as a multiple of OTE. For consumption, that data is still developing, and anyone who tells you they have a definitive benchmark is guessing with more confidence than the situation deserves.

The approach that works best is building quota from the account level. Start with forecasted consumption for every existing account in the territory, then layer in expected new logo contribution. Use that as the primary input, not a blanket percentage lift applied to last year’s numbers. If a rep’s top three accounts are saturated and two others have churned, a 10% lift target is fiction.

Consumption models also narrow the attainment distribution. Revenue accrues predictably, so most reps land in a tighter band than bookings-based plans produce. Your accelerator table needs to be tuned accordingly, with meaningful payouts starting closer to 100% of target and accelerating through 120% to 140% rather than through 150% to 200%.

Your first consumption comp plan is really a hypothesis with an OTE attached. Design it that way.

Territory based comp weighting

The greenfield versus mature territory model is the most practical mechanism for applying different commission weightings within the same plan. A rep in a greenfield territory might run 70% on bookings and 30% on consumption. A rep in a mature territory runs 30% on bookings and 70% on consumption. Two reps at the same OTE can have materially different plan compositions based on their territory profile.

This matters for how you model commission cost. The overall cost does not change at target, but the timing of when that cost is incurred does. Finance needs to model both scenarios before the plan is published.

Attribution rules for CS led expansion

For companies running a shared model, the attribution rules need to be written BEFORE anyone sells anything. The decisions to make:

• Does CS get commission, a bonus, or a quota credit for expansion they drive?

• What is the documentation standard for CS led expansion versus organic growth?

• What is the handoff date, and does it apply uniformly across all segments or by account size?

• How do overages that accrue during the CS owned period get credited back to the original closing rep, if at all?

Benchmark numbers to anchor the plan

Pay mix in usage based pricing runs largely consistent with subscription SaaS, at 50% base and 50% variable at target OTE. Commission rates run slightly lower, with the most common range being 7% to 9% on commissionable revenue. CS team staffing ratios are higher in consumption models, with a typical target of 0.6 CS members per AE versus 0.4 in subscription businesses.

Very few consumption model companies pay extra for multi year commitments. The contractual length does not generate meaningfully better revenue predictability in a consumption model, so the incentive premium is rarely justified.

The core problem underneath all of this: usage data and deal ownership data live in completely different systems, get generated at completely different grains, and were never designed to talk to each other. Finance and RevOps end up building the translation layer by hand.

The systems involved and why comp administration can be difficult

Read more

What did this customer buy?

Not what the AE remembers selling. Not what the first quote said. Not what Billing happens to be charging this month. Not what the CSM thinks the customer is entitled to.

What did they actually buy?

I keep coming back to this because the question sounds embarrassingly basic. It should be answerable in five seconds.

In a lot of companies, it becomes a small investigation.

CRM has the opportunity.
CPQ has the quote.
The contract has the terms.
Billing has the invoice logic.
CS knows what the customer is using.
Finance has the revenue schedule.
RevOps has the dashboard everyone is quietly side-eyeing.

Everyone has part of the truth and nobody is totally wrong.

That is what makes the whole thing annoying.

The quote is not the relationship

A quote feels definitive when it gets approved.

Products. Price. Discount. Term. Start date. Maybe usage tiers. Maybe ramping. Maybe services. Maybe one or two commercial decisions made under the influence of quarter-end.

The customer signs. The deal closes. Everyone celebrates.

For a brief, beautiful moment, the quote feels like the source of truth.

Then the customer changes something.

They add seats. They upgrade a module. They downgrade another. They co-term an expansion. They remove part of a bundle. They negotiate a discount that applies to one product but not another. Usage changes. Packaging changes. Someone approves an exception because the customer is strategic and nobody has the emotional energy to fight procurement anymore.

None of this is weird.

That is the point. These are not edge cases. This is normal customer motion in a subscription business. The original quote may have been perfectly accurate on the day it was created. It just stops being the full story as the relationship evolves.

This is where a lot of teams underestimate CPQ complexity. They treat it like a front-end quoting problem.

Can we configure the products?
Can we approve the discount?
Can we generate the document?
Can we get to signature?

These are useful questions, but the harder one comes later: do we still understand what we sold six months later?

That is the gap modern CPQ tools need to close. And it is the reason platforms like Vendori are interesting to RevOps teams evaluating whether their current CPQ can actually support the full subscription lifecycle. The job is not just getting a clean quote out the door. The job is keeping the commercial record usable after the customer starts behaving like an actual customer.

Bundles are where truth starts to blur

Bundles are great for go-to-market.

They simplify packaging. They help customers buy. They help Sales tell a cleaner story. They create expansion paths. They make the pricing page look less like a Cheesecake Factory menu.

Then someone has to operationalize them.

A bundle is rarely one thing. It might include products, modules, seats, support levels, usage limits, services, implementation hours, entitlements, contract terms, and special pricing logic. Some pieces renew together. Some do not. Some are discounted. Some are only included for year one. Some get added later and somehow inherit pricing rules no one remembers creating.

This is fine when the bundle never changes. Unfortunately, customers love changing things.

They add a module mid-term. They downgrade part of the package at renewal. They want to keep one product but remove another. They move to a new tier. They ask whether the original discount still applies.

Sales says yes.
Finance says absolutely not.
CS asks what the customer is actually allowed to use.
RevOps opens seventeen tabs.

At that point, the issue is no longer “can we create a quote?”

The issue is whether the business can explain the customer relationship without summoning the original deal desk, the AE, the CSM, Billing, Legal, and one spreadsheet named something like final_final_customer_terms_v3.xlsx.

That is not process. That is folklore.

The data does not explode. It decays.

Most quote-to-cash problems do not show up as one dramatic systems failure. They show up one reasonable exception at a time.

One discount gets extended manually.
One amendment does not make it back into CRM cleanly.
One co-terming calculation lives in a spreadsheet.
One downgrade is reflected in the contract but not in the active product record.
One renewal opportunity gets created from the wrong baseline.

And each decision makes sense in the moment.

The customer needed it. The rep needed it. The quarter needed it. The system could not handle the exact scenario, so someone worked around it.

That is how the commercial record starts to drift.

Every system thinks it is right

The annoying part is that no single system is always wrong. Each system has part of the story. The problem is nobody knows which one wins.

You see it most clearly at renewal. Someone asks what the customer owns today, and suddenly the team is checking the quote, the contract, billing, Slack, and probably a spreadsheet with a name that should have been a cry for help.

Eventually, you get to an answer. But that is not a process. It’s archaeology.

This is why RevOps gets dragged into the middle. Sales needs the renewal baseline to be right. Finance needs billing to be right. CS needs entitlements to be right. Leadership needs product reporting to be right.

And when nobody trusts the record, RevOps becomes the translator.

Translating what Sales sold.
Translating what Finance needs.
Translating what Billing can support.
Translating what the CRM was supposed to capture.

That is the real job underneath the workflows and dashboards: keeping trust in the revenue machine.

The test I would actually run

If I were evaluating CPQ or quote-to-cash for a subscription business, I would not start with the clean demo.

Clean demos are lovely. Every discount is reasonable. Every approval routes correctly. Every product has been lovingly configured by someone who has clearly never met your sales team.

I would start with the ugliest customer lifecycle scenario I can find.

Take the account that bought a bundle, added seats, upgraded one module, downgraded another, changed usage tiers, co-termed an expansion, negotiated a special discount, and then renewed only part of the agreement.

Run that through the system.

Then ask:

Where does the active product record live?
What changed after the original quote?
What should renew?
What should Billing charge?
What is the customer entitled to use?
Can RevOps see the history without reconstructing it manually?
Who has to get involved when the customer changes the package?

This is the kind of scenario I would want to see in any CPQ evaluation. It is also the kind of lifecycle complexity Vendori is built to make easier for SaaS teams managing subscriptions, bundles, amendments, renewals, and quote-to-cash workflows inside their existing revenue motion.

Because most systems can make the first quote look good.

The real test is whether the business still knows what it sold after the relationship changes.

Where this lands

Not every company needs a massive quote-to-cash architecture. Simple businesses can run on simple systems for a long time. Complexity for its own sake is how you end up with an implementation project that outlives three CROs.

But companies should be honest about the complexity they already have.

If you sell bundles, usage, custom discounts, mid-term changes, partial renewals, or co-termed expansions, you are already managing subscription lifecycle complexity.

The only question is whether your system is managing it, or your people are.

The mistake is assuming that because the first quote is accurate, the commercial record will stay accurate.

It will not.

The real challenge is not just getting the quote right. It is making sure your team still knows what the customer owns after upgrades, downgrades, renewals, and mid-contract changes.

That is the operational problem Vendori is built around: helping SaaS teams manage complex pricing, subscriptions, amendments, renewals, and quote-to-cash workflows without turning RevOps into the human API between Sales, Finance, Billing, and Customer Success.

Subscribe now

I feel blessed I get to do it as well for my clients. Base level is working within the tools in your environment. Leveling up to hard mode is building it yourself. The downside of that is clearly technical debt and the risk of becoming a single point of failure.

My advice is that only teams who have serious AI skills should take on building custom agents and applications.

Everyone I talk to in this work right now has two separate conversations running in parallel. One is about what is already in production, moving actual pipeline, generating actual output. The other is about what someone saw in a demo last week, or read on LinkedIn (maybe from one of my posts 😅), or heard described as inevitable at a conference. Looping agents, self improving systems, agents that get smarter without anyone touching them, are firmly in that second conversation for most enterprise revenue teams I know.

I have been paying close enough attention to this space to feel behind on it myself. The gap between what is actually happening and what is being described is smaller and stranger than it appears.

But first, what is a loop

A standard AI workflow is a chain. Your system sends a prompt, the model responds, and the output goes somewhere. The loop ends.

You can make the chain longer, route outputs through additional steps, parallelize calls across multiple models. But each step runs once and stops.

When practitioners use the word “agentic” to mean something real, they mean a system where the model runs inside a feedback cycle. Observe the result of what was just done, decide whether that result is good enough, keep going until it is. That’s a loop.

Uber’s engineering team published a detailed account of how this changed Genie, their internal Slack bot that engineers use to ask questions about security and privacy policy. The original system was a standard retrieval pipeline. Fetch content, generate an answer, stop. When they rebuilt it with an agentic loop, the bot could expand its initial query, retrieve across multiple sources, reflect on whether the response covered the question, and re-query until the answer cleared a quality threshold. The published result was a 27% increase in acceptable answers and a 60% reduction in incorrect ones. Same underlying model but different architecture and results.

That example sits at what practitioners have started calling the inner loop: task execution, where the agent runs through a cycle of observe, reason, act, and check until either the goal condition is met or a budget runs out. Inner loops are where most production deployments actually live right now. They are the keep-trying-until-done version of the concept.

Get the AI Looping Outbound Template

The outer loop is different. When the inner loop stalls, the outer loop steps back and resets the approach entirely. Microsoft’s Magentic-One uses this design explicitly: an outer strategic layer wraps an inner execution layer, and when the inner layer hits a wall, the outer layer does not simply retry. It replans from the top. This prevents what practitioners call the “insistent failure” mode, where an agent repeats a broken approach over and over because nothing in its architecture gives it permission to question the approach itself.

Two kinds of self improvement

When people say “self-improving agents,” they usually mean one of two different things.

The first is improvement within a single run.

The Reflexion framework, published in 2023 and still heavily referenced in production discussions, was built around this. After a failed attempt, the agent writes a natural language post mortem of what went wrong, then prepends that critique to its context on the next try. No weight updates, no gradient descent. Just a text file of lessons the agent wrote about itself. On HumanEval, the standard coding benchmark, this brought GPT-4 pass rates from 80% to 91%. A simple mechanism that produces meaningful gains on trial and error tasks.

The second is improvement across runs. The agent runs today, stores what it learned, and comes back tomorrow better than it was. Google DeepMind’s AlphaEvolve, published in May 2025, is the clearest production example of this. It runs an evolutionary loop: an ensemble of models generates candidate program variants, an automated evaluator scores them, and the best survive into the next generation.

It’s a tournament of AI models! The world cup of model runs dare I say?

Running inside Google’s infrastructure, AlphaEvolve recovered 0.7% of compute across Google’s data centers, produced a 23% speedup on the FlashAttention kernel used to train Gemini itself, and found a matrix multiplication algorithm that broke a 56 year old algorithm. Machines over humans is real!

AlphaEvolve improves across iterations. Each generation learns from the last. It is self improving in the fullest sense of the term. The reason it works inside Google and may not translate directly to your pipeline comes down to one specific condition: their evaluator is machine checkable. The scoring function is exact. Code runs faster or it does not. An algorithm uses fewer matrix multiplications or it does not. The feedback is objective, automated, and immediate.

How memory works, and where it breaks

The within-run version of self-improvement has everything it needs in a single context window. The goal, the tools, the history of what the agent already tried, the evaluator’s feedback: it is all there. What the inner loop cannot do is remember what worked last Tuesday.

That is what memory architectures are for, and there are several distinct types in production now. Episodic memory records what happened during the current run, keeping the working history available as the agent processes deals or scores accounts. Persistent memory stores conclusions across sessions. For most go to market teams that means a GitHub repository holding agent configuration and scoring logic, CRM custom fields storing outputs written back to the account record after each run, or a data warehouse like Snowflake holding the signal history the agent draws from on future runs. Semantic memory stores domain knowledge and rules, the kind of content that lives in a system prompt or a context file: ICP definitions, qualification criteria, scoring rubrics.

The cross session improvement that gets everyone excited depends on file based or equivalent persistent memory. The agent finishes a task, writes a structured summary of what worked and what did not, and loads that summary on the next run. This is the version that compounds over time. It is also the version most likely to degrade silently.

Research published in May 2026 identified a specific failure mode called memory confabulation in Reflexion-style agents. When feedback is binary, pass or fail with no causal explanation, the agent can develop false conclusions: “approach X always fails.” That false conclusion gets encoded as a lesson and permanently skews future attempts. The agent will never test that approach again, never collecting evidence to overturn the belief. Across ALFWorld and HumanEval evaluations, researchers found 16 environments where the agents stored confident but incorrect interpretations and continued acting on them across trials, with 0 of 121 reflections in those environments mentioning the correct target object. The memory layer, in those cases, was confidently wrong and getting worse. Detailed feedback is critical to agent self improvement. Please don’t get tired of me saying that more context is needed.

The fix was to replace open ended self diagnosis with programmatic extraction of trajectory level failure signals. Instead of asking the agent to write a narrative about what went wrong, the system extracted observable facts from the execution log and used those as the reflection input. That got correct mention rates from 0% to 86% in the frozen environments.

The lesson transfers directly to production: the memory layer needs its own review process, not just the output layer. If you cannot say what your memory layer stores, how it expires stale conclusions, and who audits it, you do not have a self improving system. You have a system that is increasingly confident about things it decided weeks ago.

The verifier problem

The bottleneck in every loop is the evaluator. And evaluating its own output is something a language model is, reliably and demonstrably, bad at.

Anthropic’s engineering team made this explicit when describing the architecture of their multi agent Research system. When asked to evaluate its own work, an AI model is a pathological optimist. It will almost always give itself high marks, even for mediocre output. A loop without an independent evaluator is expensive text generation that believes it is working.

Their response was to borrow from generative adversarial networks. A generator model produces output. A separate evaluator model scores it without knowing who produced it. The two agents have different roles and different incentives inside the same system. On Anthropic’s internal evaluations, the multi agent configuration with Claude Opus 4 as the orchestrator outperformed single agent Claude Opus 4 by 90.2%.

The cost is real. Multi agent systems use roughly 15 times more tokens than a standard chat interaction, and token consumption explained approximately 80% of the performance variance in their evaluation framework. You are buying capability with compute spend.

I know. Token costs are falling. They are still not free, and the multiplier in multi agent loops is real enough that it changes the economics of anything deployed at volume.

The practical response most teams land on is staged loops. The inner loop, which does the actual task work, operates on a lighter and faster model. The evaluator, which has to be correct more than it has to be fast, runs on a stronger one. Hard budget gates at the outer loop level set ceilings on how many inner loop cycles run before the system escalates to a human.

Here’s an example of a hard budget (sorry, but code incoming!). If you’re confused, just ask Claude Code to evalute this code snippet below.

Practitioners building long running agents in Claude Code have started documenting this publicly as the standard architecture for anything running unattended. Define a goal, define a stopping condition the evaluator can check, set a turn limit, set a cost ceiling, then let it run.

What production actually looks like

Anthropic’s Research feature, which shipped in April 2025, is the most publicly documented orchestrator worker system in production. A lead agent analyzes the query, develops a strategy, and spawns subagents to explore different aspects simultaneously. Each subagent acts as an intelligent filter, iteratively using search tools to gather information, then returning condensed findings to the orchestrator for final synthesis. On internal research evaluations, this configuration outperformed single agent Claude Opus 4 by 90.2%. The detail that matters operationally is what the team had to do to get there: when they started with vague subagent instructions like “research the semiconductor shortage,” agents duplicated work and left gaps. One subagent explored the 2021 automotive chip crisis while two others duplicated work investigating current supply chains, without an effective division of labor. The orchestration prompt, the instructions that tell each subagent its specific scope and output format, mattered as much as the model choice.

OpenTable’s deployment on Salesforce Agentforce, reported in October 2025, shows what this looks like at customer facing scale. The agent reads inbound requests, queries booking and restaurant data for context, determines the policy correct response, executes the action, and escalates only sentiment flagged conversations to a human. OpenTable resolved 70% of diner and restaurant inquiries autonomously, inside weeks. This is a well designed inner loop with clear success criteria and a human review gate for edge cases. That is where most enterprise deployments actually sit.

Uber is the most detailed public account of what happens when you build this at organizational scale. By early 2026, 84% of Uber’s developers were using agentic coding tools daily, and a background coding agent called Minions was producing 1,800 code changes per week across 95% of the engineering organization. AI related costs increased sixfold since 2024, and token cost optimization became its own engineering discipline. They published both sides of that story, which makes it unusually useful as a reference. The cost line is part of the story and always will be.

Where this lands for go to market teams

Looping agents are relevant for a smaller set of revenue workflows than the hype suggests, and genuinely consequential in a few specific ones.

Lead and account scoring is the clearest candidate. Most scoring models today run once and stop. A score gets written to a field, someone acts on it or does not, and nobody validates whether the score was right. A looping approach changes this: the agent scores the account, checks whether the scoring rationale is consistent with what historically happened to accounts with similar profiles, revises if there is inconsistency, and writes to the CRM only when the output clears a quality threshold. This is the same approach Uber’s Genie used for compliance queries, applied to qualification logic. If “account fits ICP” is the claim, the evaluator checks it against historical win data before that claim goes anywhere.

Outreach quality is the second area. Most outbound workflows send messages and move on. Reply rates and meeting data come back asynchronously and only influence the next campaign if someone closes the loop manually. A closed loop agent does this automatically: checks which messages converted, identifies what was different about those that did not, updates its drafting approach, and tests the revision on the next batch.

Agents need closed loop data on which leads converted and which churned to optimize their targeting and qualification. Connecting CRM outcomes back to the agent platform is what makes the loop real.

Forecast review may be the highest value application for RevOps specifically. I have sat through enough forecast calls to know they are human driven processes subject to political dynamics and information asymmetry. An agent that runs a loop checking deal evidence against submitted forecasts, flagging inconsistencies, re-querying call recordings and CRM activity for recent signals, and producing a confidence adjusted view before the call fits the evaluator optimizer design almost exactly. The stopping condition is checkable: does the agent’s read differ significantly from the rep’s submission? If reps have something to hide, I’d bet there’s a difference!

Why most loops fail

Read more

I have many close peers lamenting privately that AI buying decisions are made without a requirements process.

Call it vibe buying if you will.

The board or CEO sets a direction, vendor conversations start, and RevOps gets looped in when someone needs an integration built or a data model mapped. To be expected, but don’t just say yes! Don’t be a wallflower.

The RevOps leader who shows up before that sequence starts, with a structured way of asking what problem the organization is actually solving and whether AI addresses it, is doing exactly what we should be doing in RevOps. Preparation and communication!

This is a professional skill that builds with practice. The discipline of asking the right questions before vendors are in the room, and designing evaluations that expose failure rather than validate a purchase, is how durable credibility gets built in this environment. Being honest about data readiness, even when it’s uncomfortable to say out loud, is the specific skill we as RevOps leaders should continually develop.

Even better if we make the recommendation before someone comes to us with a mandate.

The bottleneck question as professional practice

Ask one question. What is the constraint in your revenue motion right now, and does AI actually solve it?

Revenue operations has three foundational layers. The data foundation defines what you can see and trust. Process documentation captures how work moves through each stage and who owns each transition. Execution thresholds determine when to escalate, accelerate, or exit a deal. The intelligence layer, where AI operates, sits on top of all three. When any of those layers is compromised, AI does not fix it. It operates within it, and often makes the outputs of that layer look more credible than they deserve to be.

Forecasting illustrates this clearly. An AI forecasting tool ingesting data from a CRM where close dates roll monthly and stage definitions vary by rep will produce a confident looking number. Imagine that, a good looking pipeline turns out to be nothing more than a catfished rug pull.

Reps often know when their pipeline data is unreliable and factor that into their calls (or not, and there’s a bit of CYA here). An AI forecasting tool treats every record with equal confidence regardless of underlying data quality, which makes the output look authoritative in ways that may not hold up under pressure.

The RevOps leader who raises this before a tool is purchased saves the organization from a specific class of expensive mistake: AI generated outputs that look authoritative but are built on inputs that haven’t been cleaned. Raising it also signals something important about the RevOps function’s role. The team that asks “is our data foundation ready for this” before anyone else does is not creating friction. It is doing the job the business needs done.

Before deploying intelligence on top of your data, the honest question is whether your data can actually support intelligence. Most organizations in the $20M to $100M ARR range, if they answer this honestly, find that meaningful remediation work comes first.

Being honest about data readiness

The data foundation audit is the least glamorous part of any AI conversation, which is exactly why it gets skipped. Running it requires acknowledging that accumulated CRM hygiene debt, inconsistent field usage, and manual workarounds have produced a foundation that AI cannot learn from reliably. Trust me, I’ve run quite a few paid audits the last few months and I keep hearing how often internal audits go ignored while a third party validates what is already known by internal teams.

You’d think that we would trust our internal teams by now rather than having to wait for a third party to repeat many of the same findings.

Salesforce’s Einstein implementation guides include explicit data quality prerequisite checklists, which exist because of one repeated lesson from enterprise deployments: AI features built on dirty data erode rep trust faster than they build it, because reps immediately recognize when AI generated outputs don’t match their understanding of a deal. HubSpot’s research has documented that a significant share of CRM contact data becomes stale within twelve months of entry. Data in your CRM has a faster expiration date than we hope for.

The diagnostic questions to work through before any AI evaluation are direct. Can you identify the source of truth for every major data entity in your revenue motion and document it clearly enough that a new hire could follow it without interpretation? Are your pipeline stage definitions written down, enforced at the CRM field level, and applied consistently across reps? If different people apply stages based on personal judgment, AI cannot learn a reliable signal from stage movement, because the same event means different things in different records. These two questions alone will tell you more about AI readiness than a vendor proof of concept. The third is whether a documented response exists for the signals AI would surface, because without one, alerts get ignored or handled inconsistently.

If any of these reveal significant gaps, the professional move is to document the remediation work required and set the AI evaluation timeline accordingly. A RevOps leader who arrives at an AI conversation with a data readiness assessment and a remediation plan is positioning the function as the team that understands the actual state of the business. That is a stronger position than being the team that finds out the hard way.

Commodity capabilities and differentiating ones

Part of what makes RevOps leaders credible in AI conversations is learning to distinguish commodity capabilities from genuinely differentiating ones before setting evaluation criteria.

Two years ago, AI call summarization commanded meaningful standalone pricing. Today it ships as standard in virtually every sales engagement platform and CRM, and the same compression is underway with CRM field population and outreach personalization. AI capabilities at the edge of the market are compressing into standard product faster than most contract terms anticipated. Building switching cost analysis and shorter initial terms into commodity capability purchases is how you preserve flexibility as that compression continues.

The build versus buy calculus differs entirely depending on which category the capability falls into. For commodity capabilities, the criteria should favor proven vendors, low switching costs, and short contract terms. The goal is to acquire the capability at reasonable total cost while preserving the flexibility to move when something better arrives. For genuinely differentiating capabilities, which generally means capabilities that require training on your proprietary historical data or encoding your specific business logic, the calculus changes. A scoring model calibrated to your specific ICP signals is not something a vendor replicates out of the box.

Total cost of ownership across three years looks very different from the direct amount spent on headcount. . Implementation time, integration maintenance, rep behavior change, and the ongoing cost of validating AI outputs are where the real numbers accumulate. Building the habit of estimating these before signing is part of how RevOps leaders demonstrate that they are thinking about the business rather than just the tool.

Managing the mandate

The political reality for most RevOps leaders is that arriving at an AI conversation with a requirements process reads as friction. Leadership wants to see movement. The RevOps leader who learns to redirect what speed means, converting a broad mandate into a testable hypothesis with a defined timeline, is doing something professionally valuable.

A requirements process run well, covering a bottleneck diagnosis, a data readiness check, a commodity versus differentiator assessment, and a pilot design with a defined success metric and kill condition, can move in three to four weeks. That timeline reads as diligence when it is communicated as a decision-making accelerator rather than an evaluation delay.

Consider what happens when an AI deployment produces results that nobody can explain, because no one defined success before the pilot started. The RevOps leader running that conversation twelve months later is trying to explain why the tool underperformed without a baseline to reference, a success criterion that was ever written down, or a clear sense of whether the problem was the tool, the data, or the workflow. A better pilot design prevents that conversation entirely. The RevOps leader who arrives at the same situation with documented success criteria and a clean explanation of why a pilot was ended or continued is in a fundamentally different professional position.

What a sound pilot actually looks like

Before the first vendor demo, write down the specific capability being tested, the workflow gap it addresses, the success threshold, and the kill condition. Without them, the pilot runs past its original timeline and someone has to make a judgment call with no agreed basis for making it.

Scope the pilot to a single workflow, a single team or segment, and run it short enough to get a clean read. Six to eight weeks is generally right. Before it starts, write down what success looks like in measurable terms, and agree in advance on the number at which you stop and walk away.

Agree on when you'll stop before the pilot starts. Once a vendor relationship is established and someone internally has become a champion for the tool, walking away becomes a people problem on top of a business problem. The number you agreed to walk away at, set before any of that happened, is the only thing that makes the conversation clean. Without it, pilots drift. Six weeks becomes three months and someone ends up explaining to the CFO why they're still paying for something that hasn't proven itself.

Define the criteria before you take the first call. Know what problems you are solving for.

Read more

This is an expensive meeting so I’d like to make sure we derive an ROI out of it.

The pipeline council exists because pipeline problems cross team lines. A generation gap that requires marketing to change targeting cannot be solved in a sales only pipeline review. A stage conversion problem pointing to a positioning issue needs the person who owns the message present. The rest of this piece is about building a meeting that produces decisions, not just conversation.

What the meeting should do

When a pipeline council devolves into a status update, it usually happens gradually. The first few meetings feel productive because the data is new and the room is engaged. Over time, the dashboards become familiar. The same coverage metrics appear week after week. The discussion follows the same arc: here is the problem, here is who is responsible, here is what we hope will improve.

The mechanics are not complicated. Pipeline councils, as they are most often structured, are built around a data read. RevOps pulls the coverage numbers, stage velocity, and at-risk deals. The room reviews them. People react. Someone volunteers a vague follow-up. The meeting ends without a read-back of actions and without clarity on who owns what by when.

Part of why this persists is that the meeting structure rewards it. Nobody pushes back on symptom language because the meeting was never designed with a standard for what counts as a real problem versus a general concern. The room fills the time it has with the conversation the data naturally produces, which is a description of what is wrong. Then everyone goes back to their day.

The following week, RevOps pulls the same data.

The problem with symptom language

Before you can fix the meeting, you have to define what is broken about the conversation itself.

Revenue teams are good at describing pipeline problems in aggregate. “Pipeline is thin.” “We have coverage risk in enterprise.” “The mid-market segment is underperforming.” These are real observations. They are also not problems you can resolve in a meeting.

A problem you can resolve has a location, a magnitude, and a cause you can actually trace. “Enterprise segment is at 1.8x coverage with eight weeks left in the quarter, and 60% of that pipeline has no logged next step” gives the room something to work with. Is this a generation problem or a stage conversion problem? Are deals stalling at a specific stage? Is the missing next step a rep behavior problem or a data hygiene problem?

When the pipeline council stays at the symptom level, everyone leaves understanding what they walked in knowing.

The shift from symptom to specific problem requires RevOps to do something different with the data before the session starts, and to hold the conversation to a different standard once it is underway. That has to be built into the meeting.

Building the issue resolution layer

The pipeline council needs a resolution layer. Something that changes how the meeting moves from data to decision. This layer has three stages. Every meaningful problem the meeting identifies passes through all three before the room moves on.

Identify the actual problem.

Before the session opens, RevOps translates the session data into two or three problems stated at the level of specificity that lets the room act. That document is not a dashboard. It names the conditions requiring a decision in that session, with enough context that attendees arrive oriented rather than waiting to be briefed.

The identification stage closes when the room agrees on what the actual problem is. If someone says “pipeline is thin” and everyone nods, the stage is not complete. The conversation continues until the room can state the condition specifically enough that you could hand it to someone who was not in the meeting and they would know exactly what to investigate.

That is a different posture than most RevOps practitioners hold in leadership meetings. It is also why the role in this meeting has to be facilitator, not analyst.

Discuss the root cause.

Once the problem is named, the discussion stage has one job: find the cause.

Keep the discussion to ten or fifteen minutes per problem. Marketing explains what drove the generation shortfall. Sales explains where deals are stalling and why. RevOps flags whether the data can be trusted or whether what looks like a pipeline problem is actually a data quality problem sitting underneath it.

The right questions in this stage are causal.

• Why did generation come in short this quarter relative to last?

• Where in the stage progression are deals slowing down, and what is happening to them there?

• Is the coverage number itself reliable given the data we have?

The discussion stage breaks down when the room jumps to solutions before understanding the cause. The room sees a problem, moves to tactics, and spends thirty minutes debating which campaign or play to run. The actions that come out of that conversation may or may not address the actual issue. When they do not work, the room discusses why the following week.

The stage closes when the room can say: the cause of this problem is X.

Solve with an owner and a date.

Every problem that passes through the first two stages leaves the meeting with a decision, a single owner, and a real deadline.

Something specific enough to verify next week. “Marketing activates the dormant enterprise sequence by Thursday. RevOps delivers the target list by Monday.” That has an action, an owner, and a date that is not aspirational.

Without this stage, the meeting notes become a conversation log. Nobody tracks what was decided.

Close every pipeline council with a read back. RevOps reads every action item from the session: the action, the owner, the date. Owners confirm. Meeting ends.

Five minutes and please don’t skip it.

The read back closes the accountability loop. When owners confirm an action out loud in front of the group, the commitment lands differently than when RevOps records something in notes that nobody reviews until the following week. The pipeline councils that do it consistently produce different results in month two than the ones that do not.

Triage before you run the loop

Not every problem that surfaces in a pipeline council deserves the full resolution treatment in that session. Some belong to a different forum. Some require an executive decision not available in the room. Some cannot be resolved by the people present regardless of how long the group discusses them.

Before running the resolution loop, RevOps runs a triage. The question is which problems this group has both the authority and the information to resolve today.

Problems that belong in the pipeline council are the ones where the people present can make a decision and own the execution. Problems that belong elsewhere get assigned with a clear owner and a deadline, then moved out explicitly. They are not parked on a list to be discussed again next week.

The escalation path matters. If a problem requires a decision from someone not in the room, that escalation is itself an action item with an owner and a date, treated the same as any other resolution coming out of the session.

How RevOps runs this meeting

RevOps runs the room. Not just the logistics.

Before the session, RevOps does not just pull data. It translates what it finds into candidate problems, stated specifically. Leaders arrive knowing what the meeting is going to try to resolve, not just what numbers they are about to review. That change alone shifts how people show up.

During the session, RevOps facilitates the triage and holds the room to the problem identification standard. It watches the clock in the discussion stage and redirects the conversation when it drifts from cause to tactics. It names the decision at the close of each problem and confirms the owner out loud before the room moves on.

At the close of the meeting, RevOps reads back every action item. Action, owner, date.

RevOps practitioners hold the analyst role in pipeline reviews. But what the pipeline council really needs is a facilitator. When RevOps makes that shift, the room moves from documenting problems to deciding how to address them.

How you know it is working

Read more

The conversation usually starts with Salesforce CPQ.

Read more

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 …

Read more

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