Say this out loud: I need a fire truck for central Copenhagen. In five minutes, a conversational assistant asks ten sharp questions, reasons about payload, urban driving, and cyclist-heavy streets, and returns not just a spec, but a primary recommendation, a lower-cost alternative, and a five-year TCO. No Excel. No tribal handoffs. Just a defensible outcome you can walk into a customer meeting with.

From fuzzy input to a field-ready spec

In the workshop, we started with a structured Word document: modules, variants, SKUs, short and long descriptions, scenario notes, prices, and a few TCO factors. We paired that with a clear prompt that cast an LLM as a sales advisor. Then we gave it a simple intent: configure a municipal fire truck for Copenhagen.

The assistant didn’t follow a canned script. It asked ten dynamic questions based on prior answers. It narrowed on duty cycle and geography, favored a day cab over a sleeper, suggested a 6x4 for tank weight and off-road access, chose an automatic for stop-start, and recommended safety systems for dense urban traffic and blind-spot risk. It included PTO for pumps, declined aero packages and couplings that didn’t fit the use case, and proposed a retarder to cut brake wear and long-run maintenance cost.

Then it did the part most CPQ demos skip: it produced a second, lower-cost baseline and calculated five-year TCO deltas. The higher-spec build invested in safety and braking; the lighter build saved capex but paid it back in service and downtime. Not perfect. But intelligible. Fast. And close enough to show why this pattern matters.

When intent capture becomes a conversation, the system stops feeling like a form and starts acting like a colleague.

This isn’t just faster configuration

Most people see that demo and think: great, AI can configure products. That’s the wrong lesson. The change is earlier and more important: we can finally capture intent in the words the buyer uses, not the fields our systems expect.

Classic CPQ assumes the user already knows what they want. Real sales doesn’t work like that. It starts upstream: scenarios, trade-offs, risks, and what good looks like. The LLM layer excels at this conversational front-end — asking better questions, explaining options, and translating messy input into structured signals. Then the rules engine should do what it’s always done well: guarantee what’s valid, priceable, and buildable.

The conversation isn’t replacing logic. It’s feeding it.

Why this moment is different

We’ve tried to make guided selling friendly before. Why is this actually working now?

Two reasons. First, modern LLMs are good enough at scenario talk to make the first five minutes feel like help, not friction. Second, we don’t have to choose between flexibility and correctness anymore if we design for both.

In our own work, we benchmark new model releases weekly and switch when quality moves. Right now, Opus 4.6 is our pick for this class of reasoning tasks. Context windows are growing, but we still see better outcomes when we give the model focused, sales-relevant content instead of a data dump. Ten thousand tokens of the right product narrative beat a million tokens of noise every day.

There’s a catch: LLMs are probabilistic. They can be confident and wrong. That’s why the architecture matters as much as the demo.

The working pattern: fuzzy in, explicit out

The pattern that holds up in the field looks like this:

  • Sales-ready knowledge base: Modules, variants, SKUs, prices, short and long narratives, pros/cons, scenarios, and when-not-to-use guidance. Enough context to reason, not a dump of everything you have.
  • Conversational capture: A chat or guided form that asks 8–12 high-value questions, adapts as it learns, and explains trade-offs in plain language.
  • Deterministic guardrails: A constraints layer that forbids what must never happen and explains why. The LLM can propose; the rules decide.
  • Computation and transparency: Embedded TCO math, price rollups, and simple justification for each choice. If the system can’t show its work, it won’t be trusted.
  • Instant proposal surface: A shareable page that renders the build, the alternative baseline, and the five-year cost view in a way a buyer can react to immediately.

Notice what’s missing: we don’t ask the LLM to be the source of truth. We ask it to be the explainer and the synthesizer. The truth still lives in explicit logic and prices you can test.

What made the fire truck demo land

Three ingredients made that session feel different to people who have sat through a decade of CPQ demos:

First, the questions felt human. It didn’t ask for a part number. It asked where the vehicle would run, how often, how tight the streets are, how critical off-road access is, and how the city thinks about emissions. The model then mapped those answers to the right modules and variants.

Second, it explained itself. Choosing a retarder wasn’t a black box. It tied the choice to brake wear and safety in stop-start city driving and showed how the five-year cost shifted. Confidence comes from seeing why, not just seeing what.

Third, it created an alternative path with less cost and less protection. That matters. Buyers want an A/B they can defend internally. So do sales leaders.

Speed without explanation erodes trust. Explanation without speed erodes pipeline. You need both in the same flow.

What this means for your stack, this quarter

If you want this to work outside a workshop, the upstream work isn’t glamorous but it moves the needle fast:

  • Refactor one top-5 selling path into a sales-ready knowledge base: 12–20 modules, 80–150 variants, each with a short and long description, scenarios, and when-not-to-use notes. Keep it readable. Remove engineering-only detail.
  • Codify 10 non-negotiable constraints that must never break. Point them at explanations users can read.
  • Wire a basic TCO calculator for that path. Use round numbers. Improve later.
  • Run the conversation layer on top and time the full flow: first question to shareable proposal. If it’s over five minutes, find the slow step and simplify it.

We’ve seen teams go from nothing to a functioning pilot in a week when they limit scope and focus on one real path. The old trade-off between speed and trust starts to loosen when the LLM handles intent and the rules handle correctness.

The compounding advantage

Two quiet effects kick in once this approach ships:

Usage clarifies pricing. When the system produces alternatives and TCO every time, you stop waiting for perfect price logic and start collecting evidence about how choices move deals. Progress beats theory.

Governance shifts from meetings to tests. When rules explain themselves and proposals are inspectable, change control stops being a calendar exercise and starts being a set of small, safe merges. If a change still needs a project plan, your field will route around it.

And one more: buyer enablement gets real. The same five-minute path that helps a rep can help a partner or a customer explore safely on their own. That’s not a chatbot on your site. That’s a quoting surface that teaches while it sells.

I’ve worked with constraint-based configuration since 2000. I still like rules for what rules are good at. I also like that I can now sit with a sales team, type “Copenhagen fire truck,” and have a live conversation that ends with a spec they understand and a cost curve they can defend. The system isn’t the hero. The result is.

If a five-minute, explainable conversation can produce a spec, an alternative, and a five-year cost story, what exactly are you still waiting to model?