“We sent the RFP to engineering. They’ll get back to us next week.”

I’ve heard that sentence in more reviews than I can count. The quote eventually arrives. It’s correct. It’s also late, and the customer has gone quiet. Not because we lacked expertise, but because our process still depends on a few people doing mental gymnastics that a system should do.

Here’s the pattern I see: teams throw either a heavy CPQ at the problem and slow sales down, or they try AI-first and get speed without guarantees. Both miss the point.

Stop Mixing Understanding and Truth

The problem isn’t that CPQ is too complicated or that AI is too risky. The problem is that most orgs try to make one layer do two jobs: understand messy human input and decide what is technically valid. That’s where the friction and errors live.

The scalable answer is a radical separation of concerns:

  • AI interprets intent - it reads RFPs, emails, and notes, and turns them into structured requirements.
  • Symbolic logic decides truth - a formal rule set constrains what can be configured, priced, and delivered.

When you split these jobs, you get speed and control at the same time. AI stops guessing about constraints, and your rules stop pretending to understand language. The result is output that is correct by construction.

Speed without truth is theater.

Industry messaging leans hard into AI-driven recommendations. As Salesforce puts it, modern quoting platforms promise automation plus AI guidance to stay competitive. That’s useful for suggestions and workflow. It is not a safety net for product correctness. Analysts call CPQ essential for accuracy and velocity - and they’re right - but that accuracy comes from explicit logic, not probabilistic answers.

How the Dual-System CPQ Works

Think of your sales engine as two systems working in sequence and in dialogue:

1) Intent capture. AI reads free text and maps it to your product vocabulary. It doesn’t decide feasibility. It simply extracts what the customer is asking for - capacity, standards, constraints, must-haves, nice-to-haves - and normalizes it into attributes you recognize.

2) Product truth. A rule-based engine - constraints, compatibility, derivations, pricing logic - takes those attributes and computes a valid solution space. It selects a configuration that is buildable, priced, and deliverable. No expert intervention required.

Two important details make this work in the real world:

Explainability by default. Sellers don’t just need an answer - they need to understand why it’s right. Every decision should be traceable: this standard forces that option, this dimension knocks out that variant, this pricing rule applies because of these inputs. If the system can’t show its reasoning, sales will go around it.

Tests as guardrails. Treat product logic like code. Maintain a regression suite of real configurations, edge cases, and deals you never want to break. Every change runs against this suite. You don’t need perfect coverage on day one - you need a habit of catching mistakes before the field does.

Here are the rules of thumb I use on projects:

Rule 1: Separate intent capture from validation. Don’t let the same component parse language and enforce constraints. Keep them decoupled so you can improve each independently. Example: let AI derive “IEC 61439 compliance, 800A busbar, IP54” while the solver handles what that means for enclosure size, cooling, and cost.

Rule 2: Never let AI own feasibility. AI can suggest, summarize, and classify. Feasibility is a contract. You want explicit rules for that. If an LLM proposes an option, it should still pass through the constraint engine like everything else.

Rule 3: Make logic composable and testable. Small rules that compose beat big rules that try to be clever. If a rule needs a paragraph to explain, split it. Keep derivations separate from constraints. Price logic separate from configuration logic. Then test them together.

Rule 4: Show the why, not just the what. Include inline explanations and drill-downs. When a choice is forced, say why in one sentence. When a price changes, show the input that triggered it.

Rule 5: Govern change with real usage. Measure which rules trigger most often and which explanations get clicked. That tells you where friction lives and where simplification pays off.

The Blender Anti-Pattern

This is the failure mode I see most: teams blend AI interpretation and rules into one layer. Prompts call rules, rules call prompts, and nobody can explain how a decision happened. It feels magical in a demo and brittle in production. Don’t build a blender. Build a pipeline.

“Correct by construction” isn’t a slogan. It’s an architectural decision.

Why this matters now: AI is finally good at turning messy language into structured intent at scale. Constraint engines have been excellent at truth for years. Put them together properly and you get a step change in quoting speed - without losing control.

Let’s put this in context with the market narrative. Sales vendors talk about automation and AI recommendations as must-haves to stay competitive. Yes - recommendations help with guidance, cross-sell, and next steps. But the contract you sign is anchored in product truth. If recommendations are not constrained by formal logic, they scale guesswork instead of expertise.

In practice, here’s what a healthy dual-system flow looks like:

  • AI ingests the RFP and highlights conflicting requirements early - “specified voltage and chosen motor package are inconsistent.”
  • The logic engine proposes a compliant configuration set and flags trade-offs - “Option B meets IP rating but reduces throughput by 5%.”
  • The seller sees both the decision and the reason, chooses between valid options, and generates a quote that ops can live with.

The win isn’t just fewer errors. It’s cycle time. Every back-and-forth you remove is compound interest. Shorter loops mean deals die less often. Pricing improves faster because feedback is in the system, not in someone’s inbox.

Adoption is the only metric that matters.

If sellers don’t trust the system, they’ll go back to spreadsheets and calls to engineering. So measure adoption the way you measure revenue. Daily active users. Quotes started and finished in system. Time from requirements to first valid proposal. Time to revise. If those move, everything else follows.

Start Small, Prove It Fast

You don’t need a 12-month program to try this. You need a small surface area and a clear test.

Pick one product family and one buyer scenario. For example: mid-range compressor packages for OEMs in Europe. Write down the top 20 real requirements that show up in RFPs. Map them to attributes. This is your intent vocabulary.

Build the thin logic spine. Encode the non-negotiables first - standards, safety, compatibility, power, and envelope constraints. Add derived attributes that sellers always forget. Keep it minimal and verifiable.

Wire the two together. Let AI populate the attribute sheet from an email or RFP. Let the logic engine compute valid options and a default recommendation. Show the explanation footnotes in the UI. Keep humans in control of the final selection.

Install a test harness. Capture 30 real deals - wins and losses. For each, store inputs, chosen config, and price. Turn them into tests the engine must pass after every change. Add three edge cases the field worries about. That’s your safety net.

Make it visible. Share a weekly adoption snapshot and two quotes worth reusing:

  • “This is the first version I can send without calling engineering.”
  • “If the system catches my mistake before the customer does, I’m in.”

As usage grows, extend the logic, not the UI. Resist the urge to pack every exception into rules. When an outlier appears, name it, price it, and park it outside the standard flow until it becomes common. Protect the core from rule bloat.

One more thing about pricing. Don’t wait for perfect. Launch with rules that are fair, explainable, and easy to update. Use the system to learn - which discounts get approved, which segments require premiums, which options drive margin. Pricing improves fastest when the conversation happens inside the same rails that produce the quote.

I’m not against AI-driven recommendations. I’m against letting them decide feasibility. As one industry write-up put it, CPQ exists to simplify complexity and improve accuracy so sales can move faster and customers get a better experience. That’s the job. The way you deliver it, at scale, is to let AI understand and let logic decide.

The fastest quoting process is the one sales trusts.