The Cost No One Booked But Everyone Pays

A customer says: "We want it robust, but not over-engineered. Probably the medium size. Last time we had issues in winter." Your best salesperson nods, translates that into a torque class, a gasket upgrade, and one SKU out of five. It looks casual. It took 20 years to learn.

Here is the uncomfortable truth: your CPQ only wakes up after that translation is done. We have automated the part that follows. We left the most valuable part in people’s heads.

I see the cost everywhere. New hires take months to make confident choices in front of a customer. Performance gaps look like “talent,” but they’re actually translation gaps. CPQ projects stall because no one writes down the bridge between buyer language and configuration inputs. We keep modeling products while the actual job is modeling conversations.

We called it configuration for 30 years. The work has always been translation.

Where CPQ Actually Starts (and Why It Feels Late)

Configuration is deterministic. Once “5,000 liters, four axles, foam injection” reaches the solver, the system shines. According to author Patrik Skjelfoss, Gartner refers to Tacton as “the strongest constraint-solving engine for complex configure-to-order products.” That power is real and proven in the field.

But customers do not speak solver. They speak context: environment, risk, constraints, fears. The translation step transforms context into structured input. That step is undocumented, variable by rep, and slow to teach. So your CPQ is fast where the sales motion is slowest and silent where the sales motion needs the most help.

This also explains a persistent pain for mixed catalogs. Highly specialized CPQ shines for complex, engineered products, but feels heavy for simple lines. As one review on cpq.se put it, “If you need to sell simple, non-configurable SKUs—like a standard spare part or a recurring service contract—the system can feel like using a sledgehammer to hang a picture frame.” The problem appears to be tool mismatch. Underneath, it’s actually a translation mismatch: we have no pre-configuration layer to route the buyer’s language to the right path—simple cart, guided bundle, or deep constraint solve.

Why This Moment Is Different

For two decades, the translation lived only in heads, decks, and tribal phrases. You could not automate it. You could only hire it, shadow it, and hope it stuck.

That changed when language models learned to operate over your product knowledge with guardrails. Not to replace the solver, but to do the messy front half: interpret the buyer’s words, recall relevant constraints, weigh trade-offs, and present a credible starting point. Think of it as a bilingual layer: customer language on one side, configuration language on the other.

The pattern mirrors what happened in human translation. When the cost of translation collapsed, people did more of it in more places. In CPQ, when the cost of modeling conversations collapses, you model more of them—across your long tail, your aftermarket, your service bundles, and the “we never put this in CPQ” products living in spreadsheets.

A Practical Architecture For The Translation Layer

Keep the system as the enabler, not the hero. The right design is simple:

  • Retrieval layer: A living corpus of product facts, constraints, option rationales, objection handling, and “when not” guidance for each variant. This is your source of truth for the conversation, not just the configuration.
  • Translation engine: A language model that turns vague need statements into structured intents, candidate variants, and rationales. Swappable, because the model landscape changes monthly.
  • Constraint solver: The enforcement layer. It validates and prices. It can be built-in or your existing CPQ (Tacton, Configit, etc.). The translation engine never sets price or violates constraints.

That separation resolves the old trade-off. The assistant can be brilliant about conversation and still be boringly correct about configuration and price. You’re not betting your margins on a model. You’re finally putting the model to work where people burn the most time—interpreting the ask and making a sane first choice.

Let the system be fluent at conversation and strict about correctness.

What Breaks Without Translation

When translation is manual, your top rep is the system. Everything cascades from that fact:

  • Ramp delays: New hires learn by osmosis. They over-ask engineering and under-qualify customers. You pay with stalled deals and bloated solutioning calls.
  • Adoption drift: Reps default to spreadsheets whenever the official path is slower to a credible quote. Shadow quoting grows. The CPQ becomes a late-stage validator, not a thinking tool.
  • Modeling overkill: Teams push for 100 percent product coverage because the system isn’t helpful until it’s “complete.” Projects bloat. The real problem—no early-stage guidance—remains unsolved.

Notice what does not collapse. Your CPQ or ERP isn’t “wrong.” Your people aren’t uncoachable. The architecture is incomplete. You have a solver. You do not have the bridge that feeds it.

Mixed Catalogs Need Triage Before Configuration

Most manufacturers live in two worlds at once: complex engineered systems and simple parts or services. A single monolithic path forces both through the same gate and frustrates everyone. The answer is not another tool for every line. It’s triage at the translation layer.

In practice, that looks like three light paths:

  • Simple spend: Translate the intent to a handful of SKUs or a cart. No solver needed. Fast checkout or quick quote.
  • Guided bundles: For modular offers where a few big choices matter, present curated bundles with rationale. Validate with the solver when needed.
  • Deep configuration: When constraints, sizing, or dependencies dominate, route the interaction into your CPQ and let the solver do its work.

The front door is a conversation. The back office is still your single source of truth. The gain is not theoretical. It removes clicks, meetings, and back-and-forth that add zero value to the customer and all the cost to you.

What To Change This Quarter

If you buy the premise, make one small, concrete shift. Don’t start with a platform swap. Start with content and flow.

  • Map your three most common buyer statements to the first decisions your reps actually make. Write those decisions down with “why” and “when not.”
  • Rewrite variant descriptions to include a “when not” sentence. That alone sharpens any recommendation—human or machine.
  • Instrument the reasons prices move on your top paths. If a customer goes from A to B, capture and show the cause. Explanation builds trust faster than UI polish.
  • Pilot a translation assist on one product line that lives in Excel today. Keep the solver in the loop. Measure time-to-first-credible-quote and handoff quality.
  • Split your catalog intake into simple, guided, and deep. Route customers and reps accordingly. Even a manual triage script will expose where automation pays off.

The goal is not to automate the conversation out of selling. It is to model the conversation so every rep can start strong and your CPQ finally starts early enough to matter.

If the field doesn’t use it in week one, it’s not the system they need. It’s the path they don’t have.

We have spent 30 years perfecting configuration. We were not wrong to do so. But we mistook the second half of the job for the whole job. The most expensive, invisible IP in your company is the way your best people translate a messy ask into a credible starting point. Capture that once, and you stop paying for it on every deal.

So, are you still optimizing the solver while the real work happens off to the side—or will you finally make translation a first-class part of your CPQ?