v0.01 through v0.05 built the conceptual foundation. The GTM system is a product. RevOps is the product team. Operations as code is the foundation. The agentic RevStack is the infrastructure. Separation of concerns is how the layers of actors split the work.
This post is where the framework gets concrete.
A modern revenue system is a system of loops. Each loop covers one stage of the revenue lifecycle. Loops are self-contained, versioned, and measurable. They chain together. Ten of them cover the full lifecycle, end to end.
This is the framework I have been developing, implementing in parallel, and will continue to refine alongside the readers of Ship Revenue. It is not a finished theory. It is a working model of how revenue infrastructure looks when you take the thesis seriously.
The claim
A revenue loop is a self-contained, composable execution unit covering one stage of the revenue lifecycle.
Each loop has six things: config that defines its behavior, logic that executes against that config, inputs that trigger it, outputs that chain to the next loop or humans act on, metrics that describe how well it is working, and feedback that closes it.
Loops are named. Loops are versioned. Loops are reviewable. Loops chain together through well-defined interfaces. Loops can be owned by different teams without stepping on each other, because the interfaces between loops are as important as the internals of any single one.
Ten loops are the canonical set. They cover the revenue lifecycle as most modern SaaS companies experience it: two for planning, three for demand, two for acquisition, two for retention, one cross-cutting. The grouping is not arbitrary. It reflects how revenue work actually clusters at scale.
The framework is also extensible. A company with a significant channel motion may want a Partner loop that manages indirect pipeline and co-selling. A product-led company may want a Product Qualified loop that reads from product telemetry rather than inbound forms. A community-led motion might warrant a Community loop. The canonical ten are the starting point. The structure that makes them composable (anatomy, chains, archetypes) is what lets additional loops plug in without destabilizing the rest.
This is what it looks like when the GTM system is built as a product.
What a loop is
Every loop has the same anatomy. That is not a coincidence. It is what makes loops complete and composable.
Config. Every loop has structured, versioned configuration that defines its behavior. Scoring weights. Routing rules. Play definitions. Threshold values. Quality rubrics. The config changes frequently, is owned by ops, goes through review, can be tested, and can be rolled back with a single commit. The loop’s config does not change what it does; it changes its behavior. This separation is what operations as code actually looks like in execution. Anyone on the team can see, at a glance, what the loop is currently configured to do.
Logic. Every loop has code or agents (or both) that execute against the config. Code handles the deterministic work. Evaluating rules. Running math. Writing to the surfaces of work. Triggering downstream chains. Agents handle the semantic work. Researching prospects. Composing outreach. Classifying unstructured data. Inferring values from ambiguous signals. Evaluating edge cases where deterministic rules cannot produce a clean answer. The logic is engineering-owned and changes rarely. The code does not know what the thresholds are. It reads the config at runtime.
Inputs. Every loop is triggered by something. An event (a new lead is created, an opportunity is saved). A schedule (a weekly scan runs, a daily evaluator kicks off). A chain from another loop (Qualify hands off to Route). An external force (a major attrition event triggers a replan). The trigger defines when the loop runs and what it receives. Different loops are triggered in different ways, which is part of why the framework accommodates multiple loop archetypes.
Outputs. Every loop produces something. A decision. A CRM write. A task. A notification. A downstream chain. An escalation to a human. Outputs are logged. Outputs are explainable. Every decision the loop makes can be reconstructed, after the fact, with its reasoning trail intact. No black boxes.
Metrics. Every loop produces observable signals about its own behavior. How often did it run? How often did it succeed? How long did it take? What was the quality of the decisions it made? These metrics are what lets the team govern the loop without sitting in the loop itself. Monitor the aggregate outcomes. Adjust the config when outcomes drift from intent.
Feedback. Every loop closes. The loop’s outputs become observable through its metrics. Its metrics drive adjustments to its config. Those adjustments change how the next execution runs. Each cycle produces evidence about how the loop should behave, and that evidence shapes the next cycle. The closing happens at three levels. Sometimes the loop closes itself: a scoring model retrains on conversion outcomes, a routing rule auto-tunes based on assignment quality. Sometimes humans close it directly: ops sees grade distribution drifting and updates the scoring weights. And sometimes (increasingly) agents do the interpretive work: they read the metrics, identify patterns, compare current behavior to intended behavior, and propose specific config changes with the evidence to back them up. Humans review the agent’s recommendation, accept or revise it, and merge. The agent does the analysis; the human does the governance. The loop closes faster than humans alone could close it, but the human stays in the loop where it matters: in the policy decisions, not in the per-record approvals.
A loop with all six elements is a first-class primitive. Without any one of them, it is something less. A script. A workflow. An automation gluing systems together. The anatomy is what makes a loop the building block of a coherent system rather than a one-off piece of plumbing.
The chains
The ten loops organize into four chains and one cross-cutting loop. Each chain represents how work actually flows through the system.
The Planning chain. Design and Deploy. The chain plans the architecture of the revenue organization: the ICP, target accounts, audience segments, segment investments, capacity, territories, and compensation that everything else runs against. Design produces the architecture as scenarios. Deploy materializes the scenarios in surfaces of work. The output of the Planning chain is the architecture every other loop reads from.
The Demand chain. Generate, Qualify, Route. Demand-creation activities produce leads. Leads enter the system and get qualified, then routed to an owner. The chain produces demand the rest of the system can act on: qualified, scored, routed records ready for sales engagement.
The Acquisition chain. Engage, Pursue. Engage runs the full prospect engagement arc: outreach composition, the resulting meeting, discovery, and opportunity qualification. Confirmed opportunities move into Pursue, where deal execution runs to close. The chain produces closed customers from qualified demand.
The Retention chain. Onboard and Expand. A customer moves from signed contract through implementation to first value, then through the expansion and renewal lifecycle. Retention is where most modern SaaS revenue actually comes from. It is also where most modern revenue systems have the weakest loop infrastructure.
The cross-cutting loop. Coach. Coach does not chain with the others and does not own a specific stage of the lifecycle. It operates on the outputs of the other chains, aggregating activity and outcomes into development signals for each field team member.
A healthy revenue system runs all four chains and the cross-cutting loop in coordination. Most modern systems have strong Demand and Acquisition chains, weak Retention chains, patchy Planning chains, and almost no cross-cutting capability. This imbalance was tolerable in a seat-based pricing world, where expansion was mechanical and retention was largely a renewal-date event. It is a liability now. As the industry shifts to consumption-based pricing, revenue grows or shrinks continuously with usage, and the Retention chain becomes operationally as critical as the Demand and Acquisition chains. The tools to instrument this shift are arriving. Revenue loops are how you use them.
The ten loops
The Planning chain
Design. ICP definition. Target account lists. Audience and persona segments. Strategic investment allocation across segments and channels. Capacity planning and territory design. Compensation design. Target productivity per role and segment. Ramp curves for new hires. Roster of existing and planned people. Annual targets per territory per measure. The Design loop answers questions like what does our ICP look like for the upcoming year? and which segments are we investing in and at what level? and how much new ACV can we produce next year given this roster and these ramp assumptions? Design operates on scenarios. A scenario is a complete, shareable plan that downstream loops read from. Scenarios can be compared side by side, promoted to active, or retired. Promoting a scenario changes a single line of configuration and becomes the source of truth every downstream loop reads from. Design runs are usually scheduled (annual, quarterly), but they can also be triggered by events that force a replan: a macro shift, significant attrition, a funding round that changes investment capacity, a strategic decision to enter a new segment. In a mature implementation, Design also supports what-if queries driven by agents, where a question like what if we added two enterprise AEs in AMS East next quarter? returns a structured comparison against the current active scenario without writing any files.
Design also runs continuously in a lighter mode, watching whether the active architecture is holding under operational drift. When workload distribution skews (one rep is overloaded and pipeline is starting to go stale, another is underutilized and territory is producing less than it should), Design surfaces rebalancing actions. Reassign these leads. Split this territory. Escalate this pool’s overflow to a backup pool. The continuous mode operates on the outputs of Route and Pursue rather than on customer records directly. Its purpose is to prevent “the routing rules worked correctly” from becoming “one rep has twice the pipeline they can work and another has a territory producing below plan.” Rules that were right at design time can produce bad outcomes under drift, and Design’s continuous mode is how the system catches that drift.
Deploy. Territory management. Quota setting. Comp plan issuance. Deploy takes the architecture from Design and materializes it in surfaces of work. The territory hierarchy. User-to-territory assignments. Role cascades (what happens when a lead matches a territory whose AE seat is open). Account-to-territory assignment. Pool membership for shared coverage. Deploy is a materialized loop, not a per-event loop. It runs when the architecture changes. It reads the declared state from configuration and makes it real in downstream systems, applying the changes in the right order (parent territories before children, structure before assignments). When accounts cannot be matched deterministically (billing data is incomplete, geography is ambiguous, the account’s address is a multi-tenant building that could belong to three different reps), Deploy hands the ambiguous cases to an agent, which resolves them with higher confidence than rules alone. The accounts the agent cannot confidently resolve go into a review queue rather than being guessed. Deploy is where architectural work becomes operational infrastructure.
The Demand chain
Generate. Demand creation. Generate runs the activities that produce the conditions for leads to exist: multi-touch campaigns across channels, account-based programs targeting named accounts, events from field gatherings to large-scale conferences, content programs spanning editorial and SEO, paid media across search and social, partner and community programs, PR and analyst relations. The loop’s outputs are the activities themselves (campaigns running, audiences reached, content published, events held) and the leads those activities produce (form fills, registrations, downloads, conversations). Generate reads from Design (ICP definition, target account lists, audience segments, segment-level investment levels) and from downstream loops (which lead sources are converting, which campaigns produce highest-quality pipeline, which content themes drive engagement). Generate runs in multiple archetypes: campaigns are scheduled (running on cadence), high-intent signals trigger event-driven plays (an ABM motion fires when a target account shows engagement), and campaign planning is itself a modeling activity (segment analysis, channel mix optimization, budget scenarios). Its feedback cycle is long: a campaign launched today might not produce attributable revenue for six months, and the signal-to-noise ratio in attribution is famously poor. This is one of the loops where agent-assisted feedback has the most room to mature, because the interpretive work of “which patterns in our marketing activity actually drove pipeline?” is hard for humans to do at scale and harder still to do in time to act on.
Qualify. Lead qualification. Every new lead enters the system through Qualify, whether it came from an inbound form fill, an outbound signal at a target account, a webinar registration, or any other lead source. Enrichment from third-party providers fills in the firmographic and technographic gaps in the raw lead record. A weighted scoring model evaluates the enriched lead against a defined rubric and produces a score. A grade (A, B, C, D, usually) bucketizes the score into tiers that downstream loops can act on. The enriched, scored, graded lead is written back to the CRM for the field to see. Qualify runs hundreds of times a day at most modern software companies. It is the loop most directly exposed to data quality problems. Bad enrichment produces bad scores, and bad scores produce bad routing. The team governs Qualify by monitoring grade distributions over time (if the A-grade percentage is drifting up, either the product-market fit is improving or the scoring model is losing discrimination) and by reviewing the factor contributions on individual leads that look wrong. The scoring model itself is pure code because the logic is deterministic. The enrichment call is code too. The one place where semantic work appears in Qualify is when the enrichment provider returns ambiguous results and an agent has to decide which of several possible matches is the right one.
Route. Lead assignment. The Route loop takes a scored, graded lead and matches it to the right owner. A rep. A pool of reps. A queue. Route walks a priority-ordered rule set. The first rule that matches fires. Rules can reference territory, segment, lead score, existing account ownership (so that a lead from an existing customer’s domain goes to that customer’s AE, preserving continuity), or any other attribute. Most leads are resolved by a structured rule set. The interesting cases are the ones where the deterministic rules do not produce a clean answer. An agent handles those. The agent has access to the same rules and the same territory structure as the deterministic engine, but it can reason across ambiguous inputs. It reads the lead’s billing city, the company’s headquarters per its own research, the industry vertical, the lead’s own claims about location, and makes a judgment. When the agent’s confidence is high, the assignment fires. When confidence is lower, the lead goes into a review queue with the agent’s reasoning attached. When confidence is very low, the lead lands in a triage queue for human review. The same route engine powers multiple callers in a working implementation: the live routing endpoint that fires on new leads, a simulation tool for testing rule changes against historical leads, and a batch account-to-territory matcher used by Deploy.
The Acquisition chain
Engage. Prospect engagement, end to end. Engage owns the relationship with a prospect from outreach through opportunity qualification, in two phases.
The first phase is outreach. An agent researches the prospect company using available sources. It drafts a personalized email sequence (typically three to five emails, spaced appropriately). It scores the quality of what it produced against a multi-criteria rubric (relevance, personalization, specificity, calls to action, tone, length, formatting). The sequence lands in a review queue. The assigned rep reviews it. The rep approves or rejects it or makes revisions. The approved sequence gets deployed to the engagement platform. The rep is not doing the composition. The rep is governing the composition. That is the separation of concerns from v0.05 in production.
The second phase is discovery and qualification. When the outreach produces a meeting, the rep leads the conversation. The rep listens for the qualification dimensions that matter (problem fit, urgency, authority, decision process). Call intelligence platforms listen alongside, capturing the conversation, structuring it against the team’s framework (BANT, MEDDIC, MEDDPICC, custom), and in many cases populating the qualification dimensions directly from what was said. Agents support the rep further by flagging dimensions still uncovered and suggesting follow-up questions for the next meeting. The rep reviews, adjusts, and commits the qualification. The output of Engage is either a confirmed sales-qualified opportunity ready for Pursue, or a disqualification with reasoning that returns the prospect to a nurture state.
The config for Engage spans both phases. Plays, research prompts, and quality thresholds shape outreach. The qualification framework, disqualification rules, and handoff criteria to Pursue shape discovery.
Pursue. Deal lifecycle and health. When Engage hands off a confirmed sales-qualified opportunity, Pursue selects a deal play based on account characteristics and context from the discovery conversation. A small deal gets a fast-track play with minimal structure. A large deal gets a multi-thread play with stakeholder mapping, champion development milestones, and executive engagement steps. The play creates milestone tasks, aligned to the sales methodology, with staggered due dates. The rep works the tasks. Alongside the event-driven side of Pursue, a scheduled evaluator runs daily against every open opportunity. It looks for staleness (no activity in N days), close-date risk (the deal’s close date is within a window but key milestones are unmet), pipeline health problems (the stage duration does not match the velocity target), and other signals of trouble. When a signal fires, the evaluator delivers a nudge through preferred channels (Slack, email, CRM notification). Pursue is the loop that owns the longest, hardest stage of the revenue lifecycle. It is also the loop most directly consumed by managers, who see the aggregate behavior of their team’s deals and use it to coach and forecast.
The Retention chain
Onboard. From close to first value. The Onboard loop takes a new customer from signed contract through implementation, training, adoption milestones, and first value. It drives the tasks that the account team owns (kickoff call, data migration, first workflow deployed, team trained, first outcome achieved). It tracks the milestones against a timeline and flags when the customer is falling behind. It monitors health signals during ramp (login frequency, feature adoption, support ticket volume, sentiment from calls). It hands off to Expand when the customer is live, healthy, and realizing value. Onboard is the least-built-out loop across most modern revenue systems. Most companies run onboarding as a set of checklists owned by a CS manager with little programmatic infrastructure. The tasks and milestones live in a project management tool. The health signals live in a BI tool. The handoffs happen through Slack messages. This is not a stage where loops cannot work. It is a stage where the business model made it less urgent. Under seat-based pricing, revenue was largely decoupled from first-value time. Under consumption pricing, first-value time determines when revenue starts. The infrastructure to instrument Onboard has been arriving. The urgency to use it is arriving now. Onboard is a frontier. The team that builds this loop well will have a meaningful structural advantage over teams that do not, because first-value time drives retention and retention drives the rest of the business.
Expand. Renewal management and growth. Expand manages the customer through the renewal cycle and the full range of expansion plays: upsell, cross-sell, seat growth, product adoption, multi-year conversion. It applies the same rigor as Qualify, but to expansion opportunities rather than net-new ones. An account’s expansion potential reflects usage trajectory, adoption depth, engagement with the account team, signal strength from product telemetry, and commercial context (time to renewal, current contract shape, known buying-committee changes). When expansion signals are present, plays fire: executive business reviews, upsell motions, risk intervention, multi-year negotiation. When renewal approaches, the loop surfaces the risks and opportunities to the account team with enough lead time to act. Expand is where the thesis meets business reality. Most modern SaaS revenue is expansion, not new logo. A team that treats expansion as “the CS team handles it, we’ll see how it lands at renewal” is leaving the biggest lever in the business unmanaged. A team that runs the Retention chain with the same rigor applied to the Demand and Acquisition chains gets compounding returns.
The cross-cutting loop
Coach. Rep development. Coach aggregates structured signals from call intelligence, activity patterns, deal outcomes, and conversion metrics into coaching signals for each team member. It identifies patterns. Reps who discover well but close poorly. Reps whose deal velocity is faster than average but whose deal size is smaller. Territory-level skill gaps. Pipeline quality drift. The loop surfaces the patterns to managers, who use them to direct their coaching conversations and to decide where to invest training time. Coach does not replace the manager. It gives the manager better situational awareness than “I watched this rep’s last three calls and here’s what I think.” The inputs are structured, consistent, and longitudinal. A manager with Coach sees patterns they could not see from sampling. Call intelligence platforms produce the per-call signals (discovery quality, technical demo effectiveness, objection handling, qualification rigor). Agents extend this work by reading across many calls and many reps, surfacing coaching themes and skill-development trajectories that no single call could reveal. Coach is where the semantic work of the agentic RevStack pays off as leverage for the people who manage the field
How loops compose
Loops are useful because they compose. A loop in isolation is just an automation. Loops chaining together are a system.
Every handoff between loops is a well-defined interface. The sending loop produces a specific shape of output. The receiving loop expects that shape as input. When Engage changes its research approach, Route does not need to know. When Route adds a new rule, Qualify does not need to know. The chain is a contract between loops.
A worked example helps. A new lead comes in from an inbound form fill on the company’s website, produced by a Generate campaign that put a piece of content in front of the prospect. Qualify enriches and scores the lead, which lands at 91 (an A grade). Qualify hands off to Route. Route walks the rule set: the lead doesn’t match rule 1 (existing customer’s domain) but matches rule 2 (A-grade commercial in North America), and gets assigned to the North America commercial pool, which routes to the rep with the fewest open opportunities. Route hands off to Engage. Engage’s agent researches the prospect, finds the company just raised a Series B, and drafts a three-email sequence positioning the product against the scaling challenges a newly-funded growth company faces. The sequence passes all seven criteria of the quality rubric and lands in the rep’s review queue. The rep reviews it the next morning, makes a small tweak, approves. The sequence deploys to the engagement platform. The whole flow took ten seconds of compute and sixty seconds of rep attention. That is three loops chained through well-defined interfaces, with code, agents, and humans each doing the work they are best at. The flow also crosses a chain boundary at the Route-to-Engage handoff, where automated lead processing gives way to sales-led prospect engagement.
The same chain handles outbound. Instead of a form fill triggering Qualify, an outbound signal does: a target account raised a Series B, a key executive changed roles, a competitor’s customer showed churn signals. Qualify scores and qualifies the signal the same way it scores inbound leads. Route assigns it to the right territory. Engage composes outreach with a signal-specific play. The framework does not prescribe how the signal is detected: scheduled scans, intent-data webhooks, or agent-driven research all work. It prescribes how the resulting signal flows through the Demand chain into the Acquisition chain.
Loop archetypes
Not every loop fits the same shape. The framework works at scale because it allows for different loop archetypes, each suited to a different kind of work.
Event-driven loops. Most of the Demand and Acquisition chains. Triggered by a record event (a new lead is created, an opportunity is saved). Runs once per event. Produces outputs that chain to the next loop. Qualify, Route, the outreach side of Engage, and the deal play side of Pursue all follow this archetype. Fast. High volume. Per record.
Scheduled loops. Run on a schedule against a population of records. Generate’s campaigns run on cadence. Design’s continuous monitoring mode runs against workload distribution to surface rebalancing actions. Pursue’s daily nudge evaluator runs against every open deal. Scheduled loops do not react to events. They observe state and decide whether to act.
Materialized loops. Deploy is the main example. Runs on demand to make a declared architecture concrete in the live system. Not per record. Not scheduled. Triggered when the declared state changes (a new scenario is promoted, a new user is added, the territory structure is revised). Reads the desired state from configuration. Computes what needs to change. Applies the changes in the correct order.
Modeling loops. Design’s primary mode. Runs interactively rather than automatically. Each run executes a model against a set of inputs to produce a shareable artifact (a scenario, a forecast, a capacity projection). The output is not a per-record decision but a complete, reviewable plan that downstream loops read from. Modeling loops are where humans do the most hands-on work, because setting direction is human work.
Naming the archetypes matters because it prevents readers from collapsing “loop” into “webhook automation.” The framework is richer than that. Different work needs different loop shapes. A healthy revenue system runs all four archetypes. Some loops run in multiple archetypes within their own work: Design runs in modeling for full planning and scheduled for continuous rebalancing; Generate runs in scheduled for campaigns, event-driven for ABM plays, and modeling for campaign planning; Engage runs in event-driven for outreach and human-led for discovery. Multi-archetype loops are a feature of the framework, not a contradiction.
Build versus buy
Worth clarifying, since I have been getting questions. This framework does not imply that every loop must be custom-built.
A loop is defined by its anatomy. What matters is that all six elements are present. Not where the code came from.
Vendor tools can be loops, if they expose their configuration as reviewable artifacts, log their decisions in auditable detail, chain cleanly into other loops through stable interfaces, and surface their behavior in ways that let humans or agents close the feedback cycle. A vendor CRM can be the surface where Qualify’s outputs live, as long as the scoring logic is versioned and the decisions are auditable. A vendor workflow engine can run the Route logic, as long as the rules live in structured, reviewable configuration. A vendor engagement platform can deploy sequences, as long as the composition and quality-scoring layer produces explainable outputs. An off-the-shelf planning tool can run Design, as long as scenarios are first-class and the promoted scenario becomes the source of truth for downstream loops.
Custom code can be loops too, if it holds to the same principles. Most working systems are hybrids. The framework is about what loops look like, not about where they come from.
Engineering capacity is scarce. Apply it to unsolved problems. A team that rebuilds what vendors already do well is burning cycles that should go to the frontier. The frontier is the loops and capabilities the market has not yet commoditized: pipeline health intelligence that actually works, cross-tool observability, conversational surfaces over the whole revenue stack, the coherent data fabric that lets loops chain without fragile glue. These are where custom engineering creates structural advantage.
The other side of the rule matters too. Some vendor categories exist because the vendor provides something you genuinely cannot build: a data graph, a network effect, specialized infrastructure like call intelligence or an engagement platform, or a compliance surface that would take years to replicate. Buying there is not about convenience. It is about the fact that the vendor’s product is their data, their network, or their accumulated expertise, and your engineering team cannot conjure those things.
Between the frontier and the genuine-vendor-value category sits a lot of work that is neither. Scoring logic. Rule evaluation. Simple workflow orchestration. API calls against a handful of data providers. These are trivial code. A single revenue engineer with modern tooling can build a working scoring-and-routing engine in a week. The question for these layers is not “which vendor do I buy?” but “is this worth owning?” Building takes a week. Owning takes years. Someone has to maintain it, patch it when the upstream API changes, document it when the original builder leaves, and carry the context forward. The vendor does all of that in exchange for a subscription fee. Sometimes that trade is worth it. Sometimes the vendor is adding a UI and a subscription fee on top of code so simple that the maintenance cost is negligible and the ownership benefits (full control of logic, first-class agent access, no per-seat tax on programmatic usage) are worth paying for. The decision is per-loop, per-team, and often per-year.
The questions that matter when evaluating a vendor for a loop position are not “does it do the thing?” but “does it hold the principles?” Does its configuration live somewhere you can version and review, or is it buried in a UI where every change is lost to history? Can you reconstruct the reasoning behind any specific decision it made? Will it chain into your other loops through a stable API, or will you be writing fragile glue between it and the rest of the system? Can agents query and act on it through MCP or equivalent, or is it a walled garden? Does it surface its behavior in ways that let you close the feedback cycle, or is the feedback layer locked away from you? These are the build-versus-buy questions worth asking. Most vendors fail several of them today. Over time, fewer will.
What this unlocks
When the revenue system is built as a system of loops rather than a tangled mess of tools and tribal knowledge, five things change.
Change cycles shrink. A change to scoring is a change to one configuration file in one loop. A change to territory structure is a commit to Design. A change to outbound plays is a change to Engage’s play definitions. The team is not hunting through five tools to find where the behavior lives. The behavior lives in the loop. A routing rule change that used to take two weeks (find the logic in three tools, test by hand, coordinate across ops and engineering, hope nothing else breaks) takes twenty minutes (edit the configuration, run the simulation against recent leads, commit, deploy). That is the operations-as-code compounding effect from v0.03 made concrete at the loop level.
Interfaces stay clean. Each loop reads from well-defined inputs and writes to well-defined outputs. When the Route loop changes, Qualify does not need to know. When Engage changes its research approach, Route does not need to know. This is classic software engineering discipline applied to revenue infrastructure. It is what makes the system maintainable as it grows. A company that adds a new loop to the system (say, a Partner loop that manages indirect pipeline) does not have to touch the existing loops. The new loop plugs into the chain through the standard interface.
Experimentation becomes cheap. A new scoring model is a new branch of a Qualify configuration. A new routing rule is a new entry in Route’s rule set. A new play is a new entry in Engage or Pursue. Experiments are scoped to a single loop, testable against historical data before deployment, and reversible with a commit revert. The cost of trying something new drops by an order of magnitude. A team that runs one scoring experiment a quarter under the old model can run one a week under the new one.
Teams scale without chaos. As the team grows, new people own new loops or new configuration within existing loops. The loop boundary is the team boundary. One team can own Generate, another can own Qualify, a third can own Engage. Each team ships at its own pace. The chains give the teams a shared contract. A RevOps team of three running a few loops looks different than a RevOps team of fifteen running the full set, and the framework scales across that range because the units of ownership are clear.
Governance becomes structural, not procedural. The governance layer (humans) operates on loops, not on individual records. Threshold settings. Escalation rules. Quality rubrics. Scenario approvals. Policy changes. These are the artifacts of governance, not approval queues. When governance is healthy, humans are writing specs and reviewing drift, not clicking approve on every agent output. This is the operationalized version of the v0.05 claim: governance is authorship.
The compounding effect is real. Each loop that gets built makes the next loop cheaper to build. Each interface that gets cleaned up makes the system more navigable. Each experiment that runs produces evidence that improves the framework. The framework is not a destination. It is a direction of travel.
What comes next
Revenue Loops is the framework. Future posts will go deeper.
This framework is not finished. We have two decades of refinement behind the Demand and Acquisition chains, with mature patterns for demand creation, lead qualification, routing, sequencing, discovery, and pursuit. The Retention chain is genuinely earlier, particularly under consumption-based pricing, where the operational requirements are still emerging. We have learned a lot in the last few years, but Onboard and Expand have meaningful maturation ahead. I am developing the framework and implementing it in parallel, working those questions out as I build. The readers of Ship Revenue who are building in this direction are welcome, encouraged, to push back, question the framing, and contribute to the evolution.
The GTM system is a product. RevOps is the product team. Revenue engineering is the discipline. Revenue loops are how the system actually gets built.
If any of this resonates, if you are building this or wishing someone would, subscribe. Or reply to this post and tell me what you are working on. I read everything.
– Andrew