Revenue architecture is the design of the whole revenue system, acquisition, onboarding, adoption, expansion, and the org and data structure underneath all of it, as one deliberately connected object rather than three departments that hand off a deal and hope the next team catches it cleanly. The word "architecture" does real work here. A strategy states which markets or segments to pursue. A process states the steps a team runs this week. An architecture specifies the components, how they connect, and what a change in one predictably does to another, the same way a building's architecture determines what happens to the floor above when you move a load-bearing wall on the floor below.

This page treats revenue architecture as that design discipline: the layers a coherent system needs, the interfaces where most revenue systems actually fail, how to recognize when an architecture has quietly gone incoherent, and what forces a redesign. It sits inside growth frameworks as the structural layer underneath everything else in the collection. It isn't revenue operations, the function that runs an architecture day to day once it exists, and it isn't a growth model, which is one motion, one acquisition-to-expansion loop, operating inside whatever architecture a company has actually built.

Key Facts: Revenue Architecture Reality Check

Winning by Design, the firm founded by Jacco van der Kooij, updated its Bowtie Model in October 2023 to give go-to-market teams a standardized customer journey and data model spanning acquisition through expansion. (Winning by Design, October 2023)

Van der Kooij published the 556-page Revenue Architecture textbook in April 2024, framing recurring revenue growth as an engineered system with inputs, processes, and outputs rather than a set of disconnected departmental motions. (Winning by Design, via AI Journal, April 2, 2024)

Median net revenue retention across the 230 SaaS and AI-native companies that reported it, out of 342 surveyed, sat at 102% for full-year 2025, with usage-based pricing posting 108% against seat-based at 98%, evidence that how the revenue model layer is designed measurably changes expansion outcomes. (Aleph, SaaS Benchmarks 2026)

86% of B2B purchases stall during the buying process and 89% involve two or more departments, a buying reality that turns a coordinated acquisition-to-close interface into a design requirement rather than a nicety. (Forrester, December 2024)

Procurement professionals now act as decision makers in 53% of business buying cycles, engaging from the start of the process, one more stakeholder the acquisition side of the architecture has to be designed to hand off to correctly. (Forrester, January 2026)

Strategy, Process, and Architecture Are Three Different Layers

The three words get used interchangeably in most go-to-market conversations, and that's exactly what causes a "strategy" meeting to produce nothing but a slide, or a "process" fix to quietly break something two teams away. Each word answers a different question, on a different timescale, and confusing them is how a tactical fix gets asked to do an architectural job.

Strategy answers which markets, segments, and motions to pursue, and it's revisited on a roughly annual cycle. Process answers the steps a team runs to execute today's chosen motion, and it gets tuned constantly, sometimes weekly. Architecture answers what the components are, how they connect, and what a change in one predictably triggers somewhere else, and it's built deliberately rather than edited casually, because editing it casually is exactly how systems go incoherent.

Layer	Answers	Typical Time Horizon	Example
Strategy	Which markets, segments, and motions to pursue, and why	Annual, revisited on major shifts	"We're moving upmarket into mid-market accounts next year"
Process	The steps a team runs to execute today's chosen motion	Weekly to quarterly	"A rep logs the call, updates the stage, and books next steps within 24 hours"
Architecture	The components, their interfaces, and what a change in one does to another	Built deliberately, redesigned rarely and on purpose	"Switching from seat-based to usage-based pricing requires new metering, new sales comp, and a new onboarding sequence"

The practical test for whether a change is tactical or architectural is simple: does it stay inside one team's process, or does it ripple into a layer somebody else owns.

Change	Type	What It Touches	What It Doesn't Touch
Rewriting a cold email subject line	Tactical	One sequence's open rate	Anything outside that sequence
Adding a qualification question to a form	Tactical	Lead routing at one stage	The rest of the customer journey
Moving from seat-based to usage-based pricing	Architectural	Metering, billing, sales compensation, onboarding, renewal motion, forecasting	Nothing; it ripples through every layer at once
Adding a second product line	Architectural	Segmentation, packaging, the cross-sell motion, support structure, the data model	Nothing; it forces a redesign of nearly every layer

A team that treats an architectural change as if it were tactical, rewriting one team's process and calling the redesign done, is exactly how a pricing change ships without the sales motion able to sell it, a symptom covered later on this page.

The Bowtie: Why Recurring Revenue Needed a Wider Picture

For most of the sales funnel's history as a mental model, the picture stopped at the signed contract. Everything before the close got instrumented in detail: stages, conversion rates, forecast categories. Everything after it lived in a different system, owned by a different team, measured on a different cadence, if it was measured at all. Recurring revenue broke that picture, because a signed contract in a subscription business isn't the finish line, it's closer to the starting gun for onboarding, adoption, renewal, and expansion, each of which can add to revenue or quietly take it away.

Winning by Design, the B2B revenue consultancy founded by Jacco van der Kooij, built the Bowtie Model to replace the funnel with a shape that has two equally instrumented halves. The left side covers acquisition: the traditional territory of prospecting, pipeline, and close. The right side, the half a funnel simply doesn't draw, covers onboarding, adoption, and expansion, tied back into the same customer journey with its own stage definitions and its own metrics. The firm updated the model in October 2023 specifically to give go-to-market teams a standardized data model for that full journey, not just the pre-close half of it.

Dimension	Traditional Funnel	Bowtie Model
Where it ends	The signed contract	It doesn't end; the right side loops back into expansion and referral
What gets instrumented	Awareness through close	Acquisition and onboarding, adoption, and expansion, with equal rigor
Who typically owns the right side	Often nobody, or an under-resourced customer success team working from a spreadsheet	Customer success and product, designed in from the start with named metrics
What it explains	Why a deal closed or didn't	Why revenue compounds, plateaus, or leaks after the contract is signed
Origin	A generic marketing and sales convention, not attributed to one firm	Winning by Design, updated October 2023

The point of drawing the right side at all is that it makes the post-sale half a design problem instead of an afterthought. Net revenue retention is the single number most companies use to check whether that right side is actually working, but the number is a lagging read on the architecture, not a substitute for designing it.

The Five Design Layers of a Revenue Architecture

A revenue architecture isn't one drawing, it's a stack of layers that each need their own deliberate design, and a company can have a strong layer sitting right next to a weak one without anyone noticing until the weak one breaks something. Five layers cover most of what a working architecture needs to specify: the revenue model, the go-to-market motion, the customer journey, the data model and metrics, and the org and hand-off design.

The revenue model decides how money gets charged and whether it recurs on its own or needs re-selling every cycle; a look at SaaS pricing models covers the tradeoffs between the mechanics available, and where the charge is metered rather than fixed, the usage-based revenue model covers what that choice forces on billing, compensation and forecasting. The go-to-market motion decides which combination of self-serve, sales-led, and partner-led reaches which segment, and the go-to-market framework covers the order those decisions have to be made in. The customer journey defines what each stage of the bowtie actually means and what has to be true to exit it. The data model and metrics layer defines a single, shared definition of a customer, an opportunity, and a renewal, so three teams stop reporting three different numbers for the same thing. And the org and hand-off design layer decides who owns each interface between the first four layers, since a layer with no named owner at its edges is the layer that breaks first.

Layer	Core Design Questions	Failure Signal If Left Undesigned
Revenue model	How does money get charged, and does it recur on its own or require re-selling?	A pricing model the sales motion can't actually sell, or one that caps expansion before it starts
Go-to-market motion	Which combination of self-serve, sales-led, and partner-led reaches which segment, and who owns each?	Two motions competing for the same account with no rule for which one wins
Customer journey and stage definitions	What does each stage mean, and what has to be true to exit it?	The same account sitting at a different stage in two different systems
Data model and metrics	What is the single, shared definition of a customer, an opportunity, and a renewal?	Marketing, sales, and customer success each reporting a different number for how many customers exist
Org and hand-off design	Who owns each interface, and what does a clean hand-off actually require?	A deal that closes and then sits untouched for weeks before onboarding starts

None of the five layers works in isolation, which is exactly why the interfaces between them, not the layers themselves, are where most revenue systems fail.

The Interfaces Between Layers: Where Most Revenue Systems Actually Fail

A layer rarely fails on its own terms. Marketing can define leads correctly, sales can run a disciplined process, and customer success can genuinely care about the account, and the system can still leak revenue at the seams where those three hand off to each other. The interfaces are where a revenue architecture earns or loses its coherence, because a hand-off with no explicit contract defaults to whatever the two teams on either side happen to assume about each other.

Four interfaces account for most of the damage in practice: marketing to sales, sales to onboarding, onboarding to customer success, and the renewal and expansion loop feeding back into acquisition. Each needs an explicit definition of what crosses the boundary and in what state, not an informal understanding that erodes the moment either team changes headcount or leadership.

Interface	What a Clean Hand-off Requires	Typical Failure
Marketing to sales	A shared lead definition and a response-time agreement both sides actually honor	Sales quietly stops working leads it doesn't trust, regardless of what marketing calls them
Sales to onboarding	Every commitment made during the sale documented before the contract signs	Onboarding discovers promises nobody told them about, usually from an unhappy customer
Onboarding to customer success	A documented account state at hand-off: what was set up, what was promised, what's still open	Customer success starts from zero, re-discovering the account and losing the goodwill built during onboarding
Renewal and expansion back into acquisition	Expansion wins and referral data feeding the next quarter's targeting and messaging	Expansion happens, but nothing about who expanded or why ever reaches the team building next quarter's target list

A pipeline operations system is one place the marketing-to-sales interface gets operationalized with actual tooling rather than a policy document, and a revenue efficiency model is a useful lens for deciding which of these interfaces is costing the most before investing in fixing all four at once.

Signs an Architecture Has Gone Incoherent

An incoherent architecture rarely announces itself as a crisis. It shows up as a handful of specific, checkable symptoms that get explained away individually long before anyone connects them to a shared cause: a design gap, not four unrelated problems.

Symptom	Root Cause
The same customer is counted differently in two systems	No single source of truth for the customer record across marketing, sales, and billing, a problem the source of truth for revenue data is built to fix
A pricing model the sales motion can't sell	The revenue model was designed without checking it against the go-to-market motion that has to sell it
An expansion promise nobody is staffed to deliver	Sales sold a roadmap item or a service level the org design never allocated headcount to support
Metrics improve while revenue does not	A team is optimizing its own layer in isolation, MQL volume or activity counts, with no tie back to a shared data model or actual bookings
A deal closes and then stalls for weeks before onboarding starts	No designed hand-off contract exists at the sales-to-onboarding interface

Each of these traces back to a specific, nameable gap in one of the five layers or one of the four interfaces above, which is the point: an incoherent architecture is diagnosable, not just a vague sense that something feels off.

Coherence Levels: From Ad Hoc to Designed

Architectures don't jump from broken to coherent in one project. They move through recognizable levels, and knowing which level a company is actually at, rather than which level the last strategy deck claimed, is most of the diagnostic work.

Level	What It Looks Like	Evidence You're Actually There
Ad hoc	Each function invents its own definitions and hand-offs as it goes	Basic counts, like how many customers exist, are disputed in most meetings
Documented	Hand-offs are written down somewhere	A policy doc nobody actually follows under deadline pressure
Instrumented	Journey stages and shared metrics live in one system everyone can see	A dashboard people reference in real meetings, not just export for a board deck
Designed	Layers were built to interact deliberately, with a named owner for each interface	A pricing or motion change gets modeled across every affected layer before it ships
Self-correcting	Incoherence signals get caught and routed to an owner automatically	A recurring architecture review with real authority to block a change, not a slide nobody revisits

This ladder runs in parallel to, but isn't identical to, the RevOps maturity model: RevOps maturity describes how well the function runs the architecture day to day, while this ladder describes how coherent the architecture itself is underneath that function's work.

What Forces a Redesign

A working architecture doesn't need touching just because a quarter was slow. It needs redesigning when something changes the assumptions the current layers were built around, and ignoring that trigger doesn't preserve stability, it just delays the reckoning to a more expensive moment.

Trigger	What It Forces to Change	Risk of Ignoring It
A new segment (moving upmarket or downmarket)	Customer journey stage definitions, the sales motion, the org structure	Selling deals the fulfillment side of the architecture was never built to support
A pricing model change	The revenue model, the metering and data model beneath it, sales compensation, the renewal motion	Sales sells a model billing can't invoice correctly, or that quietly caps expansion
A second product line	Segmentation, packaging, the cross-sell motion, support structure	Two products competing for the same rep's attention with no rule for which one wins
An acquisition (M&A)	Every layer at once, run on two separate architectures simultaneously	Two revenue systems operating in parallel indefinitely, doubling every interface failure above

A land and expand strategy is often the specific plan that surfaces the second product or new-segment trigger first, since sizing the first deal and pricing for future expansion is itself a bet about how the architecture will need to flex later.

Redesigning Without Stopping the Business

The mistake most redesigns make is treating the fix as a single cutover: turn off the old motion, turn on the new one, and hope the interfaces reconnect cleanly on day one. A revenue architecture has live revenue running through it while it's being redesigned, so the work has to happen in a sequence that never fully stops the business it's redesigning.

Phase	Focus	Exit Criteria
Diagnose	Map the current architecture against the five layers and find the interface that's actually failing, not the one that's assumed to be failing	A named root cause, backed by the symptom-to-root-cause pattern above, not a guess
Design the target state	Redesign the affected layer or layers, and trace every interface they touch	Every owner on the affected side of each interface has reviewed and signed off on the change
Pilot on a bounded slice	Run the new design against one segment, one region, or one team before full rollout	The pilot shows the intended metric moving with no new symptoms appearing elsewhere
Roll out in dependency order	Deploy fully, oldest interface dependency first, without shutting down the still-running old motion	Old and new architectures run in parallel briefly without confusing a live customer
Retire the old path	Complete the cutover	No account is still routed through the deprecated interface

Skipping the pilot phase is the single most common way a redesign turns into an outage: a change validated only on paper meets a real interface, usually the sales-to-onboarding one, and the gap between the design and the actual hand-off shows up in front of a customer instead of in a review meeting.

Boundaries: Architecture, Revenue Operations, and the Growth Model

These three terms get used almost interchangeably in casual conversation, and the collapse causes real damage: a company hires a RevOps lead and expects the architecture to redesign itself, or builds one growth model and calls the whole revenue system done.

Concept	What It Is	What It Isn't	Who Typically Owns It
Revenue architecture	The design of the whole system: the five layers, their interfaces, and what a change in one ripples into elsewhere	Not a function or a daily task list; not something that runs itself	Usually a CRO or COO function, designed together with RevOps leadership
Revenue operations	The function that runs and maintains the architecture day to day, and often proposes when it needs to change	Not the design itself, even though good RevOps teams influence it constantly	RevOps leadership; see what is revenue operations and the RevOps framework
Growth model	One motion, one specific acquisition-to-expansion loop, operating inside whatever architecture exists	Not the architecture itself; a company can run several growth models on one shared architecture	Growth or GTM leadership; see growth model components

A company can have excellent RevOps discipline running a genuinely incoherent architecture, and a well-designed architecture can host more than one growth model at once, a product-led motion and a sales-led motion, for instance, sharing the same data model and org design underneath. The three concepts sit at different altitudes, and confusing them is how "we hired a RevOps team" gets mistaken for "we fixed the architecture."

Conclusion

Revenue architecture is the discipline of treating acquisition, onboarding, adoption, and expansion as one designed system rather than three departments that hand off a deal and hope for the best. The five layers, the revenue model, the go-to-market motion, the customer journey, the data model, and the org design, each need deliberate design, and the interfaces between them, not the layers in isolation, are where most systems actually fail. An incoherent architecture is diagnosable: the same customer counted twice, a pricing model sales can't sell, an expansion promise nobody can deliver, and metrics that improve while revenue doesn't, each traces to a specific, nameable gap.

Redesigning gets triggered by real events, a new segment, a pricing change, a second product, an acquisition, not by a quarter that felt slow, and it has to happen in a sequence that never fully stops the business running through it. Getting the boundaries right matters as much as getting the layers right: revenue operations runs the architecture, a growth model is one motion inside it, and neither substitutes for the design work this page describes.

Frequently Asked Questions about Revenue Architecture

What is revenue architecture?

Revenue architecture is the design of the whole revenue system, acquisition, onboarding, adoption, expansion, and the org and data structure underneath it, as one deliberately connected object. It specifies components and interfaces the way a building's architecture does, so a change in one place has a predictable consequence somewhere else, rather than treating growth as three departments handing off a deal.

What's the difference between revenue architecture and revenue operations?

Revenue architecture is the design: the layers, their interfaces, and what a change in one does to another. Revenue operations is the function that runs and maintains that design day to day, and often proposes when it needs to change. A company can have strong RevOps discipline running an architecture that is still genuinely incoherent underneath it.

What is the Bowtie Model and who created it?

The Bowtie Model is a framework from Winning by Design, the B2B revenue consultancy founded by Jacco van der Kooij, that replaces the traditional funnel's stop at the signed contract with two equally instrumented halves: acquisition on the left, and onboarding, adoption, and expansion on the right. The firm updated the model in October 2023 to standardize the customer journey and data model across that full loop.

How is a growth model different from a revenue architecture?

A growth model is one motion, a specific acquisition-to-expansion loop, running inside whatever architecture a company has built. Revenue architecture is the underlying design that motion runs on. A company can run more than one growth model, a product-led motion and a sales-led motion, for instance, on a single shared architecture.

What's an example of an architectural change versus a tactical change?

Rewriting a cold email subject line is tactical: it touches one sequence and nothing else. Switching from seat-based to usage-based pricing is architectural: it forces new metering, new billing logic, new sales compensation, a new onboarding sequence, and a new renewal motion, all at once, because it changes a layer every other layer depends on.

How do you know a revenue architecture has gone incoherent?

Watch for specific, checkable symptoms: the same customer counted differently in two systems, a pricing model the sales motion can't actually sell, an expansion promise nobody is staffed to deliver, metrics improving while revenue doesn't, and deals that close and then stall before onboarding starts. Each traces back to a nameable gap in a layer or an interface, not a vague sense that something is off.

What forces a company to redesign its revenue architecture?

Four triggers show up most often: moving into a new segment, changing the pricing model, adding a second product line, and completing an acquisition. Each one invalidates assumptions the current layers were built around, and delaying the redesign doesn't preserve stability, it just moves the cost to a later, more expensive moment.

Can a company redesign its revenue architecture without stopping the business?

Yes, but only by sequencing the work: diagnose the actual failing interface, design the target state and get every affected owner to sign off, pilot the change on a bounded slice before full rollout, deploy in dependency order while the old motion keeps running, then retire the old path last. Skipping the pilot phase is the most common way a redesign turns into a customer-facing outage.

About the author

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.

View full profile LinkedIn