There is a sentence that comes up again and again in CRM and RevOps work: “the CRM is not working.”
Sometimes that is exactly the problem. The configuration is poor, adoption is weak, or the platform is simply a bad fit. But often the CRM is exposing something that started earlier: unclear sales stages, teams using different qualification rules, data with no clear owner, or hand-offs nobody designed end to end.
That is why we use the idea of a Revenue System: to look at the whole operating chain, not only the tool where the symptom became visible.
RevOpsHubs Thesis
A Revenue System is how a company turns strategy into revenue through interdependent decisions, processes, technology and data. Improving one component can help. It does not guarantee that the system improves.
The Revenue System starts before the CRM
Picture a mid-market B2B company running Salesforce, HubSpot or Microsoft Dynamics. Marketing is active. Sales is experienced. Customer teams are in place. Dashboards and automations exist. Yet leadership does not trust the pipeline, context disappears between teams, and sellers keep private spreadsheets on the side.
The obvious response is to attack each symptom: rebuild the pipeline, add fields, run more training, create another workflow, buy another integration.
The difficulty is that these choices are connected.
If Marketing and Sales disagree on what qualifies as an opportunity, the CRM will encode that disagreement. If the CRM does not represent the process well, the data becomes inconsistent. If the data is unreliable, automation makes bad decisions faster. When AI is added to that environment, it inherits the same ambiguity.
The CRM is one layer of the system. It is not the system.
The 6 layers of the Revenue System Model
The RevOpsHubs Revenue System Model separates the operation into six layers. Revenue is the outcome, not a seventh layer.
1. Strategy
Who are we trying to serve? Where do we want to grow? What is the ICP? How do we go to market? What counts as meaningful progression through the customer lifecycle?
When those choices remain fuzzy, the rest of the system tries to compensate with operational rules for decisions the business never actually made.
2. Process
Strategy becomes work: qualification, ownership, hand-offs, stage criteria, proposals, close, onboarding and expansion.
A useful process is not a perfect diagram. It is clear enough to answer four questions: what happens now, who decides, what evidence is required, and what happens next?
3. CRM
The CRM gives the process an operational form. Objects, properties, lifecycle stages, pipelines, permissions and integrations should represent how the company has chosen to work.
A common mistake starts here: configuring a decision the organisation has not yet made.
4. Data
Data makes the system observable. The organisation needs enough reliable context to understand who the account is, what state it is in, what happened, who owns it, which signals matter and what the outcome was.
The goal is not to collect everything. It is to capture the information needed to decide, measure and transfer context without forcing someone to rebuild the story manually.
5. Automation
Once the process is stable enough, automation can remove waiting and repetitive work: routing, notifications, enrichment, synchronisation, task creation and data updates.
Automation is powerful because it speeds things up. That is also why clarity matters first: it can speed up the wrong process just as effectively.
6. AI
AI adds interpretation and adaptive action. It can prepare context, recommend the next move, research an account or execute bounded work.
But it does not start from a blank page. Agents need business context, access to the right tools, permissions and controls. Emerging enterprise agent architectures — including OpenAI Frontier — put explicit weight on business context, systems of record, permissions and auditable actions.
For a deeper treatment of that question, see AI readiness starts before the AI layer →
The point is not the six boxes. It is the dependency between them.
The model is not meant to turn RevOps into a six-part checklist. It is meant to help teams ask a more useful question: where did this problem actually begin?
Take a simple example:
- Leadership says the forecast cannot be trusted.
- The report itself is technically correct.
- Opportunities, however, move stages without consistent evidence.
- Different sellers use “proposal” to mean different things.
- The CRM faithfully records those different interpretations.
The symptom shows up in data and reporting. The cause may sit in process.
If the first reaction is to buy a forecasting tool or build another dashboard, the business may simply create a better view of the same underlying problem.
A recurring pattern in B2B implementations is that a project starts with a configuration request — “we need to change the pipeline”, “we need more fields”, “the CRM cannot report this” — and diagnosis shows that the team has not yet agreed on the operational rule the configuration is supposed to represent.
One question is particularly useful:
Is the problem in the layer where we can see it, or is that layer exposing an earlier problem?
This is not a maturity ladder
Strategy → Process → CRM → Data → Automation → AI looks sequential. It does not mean a company must “finish” strategy before touching the CRM, or complete automation before testing AI.
Real organisations improve several layers at once. The sequence is there to make one dependency visible: downstream layers inherit the constraints of the layers before them.
You can experiment with AI early. You can automate early. What matters is not confusing access to technology with operational readiness.
RevOpsHubs Thesis
AI readiness is, to a large extent, an outcome of Revenue System quality. The more work an organisation delegates to agents, the more explicit its context, decision criteria, ownership and action boundaries need to become.
How to use the model on a real decision
Do not start with a programme called “transform RevOps”. Start with one revenue outcome that is not working and trace it backwards.
Say the goal is to improve the conversion of qualified opportunities into valid proposals.
Ask five questions:
- Which decision needs to improve? Are we qualifying the right opportunities?
- Which process governs that decision? Are entry and exit criteria explicit?
- How is it represented in the CRM? Do stages and properties match the real process?
- Which data tells us whether it works? Can we distinguish buyer progress from seller activity?
- What should be automated or delegated to AI? Where is human judgement still required?
The aim is to find the smallest intervention that addresses the cause instead of adding another layer of technology on top of the symptom.
The systems principle is broader than RevOpsHubs
Winning by Design reaches a related principle through Revenue Architecture, treating recurring-revenue growth as a set of interconnected models that need shared logic, language and data.
The RevOpsHubs Revenue System Model has its own structure and purpose. It is not a reproduction of that model. The overlap is the systems principle: optimising individual components does not guarantee a better overall system.
The model in this article is a RevOpsHubs framework. External sources are used to frame related systems thinking and, in the case of AI, verifiable technical and operating requirements.