Why your CPQ feels slower the more you invest

You've seen this movie. The rollout is live, the demo looked great, and then reality hits. A new option from engineering lands on a Friday. Sales needs it on Monday. IT gives you a two-week release window. Meanwhile, someone dusts off an old Excel, because the deal won't wait.

When I hear "we just need one more integration" or "it’s a training problem," I know what’s really going on. The monolith is dictating your change speed. Not the business.

CPQ doesn’t fail loudly. It fails quietly - through workarounds.

I've worked inside and around CPQ platforms since 2000. The hard part has never been clicks and buttons. It’s the tangle of product rules, pricing logic, approvals, and documents locked together so tightly that a small change requires a ceremony.

The hidden cost of monoliths in CPQ

Teams think the problem is feature gaps or UI friction. The real problem is the architecture. When configuration, pricing, approvals, and document logic live in one big application, three things happen:

  • Change coupling: You can't update pricing without retesting configuration and document generation.
  • Release drag: Every release tries to be a mini project. Risk rises, so cadence slows.
  • Hero dependency: Knowledge concentrates in a few experts. When they leave, velocity leaves with them.

According to Gartner, the shift to composable applications built from packaged business capabilities is how enterprises break this pattern. In CPQ terms, that means treating configuration, pricing, quoting, and documents as separate, contract-driven services that can evolve independently - but still work as one.

Rules are not the enemy - brittle rules are.

CPQ is not about automation - it’s about correctness. If the logic that makes quotes correct is welded to a release train, sales will route around it. Adoption is the only metric that matters.

What composable CPQ actually looks like

Composable CPQ isn’t a buzzword. It’s a set of boundaries and behaviors you can point to:

  • Configuration service: Given customer intent, it validates options and produces a complete, buildable structure. It explains itself.
  • Pricing service: Given a valid structure and context, it returns list price, costs, discounts, and guardrails. It version-controls strategies.
  • Quoting service: It assembles the offer, tracks states, and locks approved versions immutably.
  • Document service: It renders what's approved - not what’s current - so audits are clean.
  • Approvals service: It evaluates policy, not email threads, and logs the why.

Each one is API-first. Contracts are explicit. They publish events when something meaningful happens - quote created, configuration changed, price locked, approval granted. Other services react. Nothing needs to know everything.

If you work in a CRM like Salesforce or Microsoft Dynamics, this is not an all-or-nothing rewrite. Think of the CRM as the orchestrator and front door. The CPQ capabilities sit behind APIs that the CRM calls. MACH Alliance principles - microservices, API-first, cloud, headless - apply neatly here. The point is not tools. It’s decoupling your rate of change from one application’s release cycle.

Why this moment is different

We’ve wanted this for a decade. Now it’s finally practical.

  • APIs and events are table stakes: Most enterprise stacks accept contract-first integration and event buses as normal, not exotic.
  • Pricing and configuration engines are mature: You can expose them as services with test suites and performance profiles, not just embedded features.
  • AI depends on logic: Assistants can draft, summarize, and guide, but they need clear constraints. With composable services, AI can ask the configuration service for valid options and the pricing service for guardrails - instead of guessing.
  • Composable thinking has an enterprise language: Gartner’s composable applications and packaged business capabilities give you a governance vocabulary your CIO recognizes.

AI does not replace logic - it depends on it.

Design rules that keep you fast

Here are the rules I use when moving clients from monoliths to composable CPQ.

  • Split decide from describe: A configuration or pricing service decides. The quoting service describes the offer and state. Example: pricing service says minimum margin is 18 percent; quoting service records a 17.5 percent request and asks approvals.
  • Contracts over screens: Design API contracts first, then design UI. If a capability can’t be exercised by API, it isn’t a capability - it’s a demo.
  • Version everything that affects the deal: Rules, price lists, cost tables, approval policies. A quote must be reproducible from its components.
  • Events define your backbone: Publish business events with intent - not CRUD noise. QuoteVersionApproved is better than QuoteUpdated. Consumers decide how to react.
  • Make explainability a requirement: Every decisioning service must be able to answer why. If sales can’t explain it to a customer, they won’t trust it.

Anti-pattern: the facade-first "composable"

Wrapping a monolith with an API gateway and calling it composable is lipstick on a release train. If configuration, pricing, and approvals still ship together, you’ve only moved the bottleneck. You’ll feel faster for one quarter, then slow again.

The compounding advantage

Teams that go composable don’t just ship changes faster. They learn faster. They can A/B a discount guardrail in one market without risking another. They can swap a costing method without touching the UI. They can add a new option and have it priced, approved, and documented the same day.

Meanwhile, monoliths don’t explode. They just drift. Adoption slips. Workarounds grow. Audits get messy. The cost isn’t visible until a big deal misses the quarter because a basic option needed a release.

Every rule you add is a tax on future change.

This is why governance matters. Governance isn’t meetings. It’s clear ownership, safe change paths, and fast feedback loops. If a simple change still needs a project plan, the field will route around the system.

A practical path without a big rewrite

You don’t need a greenfield build. Start with one capability that hurts today.

  • Externalize pricing first: Pull price and discounting into a dedicated service with versioned strategies and a test suite. Keep the current UI. Prove you can change prices without a release.
  • Event-enable quoting: When quotes change state, publish events. Drive documents and notifications from events, not page buttons. This creates traceability.
  • Introduce explainability: Add a simple "Why" endpoint to your configuration or pricing service. Include rule references and inputs. Train sales to use it in customer calls.

Set operating rules around it: SLAs for each service, contract tests on every release, and a weekly change cadence. Make ownership explicit. Pricing owns the pricing service. Engineering owns product rules. Sales operations owns quoting states and documents. IT owns the platform and quality gates.

When that works, peel another capability. Approvals. Then documents. Then configuration. Each peel should reduce coupling and increase change speed. Measure time-to-change, not just cycle time. That’s the adoption lever.

What this unlocks for AI and sales

With composable CPQ, AI can be an expert’s apprentice instead of a fluent guesser. It can propose configurations by calling the configuration service, check margin with the pricing service, and assemble a customer-friendly summary that legal can trust. You still fly the plane - you just stop flying it manually.

And for sales, the experience gets calmer. Fewer dead ends. Faster updates. Clear reasons. The system helps them think, not just click.

Adoption is the only metric that matters.

The shift from monolith to composable is not a rebuild. It’s a decision to separate what must be correct from what must be fast - and design so both can be true at once.

If Excel is still the fastest path to a correct quote in your team, you don’t have a speed problem. You have an architecture problem.