AI assistants are getting noticeably better. Products like Grok Bot, Muse, Dots, and others can now manage pieces of your inbox, calendar, research, reminders, and daily work in ways that are starting to feel genuinely useful.

What is less obvious is where that same level of progress is happening inside the business.

There are plenty of enterprise AI pilots, copilots, and agents, but relatively few examples where an agent is materially changing a core business metric like revenue cycle time, margin, order accuracy, service cost, or operating capacity.

That gap is interesting because the technology itself is moving quickly. The harder problem may be that businesses are not structured in a way that agents can reliably operate.

Personal assistants have an easier job

A personal assistant works for one person. It can learn preferences, watch a calendar, read email, search files, and help complete tasks with relatively limited consequences when something is ambiguous.

Enterprise agents have a different challenge. They need to understand how the business works across multiple systems, teams, and rules.

Take quote-to-order. An agent might need to know which configurations are valid, where pricing comes from, when engineering approval is required, whether a customer has special terms, whether inventory can support the requested date, when credit needs to be checked, and what conditions must be met before an order can move into ERP.

Most companies do not have all of that logic clearly documented in one place. It is distributed across systems, spreadsheets, approval chains, custom code, and institutional knowledge.

Experienced employees know how to navigate that ambiguity. Agents do not unless the business makes those rules explicit.

That may be why enterprise agents still feel incremental

A lot of what we are seeing today improves individual tasks. AI can summarize a call, draft an email, suggest next steps, create content, or answer questions faster.

Those are useful improvements, but they do not necessarily change the underlying workflow.

If a salesperson creates a quote in 20 minutes instead of two hours, but the quote still waits two days for engineering, another day for pricing approval, and then requires manual re-entry into ERP, the business outcome has not changed very much.

That is the distinction that matters.

Enterprise AI should not ultimately be measured by how much time it saves an individual. It should be measured by whether it removes friction from the process itself.

The better model may be specialized agents

I do not think the near-term future is one general-purpose AI employee running an entire process from beginning to end.

A more realistic model is a set of specialized agents with clearly defined responsibilities.

A configuration agent could validate product requirements. A pricing agent could apply contract pricing and discount rules. An approval agent could determine whether escalation is required. An order-readiness agent could confirm that all commercial, operational, and financial conditions are satisfied before the order moves downstream.

That approach is more practical because it limits scope, makes decisions easier to govern, and creates clearer accountability.

It also gives companies a better way to measure value. Instead of asking whether the agent is useful, you can ask whether it reduced approval time, lowered rework, improved order accuracy, reduced manual touches, or shortened quote-to-order cycle time.

The real constraint may be business design

The AI is getting better quickly. The harder part is creating an environment where it can be trusted to act.

That requires clear system ownership, well-defined business rules, clean data, accessible actions, permissions, and a consistent way to handle exceptions.

Most organizations are still working through those basics.

That is why the current generation of personal assistants can feel more impressive than enterprise agents. The personal assistant only needs to understand you well enough to help. The enterprise agent needs to understand the business well enough to make decisions that matter.

That is a much higher bar.

The companies that get the most value from agents will not necessarily be the ones with the most advanced AI. They will be the ones that have made their processes understandable enough for AI to operate.

Ask the people closest to the work where the waste is. They won’t need time to think.

The approval that always comes back yes. The meeting that could be a two-line update. The handoff that adds three days and catches nothing. The process everyone follows because “that’s how we do it.”

They see it every day. So why is it still there?

Seeing It Isn’t the Problem

Waste doesn’t survive because nobody notices it. It survives because nobody feels allowed to remove it.

Adding something takes one request. Removing it takes courage. Nobody knows who has the authority to kill a process, and the risk is lopsided: remove something that matters and it’s on you. Leave it alone and nobody ever blames you.

Most people tried once. They raised it, and nothing happened. That’s all it takes.

The day someone stops pointing out the waste isn’t the day they stopped seeing it. It’s the day they stopped believing it would matter.

The Real Cost

Your sharpest people spend their energy navigating the system instead of improving it. The friction builds into a tiredness that never shows up on a report. Eventually the best ones stop caring or leave.

That’s how a business gets slow. Not through one bad decision, but through people who could see a better way and didn’t feel allowed to take it.

And speed is the strategy now. Markets shift monthly. The companies that win will be the ones whose people can act on what they see without waiting for a committee.

Why This Is Your AI Strategy

Every company wants agents running its processes. Most are about to automate the waste.

An agent can’t tell which approval is theater or which step exists because of a mistake from five years ago. It follows everything you give it, faithfully and at scale. Hand it a bloated process and you get bloat that moves faster. Your process isn’t ready for agents!

The people who know what to cut are the same people who see the waste every day. They’re the ones who can tell an agent what actually matters, what to skip, and where human judgment still belongs. The companies that get real value from AI won’t be the ones with the best tools. They’ll be the ones whose people were already empowered to strip a process down to what matters before handing it off.

That’s the future of work worth building: agents take the repetitive steps, and people own the judgment, including the judgment about what shouldn’t exist at all. But it only works if your people believe they’re allowed to make that call.

Permission isn’t a culture initiative running alongside your AI plans. It is the AI plan.

Permission Is Something You Prove

Say it out loud: “You have the authority to change it.”

Then the real test comes the first time someone uses it. If they cut something that turns out to matter, put it back, thank them, and move on. Do that once and people will believe you. Punish it once and you’ll never hear another idea.

Anything that doesn’t serve a customer, protect the business, or manage a real risk is fair game. Pause it before you kill it. And celebrate removals as loudly as you’d celebrate a launch.

Put Them Down

Most leadership teams ask “what should we add?”

The better question is “what are our people carrying that they don’t need to?” And do they believe they’re allowed to put it down?

This week, ask your team for three things they’d stop doing tomorrow if it were their call. Then tell them it is.

Reply and tell me what you hear.

Need help getting AI ready? Let’s Talk!

This year, at least five projects we’ve scoped have stalled in the same place.

Not lost. Stalled. Each one started the same way: a business process held together by a few key people and a handful of spreadsheets, systems that were implemented but never finished, and leadership that knows AI is about to raise the bar before they’re ready. Everyone agreed on the problem. Everyone wanted it fixed.

Then the meetings started. New stakeholders joined. Requirements got revised. Another round of demos. A proposal, then a revised proposal.

Lots of motion. No movement.

We call that the rocking horse, and right now it’s the most common state a transformation project can be in.

Everyone in the Room Has Been Burned Before

Walk into any leadership team today and you’re not talking to a blank slate. You’re talking to people who lived through the last one.

The ERP rollout that was supposed to take a year and took three. The CRM that went live on schedule and then got quietly abandoned by the people it was built for. The “transformation” that transformed mostly the budget. The integration that still breaks every month-end, years later.

That history doesn’t stay in the past. It walks into every new evaluation.

It shows up as more stakeholders, added as insurance. As longer requirements lists, written as protection. As requests for guarantees no honest partner can give. As a sponsor who believes in the project but remembers what happened to the last person who championed one.

And it shows up as fatigue. Teams that spent years absorbing change they didn’t ask for, learning systems that didn’t stick, and cleaning up after go-lives, have very little appetite left for another round. Nobody says “we’re too tired to do this.” They say “let’s revisit next quarter.”

This is scar tissue, and it’s rational. These organizations learned something real from past projects. The problem is what they learned: that the safest move is not to move.

Every Stakeholder Is Solving for a Different Failure

Here’s where the scar tissue turns into a stall.

The business side wants speed, because the last project took forever. Finance wants control, because the last one blew the budget. IT wants fewer platforms, because they’re still supporting the last one. Operations wants less disruption, because they absorbed the last go-live.

Each of those is legitimate. They’re just not the same project. Every person at the table is protecting against a different bad memory.

When nobody has agreed on the one outcome that matters most, every proposal looks wrong to somebody. So nobody says no. They just don’t say yes.

The RFP Is Where Alignment Goes to Hide

The standard fix for misalignment is a formal process. Write an RFP, gather requirements, evaluate vendors objectively.

In practice, it often does the opposite. A 200-line requirements list is usually five departments’ wish lists stapled together. Nobody had to decide what mattered most, because everything made the list. The disagreement didn’t get resolved. It got formatted.

And by the time it’s released, it’s stale. An RFP takes months to write, route, and approve. In that window the AI roadmap shifted, vendors announced new products, a sponsor changed roles, and the budget got reset. Vendors respond to a document that describes last year’s problem.

To be fair to buyers: partners contribute to this too. When we answer a fatigued, misaligned committee with a transformation-sized proposal, we’re asking them to relive exactly the thing they’re afraid of.

Waiting Has a Cost Nobody Tracks

While the project idles, the costs keep running. Work still waits on manual handoffs. Errors still leak through exceptions nobody tracks. Your best people still spend their week patching the process instead of improving it.

Those costs are quiet and spread across the business. The cost of a new project is loud and concentrated. So the quiet cost wins every time.

What Actually Breaks the Stall

In the projects that do move, two things are almost always true.

They agreed on one outcome first. Not a requirements list. One measurable result that every department signed off on before anyone talked about platforms.

They made the bet small enough to trust. Scar tissue doesn’t heal with a better pitch. It heals with evidence. A fixed-scope, time-boxed engagement that shows something working in weeks does more to rebuild confidence than any business case. If it works, the next step is easy to approve. If it doesn’t, you’ve lost a quarter, not a year.

Neither requires knowing which AI platform wins. Documenting how your business actually runs, and cleaning up the logic behind it, pays off on any platform. That’s the foundation AI runs on.

A Test for Your Stalled Project

If there’s a project on your desk that everyone agrees on and nobody has approved, ask each stakeholder, separately, two questions:

1. What’s the one outcome this has to deliver?

2. And what went wrong the last time we tried something like this?

If the answers to the first question match, you’re ready to move. If they don’t, the answers to the second will tell you why.

Reply and tell me what you heard. I’m genuinely curious how common this is.

One of the biggest shifts AI may bring to business processes is not replacing people. It is changing where people spend their time.

For years, many workflows have been built around people reviewing, approving, entering, validating, and moving information. In a lot of cases, that was necessary because the systems could not reliably make decisions on their own.

That is starting to change.

As AI, automation, and modern platforms get better at interpreting information and applying context, there is less reason for a person to touch every transaction. The better model is often to let the normal path move automatically and bring people in only when something falls outside of it.

That is what I mean by exception-based work.

Stop Reviewing Everything

Take a common approval process.

A manager may be required to review every discount over a certain threshold, even though most of those deals are completely normal.

A better approach would evaluate the broader context. Is the discount within historical norms? Is the margin acceptable? Is the deal unusually complex? Does anything look materially different from similar transactions?

If everything looks normal, the process keeps moving. If something does not, the right person gets involved.

That is a much better use of human judgment.

The Same Pattern Shows Up Everywhere

The same concept applies across the business.

In quoting, only unusual configurations may need engineering review. In customer service, routine requests can be resolved automatically while more complex situations go to experienced people. In order management, normal transactions can continue without intervention unless pricing, inventory, credit, or fulfillment data creates an exception.

The value is not just that AI makes tasks faster.

The real value is reducing how often a person needs to participate in the process at all.

That Changes the Role of the Employee

If people are no longer spending as much time processing the normal path, their role shifts.

They spend more time investigating unusual situations, making judgment calls, solving problems, and improving the process itself.

That is a more useful way to think about AI than simply asking how many hours it can save.

The goal should not be to remove people from the process. It should be to put them where their judgment matters most.

Design for the Exception

This is where I think companies should focus.

Look at the work teams are doing today and ask how much of it is truly unusual.

How many quotes really require engineering judgment? How many discounts actually represent financial risk? How many orders genuinely need someone to investigate them?

The answer is often much smaller than the amount of work people are touching today.

That is the opportunity.

AI and automation should increasingly handle the predictable path while people focus on the situations where context, experience, and judgment matter.

Machines handle the normal. People handle the exceptions.

One of the most common mistakes businesses are making with AI is also one of the most predictable: they are taking the processes they already have and asking where AI can be inserted.

That usually leads to useful ideas. AI can summarize information, draft responses, recommend products, prepare approvals, or help employees find what they need faster. Those are all valid use cases, but they can also keep the conversation too narrow.

The better question is whether the process itself still makes sense.

If you were designing that workflow today, with modern cloud platforms, automation, APIs, and AI available from the beginning, would you build it the same way?

In many cases, the answer is no.

Get Started

Most Processes Were Built Around Old Constraints

Business processes rarely come from a clean-sheet design. They evolve over time.

An approval gets added because of a problem that happened years ago. A spreadsheet appears because two systems do not communicate well. Someone becomes responsible for moving data from one department to another. A report gets built because the underlying information is difficult to access. A workaround that was supposed to be temporary becomes part of the process.

Over time, all of that becomes normal.

The process works, but often only because people know the exceptions, the side conversations, the manual checks, and the unofficial steps required to keep it moving.

This is what I think of as process debt.

Most companies are familiar with technical debt: old code, legacy integrations, outdated architecture, or customizations that become harder to support over time. Process debt is similar. It is the accumulation of manual steps, unnecessary approvals, duplicated effort, organizational handoffs, and workarounds that were created to solve constraints that may no longer exist.

AI is starting to expose that debt.

Faster Is Not Always Better

A lot of the current AI conversation is focused on productivity: helping someone complete a task faster.

That is useful, but there is a difference between making a task faster and removing unnecessary work from the process entirely.

Take a complex quote-to-order process. A salesperson may gather customer requirements, enter information into CRM, configure a product, request pricing approval, wait for engineering input, revise the quote, create a proposal, send it to the customer, and eventually hand everything to another team for order processing.

There are plenty of opportunities to insert AI into that workflow. AI could summarize the requirements, recommend products, draft the approval request, generate proposal content, or surface similar historical deals.

But that still assumes the existing workflow is the right workflow.

A more interesting conversation starts when you ask why those handoffs exist in the first place.

Could customer requirements be evaluated automatically against product and configuration rules? Could pricing approval become exception-based instead of requiring approval on every transaction? Could engineering only be involved when a configuration falls outside known parameters? Could order validation happen throughout the quoting process instead of at the end?

Once you start asking those questions, you are no longer trying to automate the process you have.

You are redesigning the process you need.

Start With the Outcome, Not the Workflow

This is where I think many technology initiatives need to change.

Instead of beginning with, “Here is our current process. How can we automate it?” start with the business outcome.

Maybe the goal is to reduce quote turnaround time. Maybe it is to reduce order errors, remove manual approvals, improve customer self-service, or free salespeople from chasing internal information.

Once the outcome is clear, work backward.

What would the ideal process look like? Which steps actually create value? Which decisions truly require a person? Which decisions can be handled by business rules? Which decisions could increasingly be handled by AI? Where are employees acting as the connection point between systems simply because the systems themselves are not connected?

Those are the questions that should shape the technology design.

If the process is never challenged, there is a real risk that companies will spend a lot of money making inefficient workflows move faster.

AI Changes the Assumptions

This does not mean every process should be rebuilt around AI, and it certainly does not mean every decision should be automated.

The point is that some of the assumptions behind existing processes are changing.

Historically, certain activities required people because the technology could not interpret unstructured information well. Integrations were expensive. Automation required highly predictable rules. Systems had limited context. Exceptions were difficult to manage.

Those constraints are becoming less absolute.

That creates an opportunity to revisit decisions that may have been made five, ten, or fifteen years ago and ask whether they are still necessary.

The important part is not putting AI everywhere. It is recognizing that AI gives businesses another reason to challenge how work gets done.

The Real Opportunity Is Process Redesign

There will absolutely be value in using AI to help employees work faster. That is already happening.

But I think the larger opportunity will come from companies that are willing to redesign workflows rather than simply adding AI to them.

If five people participate in an approval process today, the goal should not automatically be to help those five people approve something faster. The better question is whether all five people need to participate at all.

If an employee spends hours moving information between systems, the goal should not automatically be to give that employee an AI assistant. The better question is why the information needs to be moved manually in the first place.

If a customer waits three days because work is sitting in different internal queues, the goal should not simply be to make each queue more efficient. The better question is whether the queues still need to exist.

That is the mindset shift.

Modern technology gives businesses an opportunity to stop designing around yesterday’s constraints.

Use AI where it creates value. Automate where it makes sense. But before doing either, challenge the process itself.

Because the biggest opportunity may not be doing what you already do faster.

It may be deciding that you no longer need to do it that way at all.

For years, companies have approached technology investments the same way:

Define the requirements. Approve the implementation budget. Go live. Then move into maintenance mode.

That model is becoming outdated.

Technology no longer sits still long enough for businesses to think in terms of “implement, maintain, replace.”

Cloud platforms are releasing new capabilities constantly. AI is moving even faster. Business processes are changing. Customer expectations are changing. And capabilities that were too expensive or unrealistic a year ago can suddenly become practical.

The problem is that many companies have changed the technology they are buying without changing the way they budget for it.

Maintenance Is Not Continuous Improvement

Most companies already budget for maintenance.

Maintenance keeps the lights on.

It fixes issues, handles releases, supports users, and keeps integrations working.

Continuous improvement is different.

It asks:

How do we make the business better using the technology we already invested in?

That might mean improving a quoting process after seeing how users actually work. Automating an approval that was left manual during phase one. Introducing an AI agent into an existing workflow. Replacing custom functionality with a new platform capability. Or improving the handoff between CRM, CPQ, ERP, and other systems.

Maintenance preserves the investment.

Continuous improvement compounds it.

That distinction is becoming increasingly important.

AI Makes This Hard to Ignore

AI has accelerated this shift.

A technology decision made today may look very different twelve or eighteen months from now.

That doesn’t mean businesses should chase every new AI feature.

It means they need the ability to continuously evaluate what is now possible.

Something excluded from the original project because it was too expensive, too complex, or simply didn’t exist may become a very real opportunity later.

If there is no budget or operating model for continuous improvement, those opportunities usually get ignored until the next major transformation project.

By then, the business may already be behind.

The Budget Conversation Needs to Change

Instead of asking:

“What will this implementation cost?”

Businesses should increasingly ask:

“What should we expect to invest in this capability over the next three years?”

Those are very different conversations.

The first focuses almost entirely on getting to go-live.

The second recognizes that go-live is only the beginning.

A modern technology investment should really be viewed in three parts:

• Build — Establish the platform, integrations, architecture, and initial capabilities.

• Operate — Support the environment and keep everything working reliably.

• Improve — Continuously optimize processes, introduce new capabilities, and take advantage of meaningful innovation.

For some organizations, there may even be a fourth category:

• Explore — Test emerging capabilities such as AI agents or new automation patterns before making a larger investment.

The percentages will vary.

The important part is that improvement is planned and funded instead of treated as an unexpected expense.

Technology Is Becoming a Capability, Not an Asset

This may be the biggest mindset change.

We used to treat enterprise technology more like infrastructure.

Build it. Maintain it. Replace it eventually.

Modern technology behaves more like a business capability.

• Your CRM is never really finished.

• Your CPQ environment is never really finished.

• Your revenue process is never really finished.

• And your AI strategy definitely isn’t finished.

That doesn’t necessarily mean spending more.

In many cases, it should mean spending more intelligently.

Instead of massive transformation projects every few years, organizations can make smaller, more frequent investments tied to actual business outcomes.

They can see what users need.

Measure what is working.

Stop investing where value isn’t materializing.

And accelerate the areas where it is.

The objective becomes less about completing a project and more about continuously improving the business.

The Upfront Number Still Matters. It Just Isn’t the Whole Number.

Companies should absolutely understand what an implementation will cost.

Scope matters. Budgets matter. Accountability matters.

But the initial implementation cost is only the cost of getting started.

The more important question is what capability the organization is creating and how it plans to keep improving that capability as the business and technology evolve.

The technology you implement today may still be running five years from now.

But what it is capable of doing five years from now should look very different.

If your budget assumes otherwise, the technology probably isn’t the thing that needs to change.

Your investment model is.

There’s a simple question I think every company evaluating AI should ask:

Could an AI agent run your quote-to-order process today?

Not whether you have Salesforce, ServiceNow, a modern ERP, or an AI strategy. Not whether your vendors have released agents that can configure products, generate quotes, submit approvals, or create orders.

Could you actually give an agent responsibility for moving a real customer transaction through your business?

For many companies, the answer would be no.

And the reason probably has very little to do with AI.

Imagine giving the job to someone new

Think about what happens when a new employee joins your organization.

You can give them process documentation, training, system access, and instructions. But eventually someone tells them how things really work.

Use this price unless it’s this type of customer.

Check ERP before promising the delivery date.

That product technically requires engineering approval, but only under certain configurations.

Don’t trust that field in CRM.

If it’s an international order, send it to Finance first.

That customer has special terms. Ask Susan.

These aren’t unusual edge cases. In many businesses, they are the process.

Experienced employees learn how to navigate them. They develop context. They recognize patterns. They know who to call when the system doesn’t provide an answer.

Now replace that experienced employee with an AI agent.

Suddenly all those little gaps matter.

An agent can’t rely on “you just know”

Consider a fairly normal quote-to-order request:

Create a quote for 50 units of this configuration, apply the customer’s contracted pricing, confirm we can deliver by October 15, get whatever approvals are required, and create the order.

That sounds like exactly the kind of workflow an AI agent should eventually handle.

But look at what the agent actually needs to understand.

Which product combinations are valid? Which system owns the configuration logic? Where does contract pricing live? Is current inventory enough to satisfy the order? If not, can production meet the date? Does this discount require approval? Does the customer’s credit status affect the order? At what point can the transaction move from CRM into ERP?

None of those are AI questions.

They’re business architecture questions.

If the answers live across six applications, three spreadsheets, two inboxes, and the heads of a few longtime employees, adding an agent on top doesn’t eliminate the complexity.

It exposes it.

This changes how I think about AI readiness

Most AI-readiness conversations start with technology.

What model should we use? Which agent platform? What should we automate first? How do we connect our data?

Those questions matter, but I think there’s a more useful place to start:

Can your business explain itself?

Take one important process—quote-to-order is a great example—and try to define exactly what an agent would need to know to execute it.

• Where does authoritative customer data live?

• Where does product configuration happen?

• Who owns pricing?

• What makes a quote valid?

• What triggers an approval?

• What makes an order ready?

• Which system has authority at each step?

• What happens when something doesn’t follow the happy path?

If those answers are difficult for your organization to provide, you’ve discovered something valuable before deploying a single agent.

The goal isn’t one giant system

This also challenges an assumption that has shaped enterprise technology for years: that simplification means putting everything into one platform.

I don’t think that’s where this is heading.

CRM may remain the best place for customer and opportunity context. CPQ may own configuration and pricing. ERP may continue to own inventory, production, and financial transactions. Order management may orchestrate fulfillment.

That’s fine.

The important thing is that each system has a clear responsibility and that the rules governing movement between them are understandable.

In that environment, an AI agent can become the engagement layer across the business.

The salesperson doesn’t necessarily need to understand which API retrieved inventory or which system calculated the price. They need to communicate the desired outcome.

The agent figures out how to get there.

But only if we’ve done the hard work underneath.

Try the test

Pick a real transaction your team completed recently.

Then ask:

Could an AI agent have completed this from beginning to end without someone quietly filling in the gaps?

Every time the answer is “no, because someone would need to know…” you’ve probably identified an opportunity.

• A missing business rule.

• An unclear system boundary.

• An undocumented exception.

• A manual approval.

• A piece of tribal knowledge.

• A data problem.

• An integration gap.

Those are the things I’d be working on now.

Because the companies that get the most value from agents won’t necessarily be the ones that buy the most AI.

They’ll be the ones whose businesses are easiest for AI to understand and operate.

Before asking what an AI agent can do for your quote-to-order process, ask whether your quote-to-order process is ready for an AI agent.

Every transformation starts with alignment.

At least it feels that way.

Everyone agrees the current process needs to improve. The system is too manual. Reporting is too hard. Data quality is inconsistent. Teams rely on too many spreadsheets, side conversations, and workarounds. The business needs better visibility, cleaner handoffs, and a more scalable way to operate.

That part is usually easy.

The hard part starts when the team has to define what “better” actually means.

Because every stakeholder tends to see success through a different lens.

• Sales wants the process to be faster.

• Finance wants more control.

• Operations wants cleaner handoffs.

• IT wants security, scalability, and maintainability.

• Leadership wants adoption, ROI, and measurable outcomes.

• Users want the system to make their daily work easier.

None of these priorities are wrong.

But if they are not reconciled, the project eventually becomes a tug-of-war.

Vision-Level Alignment Is Not Enough

Most teams are aligned at the beginning because the conversation is still broad.

Everyone can agree on phrases like:

• improve the customer experience

• streamline quote-to-order

• reduce manual work

• increase visibility

• create a better user experience

• enable automation and AI

Those are good goals, but they are not operating decisions.

The real alignment test comes later.

• Should the quote process add one more required field if it prevents downstream order issues?

• Should sales have flexibility to override pricing rules, or should margin controls be tighter?

• Should the system optimize for fewer clicks or better data quality?

• Should an approval happen earlier to reduce risk, even if it slows the seller down?

• Should the new workflow match how teams work today, or force the business toward a better future state?

That is where alignment gets real.

Stakeholders Are Usually Optimizing for Different Things

This is especially true in revenue transformation.

Sales often measures success by speed and ease of use. If the system slows down quoting or adds administrative work, they feel the pain immediately.

Finance measures success by control, accuracy, and margin protection. They care about pricing discipline, approval logic, and whether the business can trust the numbers.

Operations measures success by clean execution. They want complete information, fewer order issues, and less rework after the deal is won.

IT measures success by architecture, security, integration, and maintainability. They are thinking about whether the solution will scale and whether it can be supported over time.

Leadership measures success by outcomes. Adoption, efficiency, revenue impact, customer experience, and return on investment.

Users measure success by whether the new process helps them do their job without creating unnecessary friction.

The issue is not that these priorities conflict.

The issue is when nobody turns those conflicts into clear decisions.

Misalignment Usually Shows Up as System Feedback

After go-live, misalignment often gets blamed on the tool.

• Users say the system is too rigid.

• Sales says the workflow is too slow.

• Finance says the controls are not strong enough.

• Operations says the handoff is still messy.

• IT says the business keeps changing requirements.

• Leadership says adoption is not where it needs to be.

Sometimes the tool really does need to improve.

But often, the system is simply exposing decisions the business never fully made.

• Who owns pricing exceptions?

• What information is truly required before a quote moves forward?

• Where should approval happen?

• What does a clean order actually mean?

• Which team owns the customer promise after the deal closes?

• What tradeoff matters more: speed, control, accuracy, visibility, or flexibility?

If those questions are not answered, the system becomes the place where misalignment shows up.

Alignment Means Agreeing on Tradeoffs

Real alignment is not everyone agreeing in a kickoff meeting.

Real alignment is everyone making the same tradeoffs when the work gets real.

That means being clear about what the business is optimizing for.

• If the goal is faster quoting, where are you willing to accept more risk?

• If the goal is stronger margin control, where are you willing to add process discipline?

• If the goal is cleaner handoffs to operations, what information has to be captured earlier?

• If the goal is better customer experience, what internal complexity needs to be hidden from the customer?

• If the goal is AI readiness, what data, rules, and workflows need to be structured enough to trust?

These are not technical questions. They are operating model questions.

And they need to be decided by the business, not buried inside configuration decisions.

Strategic Enablement Keeps Alignment Alive

Alignment is not a one-time activity. It has to be maintained.

The business changes. Users react. Leaders refine priorities. New requirements emerge. AI capabilities evolve. Customer expectations shift. What looked right during design may need adjustment once the system is live.

That is why Strategic Enablement Services matter.

They create the rhythm for keeping teams aligned after the project starts and after the system goes live.

That rhythm includes feedback loops, roadmap reviews, governance, adoption tracking, release planning, stakeholder check-ins, and continuous process improvement.

Support can fix a ticket.

Enablement helps the business decide whether the ticket points to a bug, a training issue, a process gap, or an unresolved tradeoff.

That distinction matters.

Because the goal is not just to keep the system running.

The goal is to keep the business moving in the same direction.

The Takeaway

Transformation does not usually fail because stakeholders disagree.

Disagreement is normal.

Sales, finance, operations, IT, leadership, and users should see the business from different angles. That is what makes the process better.

The problem is when those differences are never translated into decisions.

That is when alignment breaks.

That is when the system becomes the battleground.

And that is when transformation starts to feel harder than it should.

The companies that get this right do not avoid tradeoffs. They make them visible, decide on them, and keep revisiting them as the business evolves.

Because alignment is not a meeting. It is an operating rhythm.

One of the hardest parts of transformation is separating what users feel from what is actually happening.

A new CRM, CPQ, ERP workflow, portal, or AI-enabled process goes live. The business case was clear: the old process was too manual, too dependent on spreadsheets, too hard to report on, and too reliant on a few people who knew how everything really worked.

Then users start reacting.

“The old system was easier.”

Sometimes they are right. The new system may have real friction that needs to be fixed. But often, that statement means something else:

The old system was familiar.

Users knew the shortcuts. They knew which fields could be skipped. They knew who to message when something got stuck. They knew which spreadsheet corrected bad data. They knew how to get the work done around the system.

That does not mean the old system was better.

It means the business had adapted to its limitations.

Familiar Is Not the Same as Effective

Old systems often feel faster because people have built muscle memory around them.

The new system feels slower because it forces people to think again.

It may require cleaner data.

It may ask for decisions earlier.

It may enforce approval logic.

It may expose handoffs that used to happen informally.

It may require teams to stop relying on tribal knowledge and put more of the process into the workflow.

That can feel like friction, but sometimes friction is just structure showing up.

If CPQ requires better product data, that is not unnecessary complexity. It is what allows the quote to be accurate.

If approvals happen earlier, that may not be bureaucracy. It may be margin protection.

If customer or order information has to be captured upfront, that may not be extra work. It may be what prevents cleanup later.

The user feels the new step.

The business needs to understand the downstream value of that step.

Workarounds Hide the Real Cost

Every legacy process has workarounds.

A spreadsheet outside the system.

An approval in email.

A manual order review before ERP.

A finance correction after the quote.

A salesperson who knows which fields “really matter.”

Over time, these workarounds become invisible. They feel normal because everyone knows how to use them.

That is the problem.

The old system can feel easy because the real work is happening somewhere else.

The new system feels hard because it brings that hidden work into the open.

This is why early user feedback matters, but it has to be interpreted carefully.

A complaint may point to bad design.

It may point to poor training.

It may point to a workflow that needs refinement.

Or it may point to an old habit the business needs to retire.

Those are very different problems.

Adoption Is a Mental Model Shift

Adoption is not just teaching people where to click.

It is helping them understand why the work changed.

• Why is the data required?

• Why does the approval happen here?

• Why does the quote need to be structured differently?

• Why does the system prevent a shortcut that used to be common?

If users do not understand the reason behind the workflow, they will compare the new system to the old workaround.

And the workaround will usually feel easier.

That is how companies end up with modern platforms and legacy behavior.

The technology changes.

The operating model does not.

Strategic Enablement Closes the Gap

This is where Strategic Enablement Services matter.

After go-live, companies need more than support tickets and training sessions. They need a rhythm for closing the gap between system design and user reality.

That means:

• listening to user feedback

• identifying real friction

• refining workflows

• reinforcing the new process

• retiring old workarounds

• tracking adoption

• connecting improvements back to business outcomes

Support fixes what is broken.

Enablement helps determine what needs to change.

A ticket can fix a field.

Enablement asks whether the field is needed, whether users understand it, and whether it supports the outcome the business wants.

That is the difference.

The Goal Is Not to Recreate the Old System

When users struggle, the easy response is to make the new system feel more like the old one.

Sometimes that is appropriate. Good feedback should improve the experience.

But if the new platform simply recreates the old process, the transformation loses its purpose.

The goal is not comfort.

The goal is capability.

• Can the business quote faster and more accurately?

• Can teams trust the data?

• Can approvals happen with better context?

• Can operations receive cleaner orders?

• Can leaders see what is happening?

Can automation and AI work because the process is structured enough to trust?

Those are the measures that matter.

The Takeaway

The old system often felt easier because everyone knew the workarounds.

That does not mean it was better.

It means the business had learned how to operate around its problems.

Modern systems expose those problems. They require cleaner data, clearer rules, better handoffs, and more shared accountability. That can feel uncomfortable at first.

But discomfort is not always a sign the system is wrong.

Sometimes it is a sign the business is finally changing.

The companies that get value from transformation are the ones that manage the perception gap. They listen to users, fix real friction, reinforce the new way of working, and retire the workarounds that no longer serve the business.

That is how adoption becomes capability.

Most transformation work starts with too much confidence.

That is not a criticism. It is just how these things go.

The kickoff feels good. The business case makes sense. Everyone agrees the current process is too manual, too slow, too dependent on a few heroic people who know how everything really works. The first workshops uncover obvious opportunities. The demos looks promising. The prototype gets people excited.

Then the real work starts.

The data is worse than expected. The exception process has exceptions. The approval path that looked simple on a whiteboard turns out to depend on three people, two spreadsheets, and a Slack thread no one documented. Users like the idea, but they are busy. Leaders want speed, but every decision has tradeoffs. IT wants something secure and maintainable. The business wants something flexible. Sales wants fewer clicks. Finance wants more control. Operations wants fewer surprises.

This is the middle.

It is where a lot of transformation efforts either mature or quietly stall.

And it is exactly where Strategic Enablement Services create value.

More on Strategic Enablement Here

Projects and Support Leave a Gap

Most companies still think about services in two buckets.

There is the project: define the scope, build the plan, hit the milestones, get to go-live.

Then there is support: fix issues, respond to requests, keep the system running.

Both matter. But neither one fully solves the problem companies are facing right now.

Projects are useful when the path is clear. The problem is that the path is often not as clear as everyone pretends it is at the beginning. You learn things as you build. Priorities shift. Users react differently than expected. AI capabilities change. The business sees the first version and immediately understands what it should have asked for.

Support is useful when something breaks. But support is usually reactive. It helps the system function. It does not necessarily help the business get better.

The real need sits between those two models.

Companies need a way to keep moving after the initial project energy fades, but before the new way of working has fully taken hold.

That is the enablement gap.

The Trough Is Not the Problem

The “trough of disillusionment” is usually talked about like it is a bad thing.

I don’t think that is always true.

The trough is often the first honest part of the transformation.

At the beginning, everything is theory. The process maps are clean. The future state looks obvious. The business case assumes a level of adoption and alignment that always feels reasonable in a deck.

Then people start using the thing.

That is when you find out what was missed.

The sales team still has a workaround. Engineering still does not trust the inputs. Finance still wants a review step that was supposed to be automated. Operations still has to clean up orders before they hit ERP. The dashboard is live, but nobody agrees what the numbers mean.

That can feel like failure.

Usually, it is just reality showing up.

The organizations that struggle are the ones that treat this moment as proof the project went wrong. The better move is to treat it as the moment where the next layer of work becomes visible.

What needs to be governed?

What needs to be simplified?

What needs more training?

What needs a better workflow?

What should be automated, and what still needs judgment?

What should be killed because it sounded good but is not actually useful?

Strategic enablement gives companies a structure for answering those questions without turning every lesson into a new project or every problem into a support ticket.

Teams Have to Storm Before They Perform

Tuckman’s model is simple for a reason: forming, storming, norming, performing.

It applies almost perfectly to transformation work.

In the forming stage, everyone is aligned because the conversation is still high-level. The goals are broad enough for everyone to agree.

Then the storming starts.

That is when the business has to make real decisions.

Who owns the process?

Who gets to approve exceptions?

What happens when sales wants speed and finance wants control?

What happens when the best customer experience creates more work for engineering?

What happens when AI can do something, but nobody is sure whether it should?

This is the part companies underestimate.

They assume friction means misalignment. Sometimes it does. But often friction means the operating model is finally becoming visible.

You are no longer talking about transformation as a concept. You are deciding how the business should actually work.

That is uncomfortable.

It is also necessary.

Strategic enablement helps teams move through that phase. Not by pretending every stakeholder wants the same thing, but by creating the rhythm to make decisions, test changes, capture feedback, and keep improving.

That is how teams get from storming to norming.

That is how a project becomes a capability.

AI Makes This More Urgent, Not Less

AI is speeding up the front end of transformation.

That is exciting. It is also creating a lot of false confidence.

A team can build a prototype in a few days. Someone can vibe-code a workflow that looks impressive by Friday. A demo can make an old process feel obsolete before anyone has dealt with permissions, governance, data quality, testing, support, or adoption.

This is the trap.

A prototype that works once is not the same as a capability the business can run.

A demo does not tell you who owns the process.

An agent does not automatically understand which exceptions matter.

A chatbot does not fix bad data.

A workflow built quickly does not automatically become secure, scalable, or maintainable.

AI makes it easier to create the first version. It does not remove the hard part of making that version trustworthy.

In some ways, AI makes Strategic Enablement more important because companies are going to create more experiments than ever. More pilots. More half-built workflows. More internal tools. More “this is almost ready” moments.

The question becomes: which of those should become part of how the business runs?

That is not just a technical question.

It is an operating model question.

Enablement Is Not Just Training

This is where the word “enablement” can get misunderstood.

A lot of people hear enablement and think training.

Training is part of it, but it is not the whole thing.

Strategic enablement is the ongoing work of turning technology into business capability.

That includes adoption, process refinement, roadmap management, governance, release planning, backlog prioritization, reporting, user feedback, and executive alignment.

It also includes asking uncomfortable questions after go-live.

Are people actually using the system?

Are they using it the way we intended?

Where are they working around it?

Which parts are creating value?

Which parts are slowing people down?

Which rules need to change?

Which reports are noise?

Which AI ideas are worth scaling?

Which ones are distractions?

That work does not fit neatly into a traditional implementation plan. It also should not be reduced to reactive support.

It needs ownership.

Go-Live Is Not the Moment of Value

Go-live matters. But it is not the moment value is created.

Value comes when the business starts working differently.

That is especially true in revenue operations.

CRM, CPQ, pricing, approvals, order management, ERP integrations, portals, service workflows, and AI capabilities are not static assets. They need to evolve as the business evolves.

Products change.

Pricing changes.

Sales motions change.

Customer expectations change.

AI capabilities change.

Internal teams change.

If the system does not keep up, it starts to drift. At first, the drift is small. A spreadsheet here. A manual approval there. A side process that “only happens for this one segment.” Then, over time, the system no longer represents how the business actually works.

That is how platforms decay.

Not all at once. Slowly.

Strategic enablement is how companies fight that drift.

The Services Model Has to Change

The old model was built around big projects and support tickets.

That is not enough for the market we are in now.

Companies need partners who can help them build, learn, adjust, govern, and improve at the same time. They need enough structure to keep moving, but enough flexibility to adapt when the business learns something new.

That is a different kind of relationship.

It is not just “implement this system.”

It is not just “fix this ticket.”

It is more like: help us keep turning this investment into measurable progress.

That is where Strategic Enablement Services fit.

They give companies a way to move through the messy middle without losing momentum.

The Takeaway

Most transformations do not fail because the original idea was bad.

They fail because no one planned for what happens after the excitement wears off.

The middle is where the real work shows up.

It is where teams storm.

Where prototypes either become trusted capabilities or die in the backlog.

Where AI experiments have to become governed workflows.

Where systems either evolve with the business or begin to decay.

That is where Strategic Enablement Services create value.

The companies that win in the age of AI will not be the ones that avoid the messy middle.

They will be the ones that build the operating rhythm to move through it.

For a long time, manufacturers treated the first sales conversation as the beginning of the buying process.

• A customer submits a form.

• A salesperson follows up.

• Discovery begins.

• Requirements are gathered.

• Engineering gets involved.

• A quote is eventually produced.

That process may still be familiar, but it no longer reflects how buyers actually behave.

By the time a customer talks to sales, they have usually already done their homework. They have researched options, compared vendors, reviewed available content, and formed an early opinion about who can help them.

The sale does not start when the salesperson gets involved.

It starts when the customer begins trying to solve the problem.

For engineer-to-order manufacturers, that shift matters.

The Buyer Is Already Moving

Customers do not want to wait for a sales call to learn what is possible.

• They want to explore.

• They want to understand tradeoffs.

• They want to see whether a solution fits their application.

• They want to know if the product can be configured around their constraints.

• They want some level of confidence before they spend time with your team.

This does not mean they expect complex products to be simple. It means they expect the buying experience to be helpful earlier.

A PDF catalog, a generic contact form, and a promise that someone will get back to them is not enough anymore.

That may capture a lead.

It does not create momentum.

Your Website Is Part of the Revenue Process

For complex manufacturers, the website used to be treated mostly as a marketing asset.

• It explained what the company did.

• It listed products.

• It showed industries served.

• It gave customers a way to request information.

That role is changing.

The website is becoming the front door to the revenue process.

If a customer can answer guided questions, visualize a solution, configure around their requirements, generate preliminary drawings, review performance information, and see budgetary pricing, they are not just browsing.

They are entering the buying process.

That changes the purpose of digital experience.

It is no longer only about awareness.

It is about helping the customer make progress.

Self-Service Creates Better Sales Conversations

Self-service is often misunderstood.

It is not about removing salespeople or engineers from the process.

It is about making the first human conversation more valuable.

When a customer can explore options before engaging your team, they arrive with better context.

• They know what they are trying to solve.

• They have seen potential solutions.

• They understand some of the tradeoffs.

• They may already have preliminary drawings or a rough configuration.

• That means sales and engineering do not start from zero.

• They can refine.

• Challenge assumptions.

• Solve edge cases.

• Confirm feasibility.

• Help the customer make a better decision.

The conversation becomes less about collecting information and more about applying expertise.

That is a better experience for everyone.

Visual Configuration Builds Confidence

In engineer-to-order environments, customers often struggle to translate requirements into a product concept.

They may know the problem they need to solve, but not the specific configuration, dimensions, options, or constraints that matter.

Visual configuration changes that.

Instead of forcing the customer to interpret tables, part numbers, and technical documents, it lets them see the solution take shape.

• As they answer questions, the model updates.

• As dimensions change, drawings adjust.

• As options are selected, rules validate what is possible.

• As the design evolves, pricing and lead-time expectations can update with it.

This creates confidence before the quote is finalized.

It also improves the quality of the opportunity.

The customer is not just asking for information. They are actively designing a solution with you.

The Best Leads Are Educated Leads

Manufacturers often think about lead generation in terms of volume.

• More form fills.

• More inquiries.

• More contacts.

But volume is not the goal. Quality is.

A customer who has already explored a configuration, reviewed drawings, understood tradeoffs, and seen budgetary pricing is a very different opportunity than someone who simply downloaded a brochure.

• They are more informed.

• They are more engaged.

• They are more likely to understand value.

• They are also more likely to have internal alignment because they can share something tangible with their own stakeholders.

That is where self-service becomes more than convenience.

It becomes a way to improve the entire revenue process.

The Handoff Still Matters

The goal is not to let the customer do everything alone.

In complex manufacturing, the handoff to sales, engineering, operations, and fulfillment still matters.

But the handoff should be cleaner.

If a customer has already created a preliminary design, the handoff should preserve that context.

• Sales should see what the customer configured.

• Engineering should see the assumptions, constraints, and selected options.

• Operations should understand what may eventually need to be built.

• Finance should understand the pricing logic.

• Service should eventually know what was promised.

That is why the buying experience cannot be disconnected from CRM, CPQ, order management, ERP, and service.

The front-end experience creates the first version of the customer’s intent.

The rest of the revenue process should carry that intent forward without losing it.

The Takeaway

The next wave of growth for complex manufacturers will not come only from better products or more aggressive sales outreach.

It will come from making it easier for customers to move forward.

• Customers want to explore before they talk.

• They want to design before they commit.

• They want to validate before they wait.

• They want confidence before they raise their hand.

The companies that understand this will treat self-service, visual configuration, drawings, pricing, and quoting as more than digital tools.

They will treat them as the beginning of the revenue process.

Because the sale does not start with a call.

It starts with a customer experience that makes the buyer believe they are already on the right path.

Imagine you’re responsible for designing a new manufacturing facility.

You’ve spent weeks defining requirements, coordinating with internal stakeholders, and narrowing down potential suppliers. Finally, you visit a manufacturer’s website hoping to explore a solution.

Instead, you’re greeted with a PDF catalog.

You download a specification sheet filled with product codes that mean nothing to you. After a few minutes of searching, you find a “Request a Quote” form asking you to describe your application in a text box.

You submit the request.

A few days later, someone emails with follow-up questions.

Another week passes before preliminary drawings arrive.

Engineering has a few concerns.

The design changes.

The quote changes.

By the time you receive a proposal, the momentum that existed when you first visited the website has largely disappeared.

For decades, we’ve accepted this as the cost of selling complex products.

But what if it isn’t?

Complexity Should Stay Behind the Curtain

Engineer-to-order manufacturers solve difficult problems. That’s what makes them valuable.

Whether it’s a stormwater retention system, an automated production line, or a custom piece of industrial equipment, these products are complex because the problems they solve are complex.

Customers understand that.

What they don’t understand—or appreciate—is when your internal complexity becomes part of their buying experience.

The customer doesn’t need to know how many engineering rules govern a configuration.

They don’t need visibility into approval chains, CAD revisions, or pricing calculations.

They simply want confidence that they’re moving toward the right solution.

The complexity belongs inside your business.

The experience belongs to the customer.

Think Less About Quoting and More About Discovery

Too often, manufacturers think of digital transformation as improving the speed of the quote.

That’s important, but it’s not where the buying experience begins.

It begins much earlier.

What if a customer could start with the problem they’re trying to solve instead of the product they’re trying to buy?

Instead of searching through catalogs and part numbers, they answer a few questions.

The system narrows the possibilities.

A visual model begins to take shape.

Dimensions adjust in real time.

Performance updates as selections change.

Engineering rules quietly validate every decision in the background.

The customer isn’t configuring a product.

They’re designing a solution.

By the time they reach out to your team, they’ve already explored options, understood tradeoffs, and developed confidence in the direction they’re taking.

That changes the conversation entirely.

The Best Engineering Is Invisible

When we admire great consumer experiences, we rarely think about the engineering behind them.

We don’t marvel at Apple’s supply chain every time we buy an iPhone.

We don’t think about Amazon’s fulfillment algorithms when we click “Buy Now.”

We remember how effortless the experience felt.

Manufacturing has an opportunity to create the same feeling.

Not by making products simpler.

But by making complexity invisible.

The engineering still exists.

The rules still exist.

The calculations still happen.

They’re simply working on behalf of the customer instead of becoming obstacles for the customer.

Self-Service Isn’t About Eliminating People

There’s a common misconception that self-service is about replacing salespeople or engineers.

It’s not.

It’s about changing when they enter the conversation.

Today, too many experts spend their time collecting information, correcting incomplete requests, and answering questions that software could answer immediately.

Imagine if customers arrived having already explored a visual design, generated preliminary drawings, reviewed budgetary pricing, and validated the basic engineering constraints.

Now your engineering team isn’t starting from scratch.

They’re refining.

Optimizing.

Advising.

That’s where expertise creates value.

Technology shouldn’t replace your experts.

It should make every conversation with them more meaningful.

Experience Is Becoming the Differentiator

Most manufacturers compete on product quality, engineering capability, and price.

Those will always matter.

But increasingly, customers are evaluating something else.

How easy is this company to work with?

Can I explore solutions without waiting for an email?

Can I visualize what I’m buying before committing to it?

Can I understand tradeoffs without scheduling another meeting?

Can I move from idea to confidence in hours instead of weeks?

The manufacturers who answer “yes” to those questions won’t just shorten sales cycles.

They’ll create trust.

And trust is remarkably difficult for competitors to copy.

The Future of Engineer-to-Order

Engineer-to-order will never be simple.

Nor should it be.

The products will remain sophisticated, the engineering will remain challenging, and every customer problem will have its own nuances.

But none of that requires the buying experience to feel difficult.

The manufacturers that lead the next decade won’t be the ones that remove complexity from their products.

They’ll be the ones that remove complexity from the customer’s journey.

That’s a different kind of engineering.

And it may become the most important one of all.

Enterprise software has gone through several eras.

First, the advantage came from implementing systems that digitized work.

Then it shifted to integrating those systems.

Today, AI is becoming the next wave.

But I think we’re asking the wrong question.

The conversation shouldn’t be, “How do we use AI?”

It should be, “How does work need to change?”

Because AI agents don’t transform businesses.

Operating models do.

The Next Competitive Advantage

For years, companies invested in CRM, CPQ, ERP, customer service, and analytics platforms.

The assumption was simple: better software would create better outcomes.

Sometimes it did.

More often, it digitized existing processes without fundamentally changing how work moved through the business.

• Sales still relied on manual handoffs.

• Engineering still reviewed every exception.

• Operations still validated orders before they reached ERP.

• Finance still reconciled pricing after the quote was approved.

• Customer service still inherited whatever information survived the journey.

The software changed. The operating model didn’t.

AI is exposing that reality.

Every AI Discussion Eventually Becomes a Workflow Discussion

Most AI initiatives begin with technology.

• Which model should we use?

• Which platform should we buy?

• Where should we start?

Those are reasonable questions.

But they don’t stay the important questions for long.

Very quickly, the conversation changes.

• Who owns this decision?

• Where does this information come from?

• Which system is the source of truth?

• Who approves pricing exceptions?

• Can the agent access customer data?

• Should it be allowed to submit an order?

• Can finance trust the output?

None of these are AI questions. They’re workflow questions.

And workflow is where transformation succeeds or fails.

Data Matters. Decisions Matter More.

There’s a lot of discussion about preparing data for AI.

That’s important.

But structured data alone isn’t enough.

Agents also need structured decisions.

Consider a complex manufacturing quote.

The product model defines what can be configured.

Pricing policies determine what can be discounted.

Approval rules define when human oversight is required.

Order validation ensures downstream teams can execute what was sold.

Those aren’t simply pieces of data.

They’re business decisions.

If those decisions exist only in tribal knowledge, spreadsheets, email chains, or individual experience, an agent has nothing reliable to execute.

The challenge isn’t giving AI more information.

It’s giving the business more consistency.

Applications Are Becoming Implementation Details

For decades, enterprise software was organized around applications.

• CRM

• CPQ

• ERP

• Customer Service

Each system had its own owner, roadmap, and implementation team.

But customers don’t experience applications.

They experience outcomes.

They don’t care which system generated the quote.

They care that it was accurate.

They don’t care how many approvals happened internally.

They care that the order arrived on time.

As agents begin working across functions, applications become less important than the workflows connecting them.

The workflow becomes the experience.

The operating model becomes the product.

This Changes the Role of IT

For years, IT was often viewed as the organization that implemented and supported enterprise systems.

That role is expanding.

Agents don’t live inside one department.

They operate across sales, operations, finance, engineering, service, and fulfillment.

That requires governance.

• Security

• Permissions

• Data architecture

• Integration

• Business logic

IT isn’t becoming more important because of AI.

It’s becoming more central because the workflows themselves are becoming digital assets that span the entire organization.

But IT can’t do this alone.

Revenue leaders, operations, finance, engineering, and service teams all own part of the workflow.

The future operating model has to be designed together.

Lead-to-Cash Is the Best Place to Start

Revenue operations sits at the intersection of nearly every function in the business.

A single customer request can touch sales, engineering, pricing, finance, manufacturing, fulfillment, and customer service.

That’s exactly why lead-to-cash is such a valuable place to evaluate agent readiness.

• Every unnecessary approval

• Every manual pricing review

• Every spreadsheet

• Every rekeyed order

• Every engineering exception

• Every downstream correction

These aren’t just inefficiencies.

They’re signals that the operating model still depends on people bridging gaps between systems.

Agents won’t eliminate those gaps. They’ll make them visible.

The Real Work Begins Before the Agent

The organizations creating the most value with AI aren’t simply deploying more agents.

• They’re redesigning how work moves through the business.

• They’re clarifying decision ownership.

• Standardizing policies.

• Reducing unnecessary handoffs.

• Connecting systems around outcomes instead of departments.

Only then do agents become powerful.

Not because they’re intelligent.

Because the business has become understandable.

The Takeaway

AI is rapidly becoming part of every enterprise platform.

Soon, every company will have access to capable models.

That won’t be the differentiator.

The differentiator will be how well organizations redesign the work those models support.

Companies that continue to optimize individual applications will see incremental improvements.

Companies that redesign their operating model will unlock something much bigger.

Because in the agent era, your operating model isn’t just how your business runs.

It’s your competitive advantage.

AI agents are going to change how work gets done.

That is not the debate.

The real question is whether your business process is ready for them.

For revenue teams, this matters most in lead-to-cash. CRM, CPQ, approvals, order management, ERP, finance, and service all depend on each other. A small gap early in the process can create rework, delays, margin issues, or customer confusion later.

Agents will not make that problem disappear.

They will expose it.

Agents Need More Than Access

It is easy to imagine an agent helping a sales team.

An agent could summarize an opportunity.

Recommend the right product.

Draft a quote.

Flag a pricing issue.

Route an approval.

Check order readiness.

Prepare renewal options.

Answer customer questions.

All of that sounds useful.

But an agent needs more than access to systems. It needs a process it can trust.

If CRM data is incomplete, the agent has weak context.

If product rules are inconsistent, the agent cannot recommend confidently.

If pricing logic lives in spreadsheets, the agent has to guess.

If approvals depend on tribal knowledge, the agent cannot route work cleanly.

If CPQ output still requires manual cleanup before ERP, the agent may accelerate the wrong handoff.

The issue is not whether AI can perform tasks.

The issue is whether the business has defined the work clearly enough for AI to assist safely.

Most Revenue Processes Still Rely on Interpretation

Lead-to-cash often looks structured from the outside.

There is a CRM.

There is a quoting tool.

There is an approval process.

There is an ERP integration.

There are reports.

But the real process usually depends on people filling in the gaps.

Sales knows which details to ask for because they have learned from past mistakes.

Operations knows which quote fields to double-check before an order is created.

Finance knows which discount scenarios require extra review.

Engineering knows which product combinations need validation.

Customer service knows which promises create downstream issues.

That knowledge is valuable.

But when it only lives in people’s heads, email threads, spreadsheets, or one-off reviews, it is not ready for agents.

Agents need explicit rules, clean data, reliable handoffs, and defined outcomes.

Without that, they do not automate the process.

They amplify the inconsistency.

The Risk Is Speed Without Clarity

Bad processes are already expensive.

AI can make them more expensive if companies automate before they understand where the process breaks.

A seller may get a quote faster, but the quote may still require manual correction.

An approval may route faster, but the approval logic may still be unclear.

A customer response may be generated faster, but it may be based on incomplete order context.

An order may move faster into ERP, but the fulfillment team may still need to clean it up.

Speed is only valuable when the process is accurate.

Otherwise, AI just moves bad information faster.

That is the risk.

The Readiness Questions

Before adding agents into the revenue lifecycle, companies should ask a few practical questions.

Can we define what information must be captured before a quote is created?

Can we explain how product recommendations should be made?

Can we trust our product and pricing rules?

Can we identify which approvals are required and why?

Can we tell the difference between a standard quote and an exception?

Can we move from quote to order without rekeying or interpretation?

Can service, finance, delivery, and operations see what was promised to the customer?

Can we trace where margin, timing, or fulfillment risk enters the process?

If the answer is no, the company may still benefit from AI.

But it is probably not ready to hand meaningful revenue work to agents yet.

CPQ Is a Good Test Case

Quoting is one of the best places to evaluate agent readiness.

It sits at the center of product complexity, pricing logic, approvals, customer commitments, and ERP handoff.

If the quoting process is clear, agents can help.

They can guide sellers.

Surface similar deals.

Suggest configurations.

Explain pricing logic.

Draft customer-facing language.

Identify missing information.

Flag risk before the quote moves forward.

But if the quoting process is unclear, agents will struggle.

They will expose messy product data.

They will surface inconsistent pricing logic.

They will reveal approval paths that depend on personal judgment.

They will show where the ERP handoff is not as clean as the integration diagram suggests.

That is not a failure of AI.

That is the process becoming visible.

The Work Before the Agent

The companies that get value from agents will not simply be the ones that move fastest.

They will be the ones that prepare the work.

That means defining the revenue workflow.

Cleaning up product and pricing logic.

Documenting approval rules.

Reducing unnecessary handoffs.

Structuring data across CRM, CPQ, SOM, and ERP.

Clarifying which decisions can be automated, which need human review, and which should never be handled without approval.

This is not glamorous work.

But it is the work that makes AI useful.

Agents are only as strong as the workflow underneath them.

The Takeaway

Your revenue process does not need to be perfect before you use AI.

But it does need to be understood.

If your team cannot clearly explain how an opportunity becomes a valid quote, how that quote becomes an approved order, and how that order moves cleanly into fulfillment, then agents will not solve the problem.

They will reveal it.

That is not a reason to wait.

It is a reason to assess the workflow now.

Because the companies that prepare their revenue lifecycle for agents will have a real advantage.

They will quote faster.

Approve cleaner.

Reduce rework.

Protect margin.

Improve customer experience.

And use AI to accelerate work that is already structured enough to trust.

That is where the value will be.

Enterprise software is entering a new phase.

For years, companies bought applications to support individual functions. CRM for sales. CPQ for quoting. ERP for operations. Case systems for support. Reporting tools to understand what happened across all of them.

Each system had a purpose.

But in many companies, the business process never became as connected as the software stack suggested.

That is the issue AI is now exposing.

The future is not just about buying less software. It is about expecting software to help complete the work.

Disconnected Software Creates Disconnected Work

Lead-to-cash is one of the clearest examples.

A seller manages the opportunity in CRM.

A quote gets built in CPQ.

Pricing exceptions go through approvals.

Engineering or operations gets pulled in when the request does not fit the standard model.

ERP receives the order.

Customer service inherits what was promised.

On paper, these systems may be integrated.

In practice, the process often still depends on people to interpret, validate, correct, and move work across the lifecycle.

That is not just a technology issue.

It is a workflow issue.

SaaS Created Access. It Did Not Always Create Alignment.

The SaaS era made software easier to buy, deploy, and scale.

It also made it easier for every department to optimize its own part of the process.

Sales tracks pipeline.

CPQ manages configuration and pricing.

Operations focuses on fulfillment readiness.

Finance focuses on margin and billing.

Service focuses on what the customer was promised.

Each function may be doing its job, but the customer does not experience the business as separate systems. They experience one journey.

When the internal workflow is disconnected, the result is delay, rework, margin leakage, order fallout, and customer frustration.

Eventually, the question becomes simple:

Why do we have this much software if the process still feels this hard?

AI Raises the Standard

AI changes what companies should expect from software.

Applications that only store data, create tasks, or add another handoff will be harder to justify.

That does not mean CRM, CPQ, ERP, or order management go away.

It means their value has to shift.

The value is not just having a system of record.

The value is whether that system participates in a workflow that drives an outcome.

Can CRM capture the right information early enough to guide the quote?

Can CPQ apply product, pricing, and approval logic without constant manual intervention?

Can Sales Order Management create a clean handoff into ERP?

Can service and delivery teams see what was sold, approved, promised, and ordered?

Can AI assist safely because the underlying rules and processes are clear enough to trust?

Those are the questions that matter now.

The Real Issue Is Disconnected Work

The decline is not software itself.

The decline is tolerance for disconnected, underutilized, low-context software.

Companies will not eliminate every application. But they will keep questioning tools that do not help work move across the business.

That is especially true in lead-to-cash.

CRM, CPQ, approvals, order management, ERP, and renewals cannot be treated as isolated systems forever. The business outcome depends on how well those pieces work together.

Before companies add more automation or AI, they need to understand where the current process creates friction.

Where does information get lost?

Where do teams reinterpret what the customer asked for?

Where do approvals compensate for poor rules?

Where does quoting depend on tribal knowledge?

Where does ERP receive an order that still needs cleanup?

Those are workflow problems.

And they are the problems AI will expose first.

The Takeaway

The next phase of enterprise software will not be measured by how many applications a company owns or how many users have access.

It will be measured by how effectively work gets done.

For lead-to-cash teams, the focus has to shift from systems to workflows.

From implementation to outcomes.

From software access to process clarity.

From disconnected tools to connected revenue operations.

That is the real opportunity.

Earlier this year, roughly $285 billion in SaaS market value evaporated in about 48 hours. The press called it the SAASpocalypse. The trigger was simple to state. Investors decided that if AI agents can do the work of ten people, companies stop paying for ten seats. Jason Lemkin put it in the sentence everyone has been repeating since. If 10 agents do the work of 100 reps, you need 10 Salesforce seats, not 100.

It is tempting to read that as a story about software vendors and their stock prices. It is bigger than that. The seat, the per-user license, the priced-by-headcount model, has been the default unit of value for a generation of SaaS selling. What the market just repriced is the assumption that the unit holds. And once buyers stop accepting “price per user” as the natural way to buy, that pressure does not stay inside the software industry. It moves to everyone who sells anything.

Your buyers are already there. They want to pay for outcomes, for usage, for what they consume, for results rather than access. That shift was underway before agents arrived. Agents just made it impossible to ignore.

Which raises a question that has nothing to do with whether your CRM vendor survives the year, and everything to do with how you sell. When the unit of value stops being a simple count, something else has to become the thing you price, quote, and stand behind. And that something lives in CPQ.

The pricing model is the real story

Aaron Levie has been making the durable version of the agent argument. His framing is that the revenue model slides along a continuum. Some value still gets sold as seats, and a growing share gets monetized through consumption as agents and automation do more of the work. You can already see the blend in newer products that pair a per-user component with usage billing on top.

Now push that down to your own deals. The future of how you price is not “seats die, consumption wins.” It is hybrid, and it is different for every customer. One account is a base subscription plus metered usage above a threshold. Another is a flat platform fee with outcome-based bonuses. Another is tiered consumption with volume breaks and a committed minimum. The pricing logic that used to be “quantity times rate” becomes a branching set of rules that change by customer, by product, by term, by month.

That is a CPQ problem, and it always was. The era of simple unit pricing let a lot of companies avoid admitting how primitive their quoting logic actually was. When a quote was quantity times a number, you could survive on a spreadsheet and a seasoned rep’s judgment. Consumption, outcome, and hybrid models do not forgive that. They demand pricing, eligibility, and approval logic that is genuinely codified, versioned, and reliable, because the deal structures are too varied and too conditional to live in anyone’s head.

So the first uncomfortable question the SAASpocalypse raises is not “will agents take our jobs.” It is “can our quoting engine even express the models our customers now expect to buy.” For a lot of companies, the honest answer is not yet.

The second problem: agents have to reach the logic

There is a second question behind the first, and it decides whether the agent automation everyone is excited about actually works in your revenue motion.

If agents are going to help run quoting, checking eligibility, applying the right consumption tier, structuring an outcome-based deal, routing approvals, they have to reach your pricing logic directly. Not by clicking through a screen. By asking the engine a question and getting a deterministic answer.

This is where Levie keeps planting a flag, and his framing is closer to the headless argument than he probably intends. His point is that mission-critical processes need to be defined in deterministic business logic, precisely because the risk of an agent improvising something wrong on any given day is real. He has watched agents leak data and damage production systems. The lesson is not “avoid agents.” It is “put the business logic in a deterministic system the agent calls, rather than in something it has to improvise against.”

That is the entire case for headless CPQ, made by someone with a public-company balance sheet behind him.

For most of the last decade, the quality of a CPQ implementation was judged by what the user saw. Clean guided selling. Smart product pickers. Approval screens that surfaced the right exception at the right moment. The interface was the product. Configuration meant shaping screens until they fit how sellers worked.

In that world, pricing rules, eligibility logic, and approval thresholds end up living inside the presentation layer. An agent can only reach them by impersonating a user. Which screen, which sequence, which field fires which rule, which section renders only after a particular value is chosen. The logic is not addressable. It is performed. And anything performed through a UI inherits every fragility of that UI, including the silent rule that only fires when a human happens to click in the right order.

You cannot build reliable consumption pricing, and you certainly cannot let an agent operate it, on top of logic that is only reachable by pretending to be a person.

Headless is the precondition, not the upgrade

Headless usually gets sold as modernization. Decouple the front end, gain flexibility, support more channels. All true, and all beside the point now.

In a world where deals are priced by consumption and outcomes, and where agents help assemble them, headless stops being a preference and becomes the precondition for the thing you actually need. An agent has to ask your quoting engine direct questions and get the same answer every time. Is this configuration valid? What is the price at this volume on this tier with these terms? Does this require approval, and from whom? Those are API calls. They have to return identical answers regardless of what screen exists, regardless of click order, regardless of whether a human is anywhere near the transaction.

That only works when the logic lives below the interface, in a service layer the UI also happens to call. When the engine is headless by design, the human screen and the agent are simply two clients of the same logic. They get the same answer because they hit the same endpoint. The agent is not impersonating anyone. It is a first-class consumer of the system, exactly like the screen.

This is the line that separates a platform that can actually support agents from one with a conversational front end bolted onto UI-bound logic and called AI.

What this means if you are rethinking how you sell

The question to ask is not “does our platform have AI features.” Everyone says yes. Two better questions, both about your own revenue motion:

First, can our quoting engine express the way our customers now want to buy. If your pricing logic cannot represent metered usage, tiers, outcomes, and hybrids as actual rules rather than manual workarounds, you are not ready for the models the market is already moving toward.

Second, can an agent reach that full pricing and quoting logic without going through a screen. If the answer involves any version of “the assistant drives the UI,” your logic and your interface are the same thing, and you will fight that system the moment you try to automate beyond a scripted demo.

Levie is also right about the scale of the work ahead. He has called the agent transition a services wave larger than the move to cloud, because agents rewire the business process itself rather than just changing how software is delivered. That rewiring is the real work in front of revenue teams. Excavating the pricing rules that currently live in spreadsheets and tribal knowledge, codifying them, and exposing them as logic an agent can stand on.

The seat era let everyone judge CPQ by what they could see. The era that follows will judge it by what it can price, and by what an agent can call. When seats die, the quoting engine cannot stay a pretty front end with a spreadsheet behind it. It has to grow up.

Build the engine an agent can talk to. The rest follows.

Sales says the reps need faster quotes. RevOps says the process is broken. Finance wants guardrails on discounting. IT asks about integrations. The CRM team wants to make sure their system stays central.

It’s a reasonable room. It’s also the wrong room.

The people who actually live with a bad CPQ decision — the ones who rework the orders, absorb the exceptions, resolve the billing disputes, and rebuild the customer relationships — are almost never invited to the table.

That asymmetry is why so many CPQ implementations look like a success at go-live and a problem six months later.

Who’s Not in the Room — and Why It Matters

Walk through what actually happens after a quote becomes an order.

Order Management inherits whatever the quote said. If the configuration was sloppy or the line items don’t map cleanly to fulfillable SKUs, they’re the ones translating a commercial promise into something a warehouse or a vendor can actually act on.

Billing and Invoicing triggers off the order. If the discounting structure was non-standard, if a bundle wasn’t decomposed correctly, or if the contract terms were captured in a PDF instead of a structured field — the invoice is wrong. The dispute follows.

Field Service shows up at the customer site with whatever the work order says. If the CPQ didn’t generate a proper service requirement, the technician either doesn’t have the right parts, or the system doesn’t know the asset exists yet.

Customer Service fields the calls when any of the above goes sideways. They’re resolving the downstream damage from a quote that was fast but wrong.

Contract Operations manages the renewal baseline. If the original quote didn’t capture the right entitlements, the right terms, or the right asset relationships, the renewal conversation starts from a broken foundation.

None of these teams chose the CPQ. None of them were in the room. All of them pay the price.

The Quote Is an Operational Promise — Not a Sales Document

Here’s the framing that should reorient every CPQ decision:

The quote is the first operational promise a company makes to a customer.

Not a sales artifact. Not a pricing document. A promise — to deliver something specific, at a specific price, under specific terms, in a specific timeframe. Every team downstream of that promise is responsible for keeping it.

That means the scope of a CPQ decision is not “how do we get quotes out faster.” The scope is: how do we make sure the quote creates an order we can fulfill, invoice correctly, service properly, asset-track accurately, and renew from a clean baseline.

“Quote-to-cash” undersells this. The quote becomes an order, a delivery plan, a field service requirement, an asset record, a warranty obligation, a billing trigger, a renewal baseline, and a margin commitment. That’s not a sales process. That’s the entire operating model of a complex business.

Why CRM Isn’t the Right Center of Gravity Here

This is where a lot of CPQ conversations go sideways.

CRM is the right system for relationship management and pipeline tracking. It’s the right system for logging activity, forecasting, and managing the customer record. Nobody is arguing that.

But when the commercial process gets complex — when you’re configuring multi-product bundles, managing approval chains, decomposing orders into fulfillment components, creating assets, triggering service obligations, and setting the terms for future renewals — you’re no longer doing relationship management.

You’re doing workflow execution.

That’s a different system requirement. And it’s why ServiceNow CPQ changes the conversation.

ServiceNow CPQ doesn’t sit alongside the downstream workflows. It sits *inside* them. CSM, FSM, SOM, asset management, entitlements, billing — these are native to the platform. When a quote becomes an order on ServiceNow, the downstream isn’t an integration problem. It’s a configuration.

The center of gravity for complex commercial processes doesn’t belong in the CRM. It belongs where the execution happens.

What Mountain Point Does Differently

Most CPQ implementations are designed by the same people who wrote the original problem statement: Sales and RevOps, with IT along for the ride.

We bring in the downstream stakeholders early — before the solution is scoped, before the data model is locked, before the integration decisions are made.

Not because we want a longer discovery process. Because the people who absorb the operational risk of a bad quote are the people who can tell you exactly where the current system fails.

Field Service knows which order types always create rework. Billing knows which discount structures always generate disputes. Order Management knows which product configurations never fulfill cleanly. That’s the intelligence that shapes a good CPQ implementation.

When those voices are in the room at the start, the solution is built for the whole promise — not just the moment of sale.

The Real Win

Faster quotes are good.

Fulfillable, profitable, serviceable quotes are the real win.

If your CPQ evaluation is only measuring quote velocity and CRM integration, you’re measuring the wrong things. The right questions are: What happens when this quote becomes an order? Who touches it, what do they need, and where does it break today?

The teams who can answer those questions aren’t usually in the buying room. They should be.

That gap has a name: revenue lifecycle management. And its absence is responsible for more downstream operational pain than most leadership teams want to admit.

What Revenue Lifecycle Management Actually Is

Revenue lifecycle management (RLM) is the discipline of treating the entire customer revenue relationship, from the first quote to the final renewal, as one continuous, managed process. It requires clear ownership at every stage, clean data handoffs between them, and accountability for revenue outcomes across functions.

It is not a software platform. It is not a feature set. It is an operating model: the way a business governs how revenue is created, delivered, billed, and renewed.

The technology that supports RLM matters. But companies that buy software hoping it will deliver RLM without first building the underlying discipline consistently get the same result: a new system layered on top of the same broken handoffs.

The technology enables the operating model. It doesn’t replace it.

The Revenue Lifecycle: What It Covers

The revenue lifecycle spans six core stages. Each involves different teams, different data, and different systems. The breakdown happens at the seams between them.

1. Quoting and Pricing. This is where the commercial promise is made. If the quote is wrong, incomplete, unprofitable, or disconnected from what operations can actually deliver, every downstream stage inherits the problem.

2. Contract. Terms, obligations, discount approvals, and entitlements are captured here. Non-standard terms negotiated at this stage become operational landmines that surface months later in billing or renewals.

3. Order and Fulfillment. At this stage, the deal passes from sales to delivery, operations, or professional services. Data gaps in the handoff, whether missing configurations, unclear scope, or rekeyed information, show up immediately as service exceptions or scope disputes.

4. Billing and Invoicing. When the billing team is working from a different set of terms than the delivery team, revenue leakage begins. Disputed invoices, manual corrections, and delayed collections are the symptoms. Misaligned data is the cause.

5. Revenue Recognition. For businesses with complex deals, subscription elements, or professional services, this stage is perpetually dependent on the accuracy of everything that came before it.

6. Renewals and Expansions. Renewal success is largely determined upstream: accurate entitlement records, clear service history, and the right pricing baseline. When those foundations are missing, renewal becomes a negotiation rather than a motion.

RLM vs. Related Frameworks

These terms get used interchangeably. They shouldn’t be.

Framework - What It Is - How It Relates to RLM

Quote-to-Cash (Q2C) The process from quote creation through cash collection. A process slice. It covers the commercial transaction. RLM extends into renewals, expansions, and ongoing revenue governance.

Lead-to-Cash (L2C) The end-to-end process from lead generation through payment. Starts earlier than Q2C but, like Q2C, typically ends at payment. RLM governs the full customer revenue relationship, including post-payment stages.

Revenue Operations (RevOps) The function responsible for aligning sales, marketing, and CS around revenue RevOps is the team. RLM is the operating model they manage. A RevOps function without a revenue lifecycle discipline has accountability without a framework.

Where B2B Companies Break Down

Revenue doesn’t leak all at once. It seeps out across the lifecycle, at every stage where ownership is unclear or data doesn’t travel cleanly between teams.

Siloed handoffs between functions. Sales owns the deal until it closes. Then it’s someone else’s problem. The team receiving the order often lacks critical context: the non-standard terms, the verbal commitments made during negotiation, the configuration details that never made it into the CRM. Every handoff without a clean data transfer is a revenue risk.

Manual reconciliation between systems. When the quoting system, the contract management system, and the billing system aren’t connected, someone bridges them manually. Usually a person with a spreadsheet. Manual reconciliation is slow, error-prone, and invisible. Leadership rarely knows how much human effort is spent translating data from one format to another.

Revenue leakage at the contract-to-billing gap. The most common and most expensive failure point. Research consistently estimates that B2B companies lose between 1 and 5% of revenue to billing errors, unenforced terms, and underbilled services. At scale, this is not a rounding error. It is a structural problem caused by distance between what was agreed in the contract and what is actually billed.

No single source of truth for pricing and terms. Different teams operate from different versions of a deal. Sales has one set of terms in the CRM. Legal has another in the contract repository. Billing has a third in the ERP. When a dispute arises, there’s no authoritative source everyone agrees to. Resolution requires human archaeology instead of a system answer.

Renewals treated as afterthoughts, not lifecycle milestones. The renewal is the most predictable event in the customer lifecycle. It has a known date, a known value, and a known owner. Yet most organizations treat it reactively, surfacing it 60 to 90 days before expiry, scrambling to find the right pricing baseline, hoping the customer hasn’t already moved on. This is not a sales problem. It is a lifecycle design problem.

No visibility from quote to collected cash. Most CROs can tell you their pipeline. Very few can tell you, in real time, what percentage of booked revenue has been delivered, billed, collected, and renewed. That visibility gap is the gap between having a sales process and having a revenue lifecycle.

What Good Revenue Lifecycle Management Looks Like

Revenue lifecycle management done well doesn’t look like a software demo. It looks like a business that moves with less friction and surprises less often.

Continuous data flow across stages. When a deal closes, the data that matters, including configuration, pricing, terms, and obligations, moves automatically to the next stage. Order management, delivery, billing, and renewal all start from the same baseline. Nobody reruns the quote from memory.

Cross-functional ownership with clear handoff protocols. Every stage of the lifecycle has a named owner. Every handoff has a defined checklist. The transition from sales to delivery is a designed event, not a hallway conversation.

Revenue leakage tracked and measured. Companies with a functioning RLM discipline know their leakage rate. They can tell you what percentage of revenue is at risk at the billing stage, which contract types produce the most disputes, and how long manual reconciliation takes. You can’t fix what you can’t measure.

Renewals as a designed motion. The renewal doesn’t begin 60 days before expiry. It begins at contract signature, with accurate entitlement records, a clear expansion baseline, and a service history the renewal conversation can actually reference.

Feedback loops that run upstream. When fulfillment teams encounter delivery exceptions, that signal flows back to quoting to fix the configuration logic. When billing disputes spike, that signal flows back to contracting to fix the terms structure. The lifecycle self-corrects rather than absorbing friction silently.

Why RLM Is Getting More Attention Now

Revenue lifecycle management isn’t a new concept. The reason it’s receiving more attention comes down to three compounding pressures.

Subscription and usage-based models are harder to govern. When revenue was mostly transactional, one deal and one invoice, the gaps between lifecycle stages were manageable. Subscription, usage, and outcome-based pricing mean the revenue relationship extends indefinitely, and every stage (especially billing and renewals) happens repeatedly. Manual processes that were merely inefficient in a transactional model become structurally untenable in a recurring revenue model.

The cost of complexity has risen. Deal structures have gotten more complicated: bundled products and services, multi-year contracts with variable terms, channel and partner overlays, multi-currency configurations. Each layer of complexity is a new opportunity for data to break between stages. What was once handled informally now requires either automation or significant manual effort to bridge.

AI tools are only as good as the data flowing through the lifecycle. AI-assisted quoting, intelligent contract review, automated billing reconciliation: these tools are being adopted quickly. But every one of them is downstream of data quality. If the lifecycle stages aren’t producing clean, structured, connected data, the AI tools inherit the mess. RLM isn’t just a prerequisite for operational efficiency. It’s a prerequisite for AI that actually works.

The Real Cost of Not Having One

Companies that manage revenue in disconnected stages aren’t just leaving efficiency on the table. They’re accumulating hidden costs that compound over time: revenue that doesn’t get billed, renewals that don’t get noticed, contracts that don’t get enforced, exceptions handled manually a hundred times before anyone asks why they keep happening.

The organizations that get this right don’t have a secret. They’ve decided that the full arc of the customer revenue relationship, from the first commercial conversation to the final renewal, deserves to be designed, owned, and measured with the same rigor as any other core business process.

That’s what revenue lifecycle management is. Not a product. Not a platform. A discipline — and the decision to practice it.

That framing is right. And it’s going to send a lot of enterprise teams in exactly the wrong direction.

──────────────────────────────────────

The Front Door Isn’t the Problem

Everyone heard the Forrester take, nodded along, and is now drafting an internal memo about adding AI to their quoting process. Some are already evaluating quote-to-cash orchestration agents. A few have probably already kicked off a proof of concept.

Here’s what almost none of them are asking: What happens on the other side of that front door?

A front door only works if there’s a functioning building behind it. In most enterprise revenue stacks, what’s behind the door is a collection of disconnected systems, manual handoffs, and tribal knowledge held together by ops team heroics and spreadsheets no one will admit exist.

Deploy an AI agent on top of that and you don’t get faster revenue. You get faster chaos.

──────────────────────────────────────

What “Broken” Actually Looks Like

Picture a mid-market manufacturing company. They run ServiceNow. Their CPQ process is reasonably mature — sales reps configure quotes, approvals flow through a defined workflow, and deals close on time.

Then what happens?

The accepted quote gets manually re-entered into the order management system by an ops coordinator. The line items don’t map cleanly to SKUs that field service recognizes. The delivery SLA in the quote doesn’t match what’s been committed in the customer success platform. The billing team doesn’t see the entitlements until two weeks after the contract is signed. Renewals run off a separate asset record that no one keeps current.

Now add an AI agent to that system.

The AI approves the quote faster. It routes to the right rep faster. It flags discount exceptions faster. And then it hands off to the same broken downstream process — just with more velocity behind it. Faster approvals on quotes that still fail in delivery. Faster routing on data that still gets rekeyed by three different teams before an order ships.

Speed isn’t the bottleneck. Architecture is.

──────────────────────────────────────

The Architecture Requirement

Here’s the principle that should drive every conversation about agentic AI in CPQ:

The quote is the first operational promise a company makes to a customer.

When a customer accepts a quote, that data isn’t just a sales record — it’s the blueprint for everything that follows. Order decomposition. Delivery planning. Field service scheduling. Asset record creation. Billing triggers. Entitlement setup. Renewal terms. Every downstream system needs to act on what that quote contains.

For an AI agent to operate across that lifecycle — not just at the front door but through the whole building — the data has to flow. Cleanly. Without translation layers, without manual reentry, without someone in ops reconciling what the quote said against what the order system expects.

ServiceNow CPQ’s structural advantage is that ServiceNow already sits in most of those downstream workflows. The platform story for a connected revenue lifecycle is coherent. SOM, CSM, FSM, asset management, portals, billing integration — it’s all there. But “it’s all there” is not the same as “it’s all connected.” That’s architecture work. It doesn’t happen by default.

──────────────────────────────────────

The Real Question Before You Greenlight an AI CPQ Project

Before you ask “how do we add AI to our CPQ?” — ask this instead:

If an AI agent accepted this quote on behalf of our customer right now, could every downstream system act on it without human intervention?

Be honest. Walk it through. Could your order management system decompose the line items automatically? Could field service schedule against the delivery terms in the quote? Would billing trigger correctly without an ops coordinator touching anything?

For most enterprises, the answer is no. And that’s not an argument against AI in CPQ. It’s an argument for doing the architecture work first — or at minimum, in parallel.

─────────────────────────────────────

The Forcing Function You’ve Been Waiting For

Here’s the upside of this moment: agentic AI in CPQ is the best internal business case for revenue lifecycle architecture work that most teams have seen in years.

For a long time, the pitch for connecting CPQ to SOM to CSM to billing was a slow, abstract one. “Better data hygiene.” “Reduced re-keying.” “Improved renewal rates.” Real benefits, hard to make urgent.

The agentic AI conversation changes the stakes. Now the pitch is: “If we don’t connect these systems, we’re going to automate the broken process and make it worse. And we’re going to do it fast.” That lands differently in a budget conversation.

The Forrester framing is correct. CPQ is the AI agent’s front door to revenue. Use that framing — but use it to make the case for building the rest of the building, not just putting a smarter lock on the door.

Most companies treat a quote like a pricing document. It gets built, approved, sent, and signed. Then the real work begins.

That sequencing is the problem.

By the time a quote reaches a customer, it isn’t just numbers on a page. It’s a commitment. A commitment that order management has to execute, field service may have to honor, billing will need to invoice correctly, and your renewals team will inherit years from now.

If the quote is wrong — misconfigured, underpriced, or disconnected from what operations can actually deliver — every team downstream pays. Not once. Every time.

This is what makes CPQ a different category of software than most organizations treat it as. Configuration, pricing, and quoting aren’t just commercial processes. They’re where the handoff from commercial intent to operational execution happens. The quote is the first place a business makes a concrete promise to a customer — not in spirit, but in specifics.

The problem isn’t usually quote accuracy in isolation. It’s that CPQ systems were built to close deals faster. They optimized for sales cycle speed: approvals, discounting, document generation. What they didn’t build for was operational coherence downstream.

So quotes get approved that operations can’t fulfill cleanly. Products get configured that manufacturing can’t build to spec. Pricing gets discounted in ways that break billing logic. Renewals inherit assumptions from a deal that was never fully documented.

The teams cleaning this up aren’t the ones who built the quote. They’re the ones who never saw it.

This is why “quote-to-cash” — the frame the industry has used for years — aims at the wrong target. Cash isn’t the goal. The goal is a customer who received what was promised.

Quote-to-customer-outcome means the quote is designed to be executable, not just signable. CPQ isn’t only the sales team’s tool. It’s the connective tissue between commercial intent and operational execution — the moment where what you promised becomes what you have to deliver.

Companies running on ServiceNow are in a structurally different position here. ServiceNow isn’t a quoting tool. It’s a workflow platform. When CPQ lives there, the quote doesn’t become a document that gets emailed. It becomes a structured workflow that triggers fulfillment, provisioning, billing, and asset tracking — all from the same data model.

That changes what the quote can do.

Not faster quotes. Better promises.

The future of CPQ isn’t about speed. It’s about whether the thing you sold is the thing the customer gets.