The dream Tacton described is real
I listened to Klaus Andersen and Nils Olsson on Industrial Talk and nodded the whole way. A buyer tells you what outcome they want, a constraint-based configurator reasons about the options, and a correct quote appears that sales and engineering both trust. Faster quotes. Fewer errors. Happier customers. That is the dream.
They called it a buyer-centric smart factory. I like that phrase. It captures what good CPQ feels like when it’s working. Buyers move forward without waiting. Sales stops guessing. Engineering stops cleaning up mistakes. Everyone breathes easier.
Here’s the part you only learn after living in these systems for a couple of decades: the software is an engine. It still needs tracks.
CPQ is not about automation - it’s about correctness.
The problem we all misdiagnose
The common story is simple. Buy a powerful CPQ like Tacton, connect it to CRM and ERP, and watch complexity melt. I’ve been called into too many programs that started there and stalled. Not because the software lacked features. Because the company lacked a single, explicit, governed representation of the product and how it is sold.
The podcast touched the key point without lingering on it. Nils talked about using AI on unstructured data, then feeding a deterministic, constraint-based engine. That sentence is the whole story. AI can help you gather and draft. The engine can prove what’s valid. But something still has to be true. That something is your product knowledge, structured and owned.
AI does not replace logic - it depends on it.
I remember a rollout at a global med-tech where we were stuck in review loops. Sales wanted speed. Engineering wanted safety. We earned trust the week we could show, in the tool, why a configuration was valid and which rules enforced it. The arguments stopped. The quoting started. Trust is the unlock.
What actually drives value
Tacton’s value props are real. Higher win rates. Less engineering rework. Quotes that don’t boomerang with penalties. But those are not automatic features you switch on. They are outcomes of governance.
You only get cycle time back when engineers trust the logic enough to stop checking every quote by hand. You only get margin discipline when pricing rules are visible and testable, not tribal. You only get production flow when sales config, configuration lifecycle management, and production config line up on the same truth. Klaus called it a triangle. If the core product knowledge is flawed, that triangle collapses. Beautiful UI, broken results.
If the system cannot explain itself, it will never be trusted.
The rules that make it work
Rule 1: Model intent first, options second. Define what the customer expresses in their words. Then map that to product structure. Example: “airflow and noise class” before “fan dimension and blade count.” If you invert it, adoption will suffer because sales will feel like they are speaking engineering, not customer.
Rule 2: Make the logic explainable. Every constraint should be readable and traceable. If you cannot show a salesperson which three rules forced that motor upgrade, they will call engineering anyway. Build explainability into the UI and into your test suite.
Rule 3: Small, composable rules beat big clever ones. The anti-pattern is the wizard-in-a-box rule set that “just knows” everything. It looks smart until you change one option and 14 side effects explode. Write smaller constraints that capture single truths. Name them well. Version them. Test them.
Rule 4: Separate product truth from market policy. What can be built is not the same as what should be offered today. Keep engineering feasibility in one layer and market constraints like lead time, regional availability, and price policy in another. This is where CLM earns its keep.
Rule 5: Treat pricing as a learning system. Perfect pricing is a myth. Launch with a clean structure and solid guardrails, then improve through use. Your first goal is consistent logic and transparency. Fine-tuning comes from feedback, not meetings.
Rules are not the enemy - brittle rules are.
Start here this quarter
1) Establish ownership of configuration truth. Name a single accountable owner for the constraint model. Give them a cross-functional council that can decide, not discuss. Put change control around rules the same way you do around CAD or ERP. If change still needs a project plan, sales will route around you.
2) Build a test suite before you build the model. List 30-50 canonical configurations across your top product families. Include edge cases you always get wrong. For each, define expected outcomes and why. Every change runs through these tests. This is how you earn engineering trust and reduce sign-offs.
3) Use AI where it speeds structure, not where it replaces it. Feed quotes, price lists, and support tickets into AI to propose attribute catalogs and draft rule candidates. Then force those drafts through human review and your test suite. AI drafts. Humans define. The engine proves.
4) Launch narrow and visible. Pick one product line, one region, and a handful of key partners. Measure two things: quote cycle time and engineer touch per quote. If those don’t move, go back to rule clarity and explainability. Adoption is the only metric that matters.
5) Tie the triangle. Connect sales config to CLM to production config early, even if lightly. Example: push a clean sales BOM with manufacturing attributes pre-mapped for one family. Show the plant that sales is sending buildable intent, not marketing fluff. Credibility compounds.
The quiet truth
I’ll acknowledge the counterargument. You can brute-force many of these outcomes with more people and heroics. I’ve seen it work for a while. Then the experts change roles and the whole thing wobbles. Tribal knowledge does not scale. Pave the road.
The Holy Grail of manufacturing is not a product you buy. It’s a system you build, one correct quote at a time.




