Half the sales engineers I talk to are quietly using ChatGPT to configure quotes. They don’t tell their VP. They don’t tell engineering. They paste a spec, ask for a recommendation, and move on with their day.

Last month, in a workshop, a senior SE showed me a proposal draft that “saved the deal.” The first draft came from ChatGPT. It read well. It also picked a motor that would have tripped protection the moment it started. Fluent. Wrong. Risk disguised as speed.

That’s the uncomfortable truth: the shadow CPQ already exists. It’s just hallucinating.

The Shadow CPQ is a design spec, not a disciplinary issue

The default reaction is to clamp down. Send a memo. Block the site. Remind the team that unauthorized tools are forbidden.

Here’s the real problem: your official CPQ is slow and rigid, and your team is telling you that by routing around it. They don’t want to rebel. They want a conversational interface that helps them think in customer language and move fast, without calling three experts and waiting for approvals. The so-called bad behavior is actually valuable user research.

CPQ is not about automation. It’s about correctness.

If a system can’t keep up with the conversation, the field will improvise. Governance that still needs a project plan breeds workarounds. People are choosing speed over safety because your current tool makes them choose. That’s on the system design, not on the users.

So don’t ban the shadow CPQ. Study it. It’s telling you exactly what to build: a fast, conversational front end with a constraint layer that guarantees only buildable, priceable, and deliverable outcomes. Speed and safety in one move.

Principles for a CPQ your team will actually use

Three principles have held up across the programs I’ve led since 2000, from presales at Tacton to enterprise rollouts:

1) AI does not replace logic. It depends on it. Left alone, AI produces fluent guesses. On top of explicit, testable rules, it becomes a reasoning assistant. Put it on rails.

2) Explainability is trust. Salespeople don’t just need an answer. They need to show their customer why it’s correct. If the system cannot explain itself, adoption will always stall. Explanations beat edicts.

3) Adoption is the only metric that matters. If your best reps won’t use it mid-call, the architecture failed. Build for the moment of use, not the demo.

If the system cannot explain itself, it will never be trusted.

The two-layer system that gives you speed and safety

The future of quoting is not AI or rules. It’s both, wired together with intent. Think two layers:

Layer 1: The Constraint Layer (Logic Engine)
Your existing, trusted product and pricing logic lives here. That means your configuration constraints, compatibility rules, BOM rules, pricing policies, region codes, and test suites. This is the source of truth. It should be deterministic, explicit, versioned, and callable. In many teams I work with, this is Tacton’s model plus a pricing engine and a thin service that exposes valid options, explanations, and variant identifiers. This layer answers questions like “Given these customer requirements, what configurations are valid?” and “Why is Option A invalid?”

Layer 2: The Conversational Interface
An AI front-end that speaks human. It takes messy input — “ATEX Zone 2, 480V, must fit a 900mm frame, prefer low noise” — and translates it into queries against the Constraint Layer. It doesn’t invent BOMs. It asks for them. It not only returns a valid configuration, price, and variant ID, but also explains the trade-offs in plain language. Two reps asking the same question get the same underlying answer, because the logic is centralized. Consistency restored.

Here’s the mechanism in practice:

  • The SE writes: “Customer has 480V, Zone 2, needs 800–900mm frame, targets 65 dB. What packages are valid under our EMEA policy?”
  • The Conversational Interface parses those intents and calls the Constraint Layer’s API: validate(requirements), getValidOptions(), price(config, region=EMEA).
  • The Constraint Layer returns a set of valid configs, variant IDs, audit explanations, and price ranges based on explicit rules.
  • The interface composes a response: recommended option, alternates, what changed to meet noise target, and a clear “why” pulled from rule explanations. It cites the variant ID you can hand to ERP. No magic. Just logic, rendered conversationally.

Two objections always show up. First: “Won’t the AI be accurate enough soon?” Accuracy without guarantees is still a guess. In CPQ, a 95% correct engine is a 5% revenue and trust leak. Second: “Isn’t this slower than just asking ChatGPT?” In real teams, once the Constraint Layer is callable, the response is near-instant — and you don’t spend hours reworking wrong quotes. Fast and correct beats fast and wrong.

The winning pattern is hybrid: a brain that speaks human, riding on rails that never lie.

The two-layer architecture and what to change this quarter

Don’t redesign the world. Wire the pieces you already have.

Expose the logic. If your configuration and pricing logic is trapped inside a UI, liberate it. Create services for: validate(requirements), enumerate(options under constraints), price(config, region), explain(rule hit), and return variant IDs. Treat this as a product with versioning and tests.

Make explanations first-class. For every invalid choice, return “why.” For every chosen option, return “because.” Store the rule reference. Your Conversational Interface will use these to build trustable answers.

Instrument for adoption. Log intents, response times, rule hits, and rework. The dashboard you want is simple: time-to-first-valid-configuration, rework rate, explainability coverage, and quotes that reach ERP without manual fixing. If these numbers improve, you’re winning.

Pilot with real deals. Pick three SEs who already use shadow CPQ. Feed their common intents into the Conversational Interface. Keep the scope narrow: top 10 requirements patterns, one region, one product line. Shipping value in a week beats planning a harbor for a year.

Set guardrails. Limit the interface to actions the Constraint Layer can verify. If the AI can’t find a valid option, it should ask clarifying questions or escalate, not guess. Boring is good when money and reputation are on the line.

Govern like you plan to scale. Assign ownership for rules, API, and prompts. Changes flow to tests, then to pilot, then to production. No heroics. No tribal knowledge. As I tell teams: pave the road so anyone can drive it.

I’ve watched organizations stall for months waiting for “perfect pricing” before they expose any logic to the field. Pricing gets better through use, feedback, and transparency — not waiting. Launch with what’s reliable, collect data, and tune. Progress beats perfection, every time.

Adoption is the only metric that matters.

I started my career in technical sales and spent years inside Tacton implementations. The projects that survived market changes shared the same DNA: explicit rules, explainable outcomes, and tools the field actually wanted to open during a call. Not pretty slideware. Working rails.

You already have the raw material — product rules, price policies, and a sales team hungry for speed. Give the shadow CPQ a safe backbone and it becomes an asset instead of a liability.

Your shadow CPQ is not the enemy. It’s your spec.

Give it a body built from rules and a brain you can trust.