I built one of the first RevOps teams in the industry, back when the title was still new enough that people asked what it meant. I ran Revenue Operations at Freshworks, and the pitch we made for the function was a good one. This was going to be the role that tied go-to-market together, sitting next to the CRO, designing how revenue actually moves through a company.
At the time, I thought the trajectory was obvious. RevOps would spend less time pulling reports and administering systems as the stack matured and automation evolved, and more time designing how the revenue organization worked.
That’s not what happened.
The team meant to design the revenue system spent most of its hours holding it together instead.
I lived some version of this myself.
A number needed after 6 pm went to RevOps. Two teams arguing over a definition went to RevOps. A broken routing rule, a forecast that needed assembling overnight, a comp dispute nobody wanted to own, all of it landed on the same desk.
We stopped designing the system somewhere along the way, and started being it instead.
The promise RevOps never got to keep
A day in the life of RevOps
We recently partnered with Emporia Research to survey 195 revenue leaders at SaaS and AI-native companies on how this shows up in practice.
3 out of 4 RevOps leaders spend two full working days firefighting and keeping the revenue system running.
That’s time taken from designing how the system should run, while the CRO still expects RevOps to be the strategic partner it was hired to be. Then came AI.
Every org already has AI.
Every single leader in the 195-person survey we ran this year said AI already runs somewhere in their revenue motion. The average company runs 4.3 use cases.
Adoption is done.
The gap shows up after the AI does its job.
What this looks like on a Tuesday
The system caught the risk almost six days before anyone acted on it. Nobody heard about the risk from the tool that caught it. They heard about it from a colleague, in a meeting, the following Monday.
57% of leaders in our research still first learn a deal is at risk from a pipeline review or a conversation with a rep, rather than from a system built to detect it.
Deployed and landed turn out to be two different things, and most revenue orgs are only measuring the first one.
You are the system
The revenue system at most companies isn’t software. It’s RevOps.
RevOps sits in the middle of Marketing, Sales, Finance and CS, connecting systems, data and workflows across all of them.
At some point, the team that was supposed to design the revenue system became the team holding it together.
It shows up in the data. RevOps runs 5.4 AI use cases on average. The sales team it serves can see 3.3 of them. And the people closest to that stack trust it the least. RevOps rates its own risk detection 3.3 out of 5. Sales rates the same system 3.7 out of 5.
A team that stays in the human layer gets smaller and quieter. It lives on the work AI can’t do yet, which shrinks every quarter, and the strategic seat goes to whoever claimed it while the manual work was still a full-time job.
The next version of the job
Someone still needs to understand the systems, data, incentives, change management and workflows that make a revenue organization run.
Comp analysts, GTM engineers, deal desks, and RevOps analysts each build a piece of the revenue system. Revenue Architects often lead those teams, and sometimes do the work themselves. Their job is deciding how the pieces fit, watching where the design fails, and changing it while there’s still time to affect the outcome.
At Northstar, I gave that person a name: Revenue Architect.
Why give this a name?
A name lets you assign the responsibility and measure it. Today, plenty of teams own whether a system gets deployed. Far fewer own whether it actually changes what people do.
From operating the system to architecting it
Your new scoreboard: did it land?
If a Revenue Architect is designing for landing, not just deployment, they need a different scoreboard. Landing doesn’t mean owning every action that follows. It means designing the system so the right signal reaches the right person and prompts the intended behavior. Most teams ask one question about everything they ship: is it live? I’d ask four.
A risk alert that fires but nobody sees is deployed. One a rep sees but ignores is visible. One that changes what the rep does next is acted on. One that changes the outcome has landed. A Revenue Architect owns the distance between the first box and the last, not just whether the first box got checked.
If you’re the CRO
Your RevOps team knows more about how revenue actually moves through your company than anyone else in it. Right now, most of that knowledge goes into pulling numbers and filling gaps.
In our survey, three in four revenue leaders estimated the gap between knowing something needs to happen and it happening costs them at least 5% of revenue. One in six put it above 15%. At a $100M company, that’s $5M to $15M a year.
Closing that gap takes someone who owns what happens after a signal fires.
- Stop routing every gap to RevOps. The forecast call nobody else wants to own and the coaching that belongs with a sales manager both land there by default.
- Measure what landed. In your next QBR, ask which of last quarter’s launches changed what reps actually did.
What changes if you are doing the job
The calendar is the visible part. The title only holds if the job around it changes too, so here is what I’d expect to move.
Your reporting line changes first. Running the system, you report into a Head of Sales or into Finance. Designing it, you report to the CRO or CEO, or you become your own CxO role (COO, CSO) and a peer of the function leaders instead of a service to one of them.
Your seat changes with it. You go from the room where the number gets reported to the room where the number gets set.
Pay moves in two ways. The band shifts from an ops band to a GTM leadership band, because you’re paid for judgment rather than throughput. The bigger change is the variable, which moves from project delivery and ticket SLAs to revenue outcomes you influence: forecast accuracy, pipeline coverage, and net retention. When your variable is tied to the number, you stop being asked to pull it and start being asked whether it’s achievable.
The job we were promised
When RevOps first took shape, the promise wasn’t that we’d create a generation of great system administrators. It was that someone would finally sit across the whole revenue organization and design how all of it works together.
We got closer to that than I sometimes give us credit for. RevOps became indispensable. It accumulated the systems, the data, and the cross-functional context that job actually requires.
But being indispensable had a price. The more embedded we became running the revenue system day to day, the less time was left to design it.
AI gives us another shot at that original promise. It can take the manual layer off the people who understand the revenue system best.
Questions worth asking
Is "Revenue Architect" a real job title I can put on LinkedIn?
Yes. As long as the work matches the criteria above: you're accountable for whether a deployed system changes seller behavior in time to matter, measured on landing, not deployment. If that's the job you're already doing, whatever your current title says, call yourself a Revenue Architect.
Isn't this just a GTM engineer?
No. A GTM engineer builds the machinery: the workflows and triggers that connect your CRM to your LLMs. A Revenue Architect decides what that machinery should do across the whole revenue org, including the incentive that makes a rep act on it. Then they're on the hook for whether it did. Plenty of Revenue Architects will have GTM engineers on their team.
How is this different from RevOps?
RevOps as a title covers a wide range of work, much of it operational: system administration, reporting, data hygiene. It also tends to become the default answer whenever another GTM leader has a gap, running the forecast call nobody else wants to own, or picking up coaching that should sit with a sales manager. A Revenue Architect does revenue design instead, and is accountable for whether it actually changes what a seller does.
Isn't this just the CRM owner or the forecast lead with a new title?
No. Keeping the CRM accurate is a systems job: data hygiene, clean records. Revenue design is different: the workflow that turns a signal into an action, the incentive that makes it worth taking, the feedback loop that shows whether it worked. A Revenue Architect is accountable for one specific thing: whether what they designed actually changed what a seller did. It's an inside job, on the hook for outcomes, not a framework a consultant hands over and leaves.
What does "landing" mean, versus "deployed"?
Deployed means a capability is technically live: the alert fires, the automation runs. Landed means it actually changed what a seller did, in time for that change to matter to the outcome. Most teams only measure the first one.
Where does the data in this piece come from?
A survey of 195 senior revenue leaders across North American SaaS and AI-native companies, fielded in 2026, published in full as the Revenue Execution report.
