The Next Evolution of RevOps: From Revenue Process to Buyer Decision Architecture

We built Revenue Operations to optimize how we sell. 

The next evolution is optimizing how buyers decide.

Picture this. An account starts researching a topic. Several people visit your website. Someone downloads a report. Intent increases. A known contact comes back three days later. The revenue machine springs into action. The account gets scored. Marketing changes the nurture. Sales gets an alert. A BDR gets a task. Someone probably gets added to a dashboard. We’ve become experts at detecting activity and turning it into, well, more activity. 

Amidst this, there’s a question we don’t ask nearly enough: What is the buying group actually trying to decide?

For years, we’ve designed Revenue Operations around how companies sell. We’ve built lifecycle stages, scoring models, routing rules, opportunity stages, attribution models and increasingly sophisticated technology to move prospects through our revenue process.

Meanwhile, buyers have been busy creating their own processes. They research independently, bring colleagues into the conversation, and consume information RevOps can and cannot see. They talk to peers, revisit assumptions, and increasingly, use AI to research problems and evaluate options. They decide when, or whether, they want to talk to us.

The signals are there. The opportunity is for RevOps to improve our understanding of what they mean.


The Buyer Journey and the Revenue Process Aren’t the Same Thing

This distinction between the Buyer Journey and the Revenue Process matters.

The revenue process is ours. We define the stages and establish the qualification criteria. We determine when an opportunity gets created, which activities trigger alerts, and how the pipeline is measured.

The buyer journey belongs to the buyer. They’re trying to understand a problem, determine whether it’s important enough to solve, evaluate possible approaches, build internal consensus, assess risk, and justify an investment to eventually make a decision. Those activities don’t necessarily happen in the order we’ve conveniently configured in Salesforce, and they’re rarely happening with one person.

Forrester has been making this point for years. In “Saying Goodbye To MQLs: How Does The Buyer’s Journey Change In A Buying Groups World?”, Terry Flaherty makes an important distinction between the buyer’s journey and the seller’s revenue process. The two need to work together, but they aren’t the same thing. This is particularly important to keep in mind as we move from thinking about individual leads to buying groups as a whole.

Think about what this means operationally:

  • One person downloading a whitepaper isn’t the buyer.
  • One person visiting a pricing page isn’t the buyer.
  • One person reaching a scoring threshold isn’t the buyer.

We’re observing fragments of a much larger decision process, yet our systems often try to immediately determine the next action from those fragments. Shouldn’t we first determine what those fragments mean in the first place?


Signals Aren’t Instructions. They’re Context.

Today, we have more visibility into buyer behavior than ever before. We can see an almost overwhelming amount of activity, including first-party engagement, third-party intent, website activity, content consumption, product usage, event engagement, seller conversations, customer interactions, buying-group activity, the list could go on.

Individually, these metrics communicate data points, but together; they start to tell us a story.

I’ve seen a common pattern: we invest in better signals, then use them to trigger the same actions we’ve always taken. Intent spike? Alert Sales. Pricing-page visit? Prioritize the account. Content engagement? Increase the score. Multiple engaged contacts? Initiate outreach.

Those responses aren’t inherently wrong, but the signal itself doesn’t tell us what to do. It gives us context to help decide what to do.

Consider an account where four people suddenly begin researching the same topic. It’s interesting, but what’s actually happening? Are they defining the problem? Building a business case? Comparing potential solutions? Trying to understand implementation risk? Adding a stakeholder who needs to get comfortable with the decision? Preparing for procurement? These scenarios could generate incredibly similar engagement signals, but they shouldn’t necessarily generate the same response.

This is where the difference in operating models becomes clear.

The Traditional Revenue Response detects a signal and immediately starts moving it through the revenue process:

  • Detect: We see activity from an account or contact.
  • Prioritize: We score the signal and move the account up the list.
  • Trigger: A workflow, alert or task gets created.
  • Assign: Sales gets the account or automation initiates outreach.
  • Measure: We report on activity: opens, clicks, tasks, meetings and pipeline.

The problem isn’t necessarily the process, it’s that we’re often moving from signal to action without substantial understanding in between.

In the Buyer Decision Approach, the same signal becomes a starting point rather than an instruction:

  • Detect: We see the same activity from the account or buying group.
  • Add context: We look across people, behaviors, and other signals to understand what may be happening.
  • Identify the decision: We form a hypothesis about what the buying group is trying to figure out.
  • Determine the response: We decide who or what could actually help make progress.
  • Measure progress: We look at whether the response reduced uncertainty, addressed friction, or helped propel the buying group closer to a decision.

The difference isn’t more data, it’s what we do with it.

The same signal could trigger two completely different responses. There’s a significant difference between simply seeing a contact visit three pages versus four people from the same account (who represent different functions) engaging with content related to implementation, integrations and ROI over the past two weeks. The second example tells us much more. Not because we captured more activity, but because we gained more context.

Perhaps the buying group is moving from evaluating whether to solve the problem toward determining whether a particular approach is viable. That context changes the response. Marketing might provide implementation proof points. Sales might engage a technical stakeholder. An executive sponsor might need a stronger business case. A digital experience might help answer the next question, or the account might not need direct intervention at all.

The point isn’t that RevOps should know the answer with absolute certainty, because we won’t. Buyer signals are imperfect, and more activity doesn’t always mean more progress. The goal is to build an operating model capable of making a better decision with the information we have.


AI Can Help, But It Doesn’t Change the Question.

AI is changing some of this. Buyers increasingly use generative AI to research solutions, compare approaches, and make sense of large amounts of information before engaging vendors. For revenue organizations, AI gives us the ability to analyze combinations of signals at a scale that would be difficult to manage manually. That’s certainly useful, but we should be careful about what we automate.

If our operating model says every meaningful intent signal should generate seller activity, adding AI doesn’t make that model smarter, it just executes it faster.

Intent signal → BDR task

can very easily become:

Intent signal → AI agent → automated outreach

Congratulations. We’ve removed the human without fixing the thinking. 

Automating the wrong response doesn’t make your revenue engine smarter, it just makes it wrong faster.

AI can help identify patterns, connect signals and surface context, but it doesn’t change the fundamental question: What will actually help this buying group make progress?


What If RevOps Designed Around Decisions?

This is where I think RevOps has a much bigger role to play.

For years, we’ve built revenue architecture around stages. What if we also designed it around decisions?

A buying group needs to answer a series of questions, aka determine buyer decisions, before making a significant purchase:

  • Is this problem important enough to solve?
  • What happens if we don’t solve it?
  • What approaches are available?
  • Which approach fits our organization?
  • Who needs to be involved?
  • Can we implement it?
  • Can we justify the investment?
  • What could go wrong?
  • Which provider do we trust to help us succeed?

Every one of these buyer decisions creates opportunities for Marketing, Sales, Customer Success, digital experiences, content, and technology to help the buying group progress.

This doesn’t mean abandoning lifecycle stages, opportunity stages or qualification frameworks. We still need an internal revenue process, but the internal process should be informed by the external decision process, not mistaken for it.


Buyer Decision Architecture

This is what I call Buyer Decision Architecture, an operating model for connecting what buyers are telling us with how the revenue organization responds.

Not another platform, not another funnel, and certainly not another three-letter acronym to add to the RevOps vocabulary.

Here’s a breakdown of Buyer Decision Architecture at a high level:

Signals – What are buyers telling us? How can we capture meaningful signals across people, accounts, opportunities and channels?

Context – What does it mean altogether? We need to look beyond the individual activity to understand the buying group, the potential opportunity, and where the group may be in its decision process.

Decision – What would actually help? Determine the appropriate next step based on what will help the buying group make progress, including whether or not direct intervention is needed at this time.

Response – Who or what should respond? Coordinate the appropriate people, technology, content, and experiences around what will help the buying group progress.

Measurement – Did the buying group progress? Look beyond activity and attribution. Did the response help the buying group answer a question, involve the right stakeholders, reduce uncertainty, overcome friction, or move closer to a decision? Connect that progression to opportunity movement and revenue outcomes.


This Changes the Role of RevOps

This is where the opportunity for Revenue Operations expands. RevOps can’t simply be the team that manages the machinery behind the revenue process. Lifecycle stages, routing matters, CRM architecture, attribution, and automation all matter, but they’re mechanisms. The strategic value of RevOps comes from connecting these mechanisms to how buyers make decisions and, most importantly, how the business should respond.

This means asking different questions. 

Not just “How quickly did Sales follow up?”

But: “Did Sales engage when human expertise could actually help the buying group?”

Not just: “Which campaign generated the lead?”

But: “What information helped the buying group progress?”

Not just: “How many accounts are showing intent?”

But: “What are those signals telling us about the decisions those accounts may be trying to make?”

Not just: “Can we automate this?”

But: “Should we?”

These questions move RevOps upstream. They transform RevOps from the function responsible for moving data and activity through the revenue engine into a function that helps the organization understand how the engine should operate in the first place.


Better Signals Should Lead to Better Decisions

We’ve spent the last decade dramatically increasing the amount of buyer data available to revenue teams. The next decade shouldn’t be about collecting more of it, it should be about becoming better at interpreting what we already have. 

The competitive advantage isn’t knowing that someone clicked, searched, visited or engaged – (Most of your competitors can know that, too) – The advantage comes from understanding what those behaviors mean in context and designing an organization capable of responding appropriately. Sometimes that’s Marketing, Sales, technology, or a human conversation. In some cases, the smartest thing your revenue engine can do is wait. This is an operating-model problem, not a technology problem.

The future of RevOps isn’t about capturing more signals or automating more activity. It’s about building an organization capable of understanding what buyers are telling us and making better decisions about what to do next. For years, we’ve optimized how companies sell. The next competitive advantage may be how well we help buyers decide.

Scroll to Top