The Four-Layer Operating Model
Most AI projects begin one step too late.
Someone sees a compelling product, watches a polished demo, or learns that a competitor is deploying agents. The conversation jumps straight to the model, the application, or the integration. The company starts choosing technology before it has defined the work.
That sequence produces impressive prototypes and weak operating systems.
At RevSystems, I organize the work differently. Every opportunity moves through four layers:
User and workflow
Context and data
Runtime and tools
Governance and observability
The names are simple on purpose, it makes them easy to remember!
This is not an enterprise architecture diagram. It is a way to force the right questions into the right order before a recommendation becomes a build.
The framework also reflects a deeper belief about Revenue Operations.
RevOps is no longer the function that administers the revenue stack. It’s becoming the discipline that designs how commercial work happens across people, data, software, and intelligent systems.
That is the work I am building RevSystems to do.
Start With the Work
The first question is not: “Which AI product should we use?”
The first question is: “What are we trying to get done?”
Every system begins with a user, a recurring workflow, and an economic result.
I ask who does the work, what decision they must make, what they produce, how often the work occurs, where it breaks, and what failure costs.
“Improve sales productivity” is not a workflow.
“Use AI for forecasting” is not a workflow.
“Build a revenue copilot” is not a workflow.
A weekly pipeline inspection is a workflow. It has a trigger, a cadence, a set of inputs, an operating standard, a decision queue, and a management consequence. A renewal-risk review is a workflow. So is turning customer conversations into product feedback, preparing a quarterly business review, routing an inbound account, or inspecting whether a deal has the evidence required to remain in commit.
At RevSystems we offer a lot of value: AI advisory, AI coaching for executives, we lead implementations on system buildouts and I “train the trainer” inside organizations by working with AI and Data leadership. But every engagement starts the same way: a 30-Day AI Operating Leverage Diagnostic.
This is “the front door” because companies do not need another unranked list of AI use cases. They need to decide which workflow should change first, why it matters, and what must be true before they build.
The unit of transformation is not the tool.
It is the operating loop.
I use the same principle inside RevSystems. Product, engineering, delivery, marketing, and sales are distinct workstreams with distinct outputs. I direct them through a central Chief of Staff layer, then route bounded assignments into dedicated work lanes. Each assignment has an owner, evidence, authority, completion conditions, and a required writeback.
The org chart becomes a work graph.
Context Is Part of the Product
Once the workflow is clear, the next question is what the system must know.
AI quality is often discussed as though it lives inside the model. In practice, quality depends on the context around it: definitions, records, relationships, history, policies, permissions, examples, and current operating state.
For a revenue intelligence system, context may include CRM records, stage history, call transcripts, email activity, product usage, support cases, contracts, invoices, renewals, and account plans.
But access alone is not enough.
The system must know which source is authoritative for which fact. It must know that an opportunity is not a contract, a contract is not revenue, and revenue is not cash. It must preserve identity across systems. It must distinguish a missing field from a negative signal. It must recognize when two sources disagree instead of silently choosing the most convenient answer.
More context is not automatically better context. Often, it’s worse.
A larger pile of conflicting information can produce a more articulate mistake.
This is why I separate facts, rules, and judgment. Facts describe the recorded state. Rules compare that state with an agreed standard. Judgment interprets what the gap means and what should happen next. Each has a different proof burden.
Facts need sources. Rules need definitions. Judgment needs confidence, alternatives, and accountable human ownership.
RevSystems uses the same architecture internally. The work lives in a private Git repository, not only inside chat history. Strategy, product contracts, operating procedures, tests, decision records, and dated work logs become shared institutional memory.
An agent entering the system does not need to reconstruct the company from fragments of prior conversation.
The repository is the memory of the firm itself.
Choose the Runtime After the Truth
Only after the work and context are clear do I choose the runtime and tools.
Where will the work happen?
Which systems must be read?
Which tools do we need?
Does the user need a conversation, an exception queue, a scheduled report, or an approved system update?
Different work requires different surfaces.
An executive may use ChatGPT to inspect a decision brief. A scheduled API workflow may detect pipeline changes overnight. Codex may build and test the data pipelines, integrations, evaluations, and operating artifacts behind the system. Controlled tools may retrieve account data or prepare an update for approval. A dashboard may show portfolio state while an agent investigates the exceptions underneath it.
The runtime is the arrangement of models, memory, tools, permissions, workflow state, interfaces, and people that allows the work to complete.
This distinction keeps RevSystems from selling vague promises of “AI transformation.” The destination may be an AI-native enterprise, but the first implementation is a single governed operating motion around one consequential workflow.
For the front office, that system is often Revenue Intelligence. A strong first loop can combine CRM state, customer evidence, historical movement, and financial controls to produce a weekly pipeline and forecast review. The system prepares the truth, ranks the exceptions, and routes the decisions. Management applies judgment and owns the consequence.
From there, the system can expand into account planning, deal execution, customer value, retention, and growth. But it earns that expansion through proof.
One loop becomes the engine.
Control Is Not a Compliance Layer
The fourth layer is governance and observability.
This is where many teams add a policy document to the end of a project and declare the system governed. I take a different view.
Control is part of the product.
Before a system runs, we should know what it may observe, recommend, prepare, and change. We should know which actions require approval, which exceptions force a stop, how decisions are logged, and how the company will detect declining quality or rising cost.
The first version of a revenue workflow should usually be read-only. It inspects approved sources, identifies gaps, and prepares a recommendation. It does not change the CRM, alter the forecast, contact a seller, or message a customer.
Authority expands in steps. Observation becomes recommendation. Recommendation becomes preparation. Preparation may become a reversible action. Only a narrow, proven action should become autonomous, and only inside a clear operating envelope.
This is not caution for its own sake, this is how trust compounds.
Observability helps us close the loop. We test whether the expected data loaded, whether totals reconcile, whether rules classify known cases correctly, whether experienced operators agree with the reasoning, and whether the workflow improves the business result.
We also measure the economics. Did the system reduce labor and latency, improve decisions, and become cheaper to run? Did human attention move from record repair toward commercial judgment?
At RevSystems, I apply these controls to the company itself. Agent work is written back to durable records. Technical acceptance is separated from human operating proof. Builds are tested. Artifacts are inspected.
Authority to prepare work is separated from authority to send it.
That distinction is essential.
The Four Layers in Practice
Consider the Revenue Intelligence System I am have developed as RevSystems’ flagship front-office pattern.
The user and workflow layer begins with leaders and operators who need to inspect pipeline, forecast risk, account movement, customer health, and next actions. We do not begin by promising an omniscient revenue agent. We choose one recurring decision where better evidence can create measurable value.
The context and data layer connects the commercial reality required for that decision. That may include CRM, customer conversations, product adoption, support, contracts, billing, and market signals. The data is mapped to common entities, identities, events, and metrics so the system can reason across the customer relationship instead of reading isolated records.
The runtime and tools layer places the work where it can be used. Executives may receive a decision brief. Revenue Operations may inspect an exception queue. Models may classify unstructured evidence. Deterministic code may reconcile financial totals. Controlled integrations may prepare actions in the operating systems.
The governance and observability layer defines the limits. Sources are cited. Confidence is visible. Uncertainty is not hidden. High-consequence actions require approval. Evaluations test quality. Logs preserve what happened. Business metrics determine whether the system deserves more authority.
Each layer constrains the next.
The workflow determines the context. The context shapes the runtime. The runtime defines the risks that governance must control. Observability produces the evidence that improves the workflow.
That is why the framework is more useful than a technology stack. It describes a living operating system, not a pile of software.
I Use the Framework Twice
The most important lesson is that I do not use these four layers only in client delivery.
I use them to run RevSystems itself. This helps me get more “contact” with the surface area of the system and build useful improvements faster.
The internal users are me and the specialist agents working across product, engineering, delivery, marketing, and sales. The workflows are the recurring decisions and outputs required to build the firm. The context is the shared repository, source evidence, product definitions, plans, and work logs. The runtime is the Chief of Staff hub, dedicated work lanes, Codex, connected tools, branches, and test environments. The governance layer is the set of decision rights, approval gates, tests, holds, audit trails, and writeback requirements that keep parallel work coherent.
RevSystems is being built through the same operating principles it delivers. Work is bounded before it is assigned. Context is made durable before scale is added. Tools are chosen for the workflow. Authority is earned through evidence.
The firm is a proving ground for the product.
This creates a useful symmetry.
Revenue Operations Becomes System Architecture
The old RevOps mandate was built around applications. Administer the CRM. Connect the stack. Build the dashboard. Fix the fields. Prepare the forecast.
Those jobs matter still, but they sit inside a larger responsibility.
Someone must define how the company sees commercial reality. Someone must decide which evidence counts, how work moves, where agents may act, when humans must intervene, and how the system learns from the result.
That is Revenue Operations.
The best RevOps leaders will not be the people who deploy the most AI tools. They will be the people who can turn an important business problem into a trustworthy operating loop. They will move cleanly from workflow to context, from context to runtime, and from runtime to control.
They will know that intelligence without context is unreliable, action without authority is dangerous, and automation without observability is just hidden operational debt.
Four layers create the discipline:
Start with the work
Build the context
Choose the runtime
Install the control
Then run the loop, learn from reality, and expand from proof.
That is how I execute at RevSystems.
It is also how I believe the next generation of revenue systems will be built.
👋 Thank you for reading Mastering Revenue Operations.
To help continue our growth, please Like, Comment and Share this post.
I started this in November 2023 because revenue technology and revenue operations methodologies started evolving so rapidly I needed a focal point to coalesce ideas, outline revenue system blueprints, discuss go-to-market strategy amplified by operational alignment and logistical support, and all topics related to revenue operations.
Mastering Revenue Operations is a central hub for the intersection of strategy, technology and revenue operations. Our audience includes Fortune 500 Executives, RevOps Leaders, Venture Capitalists and Entrepreneurs.
