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.

For years, CPQ has been treated as a sales tool.

It lived in the “front office,” owned by sales ops and revenue ops, evaluated based on how quickly reps could generate quotes and how accurately pricing rules were applied. If it helped close deals faster, it was doing its job.

That framing is now outdated.

The real story is this: CPQ is becoming the entry point into the entire revenue lifecycle. And that shift is creating a meaningful opening for ServiceNow.

The broken line between front and back office

Enterprises have historically drawn a clean line:

• Front office: CRM, marketing, sales

• Back office: service, operations, fulfillment, field service, finance, IT

But that line has never reflected reality—it just reflected org charts and system ownership.

Because the moment a quote is created, the business is making a promise.

A promise about:

• What will be delivered

• How it will be delivered

• When it will be delivered

• What it will cost

• What is included in service and support

And if that promise is wrong, incomplete, or disconnected from execution, the pain doesn’t stay in sales.

It shows up downstream.

Where CPQ actually breaks businesses

When quotes are inaccurate or poorly structured, the fallout is predictable:

• Orders require manual intervention

• Fulfillment teams lack critical data

• Field service shows up unprepared

• Billing doesn’t match expectations

• Warranty and entitlement records are incomplete

• Customer service deals with avoidable escalations

• Renewals become harder than they should be

In other words: CPQ failures are paid for by the back office.

And yet, those teams are rarely central to CPQ evaluations.

That’s the gap.

The shift: from quote-to-cash to quote-to-outcome

Most CPQ conversations still revolve around “quote-to-cash.”

That’s too narrow.

In complex businesses, a quote doesn’t just turn into revenue. It turns into:

• An order

• A delivery plan

• A field service requirement

• An asset record

• A warranty obligation

• A billing event

• A support expectation

• A renewal baseline

A better framing is:

CPQ is not about generating quotes. It’s about generating executable business outcomes.

Why ServiceNow has a real opportunity

ServiceNow’s move into CPQ and Sales & Order Management is often interpreted as a CRM expansion play.

That’s incomplete.

The more important dynamic is this: ServiceNow already owns the workflows where bad quotes create pain.

• Customer Service Management

• Field Service Management

• Order Management

• Asset and configuration data

• Workflow automation across departments

That means ServiceNow is uniquely positioned to connect the commercial moment (the quote) with the operational reality (everything that follows).

This is fundamentally different from traditional CPQ positioning.

Instead of asking:

“How do we help sales quote faster?”

ServiceNow can ask:

“How do we ensure every quote becomes a clean, fulfillable, serviceable, and billable outcome?”

That’s a much bigger problem—and a much more valuable one to solve.

The real wedge: revenue as workflow

This is where the strategy becomes clear.

ServiceNow is not just trying to compete in CRM.

It is reframing the category around revenue as workflow.

• CRM tracks activity

• CPQ defines the commercial structure

• SOM orchestrates orders

• Service and field teams execute delivery

• Assets, contracts, and entitlements persist the relationship

If those pieces are disconnected, the business slows down and costs increase.

If they are connected, the company moves faster with less friction.

ServiceNow’s advantage is that it already operates in the system of action—not just the system of record.

The overlooked stakeholders

One of the biggest blind spots in CPQ today is who gets a seat at the table.

Typical buyers:

• Sales leadership

• RevOps

• Finance

• IT

• CRM owners

Missing voices:

• Customer service

• Field service

• Order management

• Fulfillment

• Warranty and contract teams

• Delivery/implementation teams

These are the teams that deal with the consequences of bad quotes every day.

Bringing them into the evaluation process changes the conversation entirely.

It shifts the focus from:

• Speed of quote generation

to:

• Quality and executability of the quote

That shift plays directly to ServiceNow’s strengths.

Where this matters most

This approach is not universal. It is most powerful in businesses where complexity is real:

• Configurable products

• Product + service bundles

• Field service requirements

• Multi-location deployments

• Dealer or partner channels

• Asset-heavy environments

• Warranty and entitlement complexity

Think:

• Manufacturing

• Industrial equipment

• Telecom

• Medical devices

• Energy and utilities

• Distribution and logistics

• Technology services

In these environments, the quote is not just a document. It is a blueprint for execution.

A better way to position CPQ

The winning narrative going forward is not:

“We help you quote faster.”

It is:

“We help you turn every quote into an operationally executable plan across your business.”

That means:

• No rekeying

• No missing data

• No surprises for fulfillment

• No disconnect between sales and service

• No downstream chaos

Just clean, structured, actionable data flowing from quote to order to service to renewal.

The bottom line

CPQ is moving out of the front office.

It is becoming the front door to enterprise workflow.

And the companies that win will not be the ones that generate quotes the fastest.

They will be the ones that ensure those quotes can actually be delivered, serviced, billed, and expanded without friction.

Faster quotes are good.
Fulfillable, profitable, serviceable quotes are what matter.

That’s the opportunity—and that’s where ServiceNow is aiming.

Last week, Salesforce stood on stage at their TDX developer conference and announced something they called Headless 360. The headline: Salesforce is stripping out the interface. No more dashboards to log into. No more screens to navigate. Every capability in the platform — CRM, service, marketing, commerce — exposed as an API, an MCP tool, or a CLI command. Built so AI agents can access it directly, without a human ever opening a browser.

Marc Benioff called it the most ambitious architectural shift in 27 years.

It’s easy to read that as a developer announcement. A technical footnote for the Salesforce architect crowd.

It’s not. It’s a signal about where all of enterprise software is heading — and for anyone in the CPQ and revenue operations world, there’s an important footnote: the best configuration engine in the space built this way from day one.

What “Headless” Actually Means

The word comes from web architecture. A “headless” system is one where the back-end logic — the data, the rules, the processing — is completely separated from the front-end presentation layer. The “head” is the interface humans look at. Remove it, and what’s left is pure capability: something that does work, responds to inputs, and produces outputs, without requiring a human to navigate it.

For years, headless was mostly a concept for e-commerce platforms. Your product catalog, inventory, and checkout logic running in the back-end, delivered to whatever front-end made sense — a mobile app, a kiosk, a partner portal, a voice assistant.

But the idea is now spreading to every layer of enterprise software. And the reason is agents.

When a human uses software, they need an interface. They need screens, menus, buttons, forms. That’s the entire history of enterprise software design — build a UI that a person can navigate.

When an agent uses software, it doesn’t need any of that. It needs an API. It needs a way to say: get this record, update that field, trigger this workflow, return that result. The interface is overhead. The interface is, in a very real sense, the thing slowing everything down.

Headless architecture is what happens when you design for agents instead of humans.

CPQ Already Knew This

Here’s the thing that doesn’t get said enough in the broader “agentic future” conversation: the CPQ world has been living this problem for years.

Traditional CPQ platforms — including Salesforce CPQ, which is now end-of-sale — were built as managed packages inside CRM. The configuration logic and the quoting interface were tightly coupled. You couldn’t run one without the other. Every customization added code and complexity. Scaling meant adding overhead. And if you wanted to power a partner portal, an e-commerce channel, or a self-service configurator alongside your sales team’s workflow, you were essentially rebuilding the logic from scratch for each surface.

That’s the headed problem. The engine and the interface are glued together. You can’t get to the engine without going through the screen.

Logik was built to solve exactly this. The configuration engine — the logic that validates product rules, enforces dependencies, calculates pricing — sits completely separate from any front-end presentation. You call it via API. It returns a result. It doesn’t care whether a sales rep is on the other end, or a partner portal, or an e-commerce checkout, or — and this is the part that matters now — an AI agent.

That’s why ServiceNow’s acquisition of Logik wasn’t just a CPQ deal. It was an architecture bet. ServiceNow looked at where enterprise software was heading and recognized that a headless configuration engine — one that could power any channel, any workflow, any interface — was foundational infrastructure for an agentic world.

When an AI agent needs to validate whether a product configuration is valid, check pricing against contract terms, and generate a quote without a human navigating through screens, it needs exactly what Logik was designed to provide: a clean API that returns accurate answers fast.

The Implications Are Bigger Than They Sound

Here’s the shift that manufacturers need to internalize: your enterprise software is about to have two kinds of users — humans and agents — and they need completely different things.

Humans need interfaces. Dashboards, exception queues, approval screens, reports. The UI isn’t going away for people.

Agents need APIs. Clean, documented, reliable programmatic access to the capabilities inside your systems. They don’t care what the screen looks like. They care whether they can read a customer record, validate a configuration, check pricing, and push an order — without waiting for a human to click through five screens to do it.

Right now, most manufacturers’ systems are built entirely around the human experience. Every workflow assumes a person is driving. Every process has a screen attached to it. Every approval requires someone to log in, review, and click a button.

That design assumption is about to become a constraint.

If your systems can’t be accessed headlessly — if there’s no clean API layer underneath your CPQ, your ERP, your CRM — then agents can’t work with them autonomously. They’ll need a human in the loop for every step. Not because the human adds judgment value, but because the system requires a human to drive the interface.

That’s not a people problem. That’s an architecture problem.

What This Looks Like in Your Revenue Motion

Think about your quote-to-cash process for a moment.

A deal closes. Someone logs into Salesforce to mark it won. Someone else pulls the quote details, validates the configuration, checks pricing against the contract, routes for approval, creates the order in ERP, and confirms delivery terms with the customer.

Each one of those steps has a screen attached to it. A human navigates to the right place, enters or reviews the right data, and moves the process forward.

Now imagine that same process in a headless, agent-native architecture.

The deal closes. An agent reads the closed-won signal, calls the configuration engine to validate the product setup, checks pricing rules programmatically, routes the one approval that requires genuine human judgment, receives it, creates the order in ERP, and triggers the customer confirmation — without anyone logging in, navigating menus, or clicking through screens.

The human didn’t disappear. They made one decision, on one exception, where their judgment actually mattered.

Every other step was intelligence work. Rules-based. Automatable. Headless.

The outcome — a clean, accurate order flowing through to fulfillment — happened faster, with fewer errors, and without burning your best ops people on screen navigation.

That’s the outcome you’re actually trying to buy. The UI was always just the means of getting there.

The Design Bifurcation

In a world of headless architecture and autonomous agents, design splits into two fundamentally different problems.

Human-facing design is what most of us have always thought about: the dashboards your sales managers review, the exception queues your ops team works, the approval screens where real judgment gets exercised. These still need to be excellent. Clear, fast, actionable. Humans spending time in these interfaces should be spending it on decisions, not navigation.

Agent-facing design is new territory for most organizations. It’s about the API contract: what data is exposed, how it’s structured, what actions are available programmatically, how errors are handled, what guardrails are in place. This is the layer that determines whether an agent can do its job reliably — or whether it gets stuck waiting for a human to intervene on something that shouldn’t require one.

Most organizations have invested almost entirely in human-facing design. The screens look reasonable. The dashboards exist. But the agent-facing layer — clean APIs, documented capabilities, reliable programmatic access to the actual logic — is an afterthought, if it exists at all.

That imbalance is about to become a competitive problem.

ServiceNow CPQ, powered by the Logik engine, is one of the few CPQ platforms on the market where that agent-facing layer was part of the original design intent. The configuration engine was always meant to be called by anything. That’s not a lucky accident — it’s an architecture philosophy that turns out to be exactly right for where enterprise software is heading.

What Manufacturers Should Be Asking

You don’t need to rebuild your entire stack tomorrow. But if you’re doing any systems work in the next 12-18 months — a CPQ implementation, an ERP integration, a Salesforce or ServiceNow build — these questions are worth asking:

Can this system be accessed without a human navigating it? Not “does it have an API” in theory, but: is that API actually documented, maintained, and built to carry real workloads programmatically?

Where are humans currently required in my process — and is it because they add judgment, or because the system requires them? The distinction matters. One is a feature. The other is a bottleneck waiting to be engineered away.

When we configure this system, are we designing for today’s human users, or for the agents that will be working alongside them in two years? A workflow built entirely around a screen-based approval process is going to require rework. A workflow built around clean data states and programmatic triggers will scale in both directions.

The shift to headless architecture isn’t about removing humans from the picture. It’s about making sure humans are only in the picture where they belong — on the judgment decisions that actually require them.

Everything else is intelligence work. And intelligence work, increasingly, shouldn’t require a human to click a button to make it happen.

The Outcome Framing

This is why the outcomes conversation matters so much right now.

When you buy a tool — a CRM, a CPQ platform, an ERP — you’re buying the interface. You’re buying the screens. And then you spend months building workflows that assume humans will navigate those screens to get work done.

When you buy an outcome — quotes generated accurately, orders flowing cleanly, revenue recognized on time — the architecture has to support both human and agent users from the start. The headless layer isn’t an add-on. It’s a design requirement.

Salesforce’s Headless 360 announcement is significant not because Salesforce invented this idea, but because they’re signaling to the entire enterprise software market that agent-first architecture is the direction everything is heading. Logik figured this out years ago. ServiceNow made a $500M bet on it. The platforms that don’t build this layer will become bottlenecks. The businesses that don’t design for it will be stuck with humans doing jobs that systems should handle.

The UI was never the point. The outcome was always the point.

We just needed the rest of the market to catch up to what the best architecture already knew.

Mountain Point is one of a handful of partners with deep ServiceNow CPQ and Salesforce ARM implementation expertise. If you’re evaluating your CPQ architecture — or wondering whether your current setup is ready for an agentic world — that’s exactly the conversation we’re built for.

There’s a person on your team — maybe it’s your RevOps lead, maybe it’s a senior sales ops analyst — who knows your Salesforce instance better than anyone. They’ve been there through three system upgrades, two reorgs, and the CPQ implementation that took eighteen months longer than it should have.

And every single day, they spend a meaningful chunk of their time doing things like:

• Manually pushing quotes through approval workflows that stall on edge cases

• Hunting down why a deal closed in CRM but never made it to ERP

• Re-keying order details that should have flowed automatically

• Untangling pricing exceptions that the system can’t handle but someone promised a customer anyway

This isn’t complexity work. It’s not strategic work. It’s not even good operational work.

It’s gap-filling. Human patch jobs on a process that was never fully finished.

And here’s the thing nobody says out loud: you’ve turned your best people into copilots for a broken system.

The Copilot Trap

The language of AI has given us a useful frame here. A copilot is a tool that makes a skilled person more productive — it assists, suggests, accelerates. The human is still flying the plane.

An autopilot handles the work. The human defines the destination, monitors for exceptions, and intervenes on the things that genuinely require judgment.

Most mid-market manufacturers talk about wanting to “leverage AI” in their revenue operations. What they actually have is something stranger: highly experienced humans acting as the copilot for a manual, rules-based process that should be the system’s job.

Your senior ops person isn’t piloting anything. They’re re-entering data. They’re watching a dashboard refresh. They’re doing the exact things a well-configured system should do on its own.

That’s the rocking horse problem. Lots of motion. No movement.

Intelligence Work vs. Judgment Work

Here’s a distinction worth internalizing: intelligence work follows rules. Complex rules, maybe — but rules. Translating a customer’s configuration into a valid quote. Routing an approval based on margin thresholds. Syncing a closed-won opportunity to your ERP. Checking whether a deal’s pricing falls within contract terms.

Judgment work is different. It requires experience and instinct. Deciding whether to hold firm on a discount request from a strategic account. Knowing when an exception is worth making. Reading the room on a stalled deal.

The uncomfortable truth for most revenue operations teams is that a significant majority of what people spend time on is intelligence work dressed up as judgment work. It feels consequential. It sits on someone’s calendar. It sometimes requires knowing the system well enough to do it correctly.

But it’s still rules. And rules can be automated.

What This Costs You

The cost isn’t just efficiency, though the efficiency case is real. When your ops team is doing intelligence work, they’re not doing judgment work — and judgment work is where they actually create value.

They’re not building better processes. They’re not analyzing where your pipeline breaks down. They’re not working cross-functionally to improve the handoff between sales and finance. They’re not thinking about what your revenue motion needs to look like eighteen months from now.

They’re closing the gap between what your system does and what your business needs.

That gap shouldn’t be a job description. It should be a problem statement.

The Outcome You’re Actually Buying

When Mountain Point works with manufacturers on revenue lifecycle implementations — CPQ, lead-to-cash, quote-to-order, whatever you call the motion in your business — the conversation usually starts with a list of problems to solve.

The conversation that actually matters is different: what should your ops team never have to do manually again?

That’s the outcomes frame. Not “implement CPQ.” Not “integrate Salesforce and ERP.” But: close the books on a deal without anyone touching it who doesn’t need to. Generate a valid, margin-compliant quote without a senior analyst reviewing every exception. Recognize revenue automatically when the conditions are met.

The goal isn’t a better-configured system. The goal is a system that handles the intelligence work so your people can do the judgment work.

That’s the difference between buying a tool and buying an outcome.

The Practical Question

Take fifteen minutes this week and ask your RevOps lead one question: What do you do every day that you shouldn’t have to do?

Don’t frame it as a complaint session. Frame it as a gap analysis. What tasks exist because the system can’t handle them — and what would it take to close those gaps?

The answer will probably be a mix of configuration work, integration work, and some honest conversation about what the process was supposed to do versus what it actually does.

But somewhere in that list is the work that your best people are doing on behalf of a system that should be doing it for them.

That’s your starting point.

Not “how do we add AI to our revenue ops.”

But: “what’s the intelligence work we’re still doing by hand — and what would it mean to finally stop?”

Mountain Point helps companies build revenue operations that close the gap between how their business runs and how their systems work. If your team is spending time on work the system should handle, that’s the conversation we’re built for.

Let's Chat!

For the better part of a decade, “improving the customer experience” meant hiring a UX consultant, redrawing a journey map, or A/B testing a button color. The assumption was always the same: a human being was on the other end, clicking through your website, filling out your form, waiting on hold. Design it better, and they’d feel it.

That assumption is breaking down. Fast.

Shopify merchants can now set up their product catalog once and sell inside a ChatGPT conversation — no separate integration, no custom app, no additional storefront. The buyer didn’t navigate to a website. An AI agent surfaced the product, answered their questions, and completed the transaction inside the conversation they were already having. Shopify and Google co-developed an open standard — the Universal Commerce Protocol — so that agents across platforms can natively complete checkout on a customer’s behalf. Hundreds of millions of ChatGPT users can now shop from Shopify merchants without ever leaving the chat window. That’s not a better checkout experience. That’s a different model entirely. The experience didn’t get redesigned. It got executed by something that never sleeps, never gets impatient, and never forgets what you told it last time.

The B2C proof of concept is already live. B2B is next.

What Shopify demonstrated in retail, agents are now building toward in procurement. Forrester predicts that buyers’ procurement teams will deploy agents capable of scaling negotiation across hundreds of suppliers simultaneously — turning static pricing pages into dynamic, real-time negotiation interfaces. A mid-market manufacturer’s purchasing manager won’t manually compare three vendor quotes and follow up by email. Their agent will evaluate all three, score them against pre-defined criteria, and initiate the next step — potentially before your sales rep has even opened their laptop.

This is where the conversation gets real for revenue leaders. If an AI agent is evaluating your quote response on behalf of the buyer, your 48-hour turnaround and a PDF attachment aren’t a minor inconvenience. They’re a disqualification. AI agents don’t call to clarify missing information or give you the benefit of the doubt on a vague line item. They move to the next supplier with complete, structured, machine-readable data. The experience your buyer has isn’t just shaped by your sales team anymore — it’s shaped by whether your systems can respond to agents at the speed and structure they require.

The scaffolding is being built in real time.

Three things happened in the last few months that, taken together, signal how fast this infrastructure is moving.

Zapier’s CEO announced the open beta of the Zapier SDK on April 7th, calling it the most powerful thing the company has shipped in years. Point your coding agent at it and it gains programmatic access to 8,000+ app integrations — Salesforce, Slack, NetSuite, you name it — without a single OAuth setup. Agents can now do things across your entire software stack through a single, standardized interface. The integration complexity that used to require months of development work is becoming a configuration problem.

Anthropic launched Claude Cowork in January, extending the same agentic architecture that powers Claude Code to everyday knowledge workers. It runs on desktop, works inside your local files and applications, synthesizes information across sources, and completes multi-step tasks without the user managing each step. In March, they added full computer use — Claude can now open apps, fill spreadsheets, export files, and complete workflows autonomously while you’re in a meeting. One demo showed a user running late, messaging Claude from their phone, and Claude exporting a pitch deck as a PDF and attaching it to a meeting invite before they walked in the door. That’s not a productivity feature. That’s a new category of coworker.

What connects all of this — Shopify’s agentic storefronts, Zapier’s SDK, Claude Cowork — is that the tooling for agent-mediated experience is now available to anyone. The barrier isn’t technology anymore. It’s whether your underlying systems are ready to participate.

The infrastructure problem hiding in plain sight.

Here’s the part most companies aren’t talking about yet: the companies that will win in an agent-mediated world aren’t the ones with the best-designed experiences. They’re the ones whose data is clean, their pricing rules are structured, and their systems can respond to an automated request in real time.

For mid-market manufacturers and distributors, this is where the stakes are highest. Your product catalog, your CPQ configuration, your quote-to-cash process — these aren’t back-office concerns. When an AI agent is evaluating suppliers on behalf of a procurement team, your ability to surface accurate pricing, available inventory, and complete product specs automatically is your experience. A CPQ that runs on batch processing and exports to Excel isn’t just slow. It’s architecturally incompatible with how buyers will increasingly be buying.

The companies investing in clean revenue infrastructure today — structured product data, real-time pricing logic, connected quote-to-cash systems — are building the foundation that agents run on. Everyone else is hoping the old way holds long enough to figure it out later.

Design doesn’t disappear. It bifurcates.

None of this means great UX stops mattering. It means the canvas has split — and the highest-leverage design work looks different than it did three years ago.

There are now two distinct surfaces that need to be designed well, and they require completely different thinking. The first is agent-facing: structured data, clean product schemas, machine-readable pricing, brand voice captured in a knowledge base an agent can actually read and act on. Shopify’s agentic storefronts let merchants define exactly how their products, policies, and brand identity appear inside AI conversations. That’s a design problem. It just doesn’t look like a Figma file.

The second surface is where human-facing design gets more important, not less. When routine transactions get handled by agents, what’s left are the high-stakes, high-judgment moments — a complex configuration decision, a contract negotiation, an onboarding experience, a renewal conversation that could go either way. Those touchpoints need to be exceptional precisely because they’re now chosen interactions, not forced ones. The buyer who shows up in person, so to speak, is already past the commodity layer. They’re there because the decision matters. Mediocre UX at that moment is no longer forgivable because “the process is just clunky.” The clunky parts got automated. What remains is a direct reflection of your brand.

The companies that will define this era aren’t choosing between agent-readiness and great design. They’re doing both — and they understand that the two are now inseparable.

What this means right now.

The experience era isn’t ending. It’s being handed off — and bifurcated. Routine interactions are moving to agents. Human-facing moments are becoming rarer and more consequential. And your brand’s ability to show up in an agent-mediated conversation depends entirely on whether the underlying architecture is ready.

Better UX alone won’t save you if your data is a mess. But clean infrastructure without a point of view on the human moments you still own is just plumbing. The companies that win will have both — and they’ll have started building before most of their competitors realized the canvas had changed.

Most companies manage outcomes directly.

Revenue. Pipeline. Retention. Growth.

They set targets, track metrics, and push teams to perform.

But outcomes don’t behave that way.

They’re not controlled.

They’re produced.

Outcomes Are Downstream

Every result in your business is a reflection of how customers experience it.

• Pipeline quality reflects the buying experience

• Win rates reflect the sales experience

• Retention reflects the customer experience

When those experiences improve, outcomes follow.

When they don’t, no amount of internal pressure changes the result.

Where Things Break

Most organizations are not designed around experience.

They’re designed around functions:

• Marketing

• Sales

• Customer Success

• Operations

Each optimized independently.

But customers don’t experience functions.

They experience the gaps between them.

That’s where friction shows up:

• Inconsistent messaging

• Slow handoffs

• Confusing processes

• Delayed value

And that friction shows up later… as missed outcomes.

AI Is Compressing the Gap

AI is accelerating every part of the business:

• Faster outreach

• More content

• More automation

• More interaction

But speed doesn’t fix experience.

It exposes it.

If the experience is fragmented, AI makes it more visible—and more frequent.

If the experience is aligned, AI makes it more effective.

AI doesn’t change the system.

It amplifies it.

What Actually Drives Results

The shift is subtle, but important:

Stop managing outcomes as targets.
Start managing the experiences that produce them.

• How easy is it to engage?

• How consistent is the journey?

• How clear is the value?

• How quickly do customers see results?

These are not soft concepts.

They are the system behind every hard metric.

Closing Thought

You don’t improve outcomes by focusing on outcomes.

You improve outcomes by improving the experiences that produce them.

Because in the end, results aren’t managed.

They’re experienced.

Most organizations agree on outcomes.

Grow revenue. Improve retention. Increase efficiency.

But agreement isn’t the problem.

Execution is.

Because while outcomes are discussed at the top, most of the organization is still operating on activity. And when that happens, even the right strategy breaks down in practice.

Why Outcomes Break Down

There are a few consistent patterns:

• Goals are too high-level to act on

• Teams are measured on activity, not impact

• Marketing, sales, and customer teams operate in silos

• No one clearly owns the outcome

So work expands. Activity increases. But results stay flat.

The Outcome Cascade

Organizations that consistently deliver results do something different. They connect strategy to execution through a clear chain:

Business Outcome → Driver Metrics → Activities → Systems

For example:

• Outcome: Increase net new revenue

• Driver Metrics: Pipeline coverage, win rate, deal velocity

• Activities: Targeting, messaging, sales execution

• Systems: CRM, automation, reporting

If these layers aren’t tightly aligned, teams default back to what’s easy to measure—activity.

And the rocking horse shows up again.

What to Measure (and What to Ignore)

The shift is simple, but not easy:

Move from volume metrics to impact metrics.

• Not emails sent → qualified pipeline generated

• Not meetings booked → opportunities advanced

• Not campaigns launched → revenue influenced

Activity can support outcomes. But it should never be mistaken for one.

Where AI Fits

AI is a force multiplier.

But it multiplies whatever system it’s applied to.

If your operating model is aligned to outcomes, AI accelerates performance.

If it’s not, AI just produces more activity—faster.

More content. More outreach. More analysis.

Same results.

AI should accelerate a defined strategy, not replace one.

Outcomes Are Delivered Through Experiences

Outcomes don’t happen in isolation.

They are the result of how customers experience your business across every interaction—marketing, sales, onboarding, delivery, and support.

• Pipeline quality is shaped by the buying experience

• Win rates are influenced by the sales experience

• Retention is driven by the customer experience

When experiences are fragmented, outcomes suffer.

When experiences are intentional and aligned, outcomes compound.

Many organizations try to improve results by optimizing internal activity instead of improving the external experience that drives those results.

The Role of Advisory

This is where most organizations get stuck.

They don’t need more effort. They need alignment.

• Translating business outcomes into measurable drivers

• Aligning teams around shared metrics

• Identifying what to stop doing

• Ensuring systems support outcomes—not just activity

• Designing experiences that consistently produce results

That’s the difference between motion and progress.

Closing Thought

Most organizations don’t fall short because they lack effort.

They fall short because their effort isn’t connected to outcomes.

The companies that win aren’t the busiest.

They’re the most aligned—around the outcomes they want to drive and the experiences that deliver them.

That’s going to be our focus / theme next month, “Experiences!”