You May Not Realize It, But Your Business Has a Configuration Problem

You May Not Realize It, But Your Business Has a Configuration Problem

Seven quiet signs it is already costing you money, wherever your customers cannot simply buy what you sell.

Executive summary

If what you sell has to be assembled, specified, or engineered to a customer's situation rather than picked off a shelf, you very likely have what we call a 'configuration problem.' And you almost certainly do not call it that. You call it the quoting mess, the spreadsheet only one person understands, or the reason we lost money on that order. It hides in plain sight precisely because it never announces itself as a technology problem — it shows up dressed as a business problem, one department at a time, and by the time anyone puts a single name on it, it has usually been expensive for years.

Having stated the conclusion, let us build the case for it properly, the way we would with a colleague rather than a prospect: starting from a definition simple enough to state in one breath, moving through where the problem tends to hide (services as often as hardware, and growth as often as decline), and ending with a short test you can run on your own business in about fifteen minutes. No consultants required.

What is a configuration problem

A configuration problem exists the moment a customer cannot simply buy your product off a catalog — they must have one assembled, specified, or designed for their situation, from parts and choices that interact with each other. Put that way it sounds almost universal, and in the everyday sense it is: a laptop with a choice of processor, memory size and warranty is technically a configuration problem, but a harmless one. A few choices, they barely interact, and a wrong answer costs an apology and a fresh order. Nobody needs an engine for that.

The commercially serious version has four properties, and it is the combination that turns a shopping decision into a business risk:

Things are made of things. A turbine island is a turbine plus a generator plus a condenser plus controls; a data hall is rows made of racks made of servers made of components. Several levels deep, and a choice at one level constrains choices at another.
Choices cross boundaries that nobody owns. A decision the electrical team makes constrains what the mechanical team can do; a grid code written for one country quietly forbids a component choice made for another.
Something has to add up. Total weight, power, cost, footprint, capacity — there is a number that must not be exceeded, and it is the sum of many small decisions that nobody in the building makes together.
Being wrong is not merely suboptimal, it is expensive. The result is not a slightly worse answer; it is unbuildable, illegal, unsafe, uncertifiable, or unprofitable — and you generally find out late.

The short test: if a wrong specification can produce a machine that cannot be built, a device that cannot legally be sold in a given market, or a bid that quietly loses money for the next five years, you are looking at a configuration problem, whatever your organization happens to call it internally.

It hides in services just as often as in hardware

Most people miss this, and it is usually where the second, larger problem lives. A service contract is configured exactly the way a machine is: it has parts (coverage, response time, spares, geography, escalation), those parts interact (a four-hour response commitment in a remote region requires a spares depot within a certain radius, which in turn requires enough volume to justify), and something has to add up — the price has to cover the true cost of the promise, and margin is exactly where that arithmetic tends to go wrong without anyone noticing. Worth examining with this lens: warranty and service contracts on capital equipment, uptime guarantees, tariffs and connectivity plans, managed services, financing structures, and any outcome-based contract.

With a piece of hardware, an error is usually caught in the factory — painful, but visible, and it stays inside one order. With a service contract, a mis-configured clause can go on losing money for two years before anyone notices, because no spreadsheet has ever held the full arithmetic across every clause of every contract. And where the service is regulated — insurance, telecom, medical, financing — the exposure runs deeper still: a single clause that quietly breaches a rule is not one bad contract, it is the same breach replicated across every contract that carries it, and the bill arrives as fines and retroactive liability rather than as merely lost margin.

Seven signs you are looking at the same problem

Three or more of these together, and you are looking at a real configuration problem — whether or not anyone in the building has ever used that phrase for it.

Depth. Products built from sub-assemblies built from components, three or more levels down.
Interaction. A choice made in one team's corner forces or forbids a choice in another's, and neither team necessarily knows it.
Aggregates. A total that must never be breached — weight, power, cost, capacity, footprint — and it is the sum of decisions nobody in the room makes together.
Cost of error. Wrong means unbuildable, illegal, unsafe or unprofitable, not merely a little worse.
Variety.Hundreds or thousands of valid variants — a catalog to build from, in other words, not a price list.
Churn. The catalog, the prices, or the regulations change several times a year.
Growth — the one you measure, not hear. Quote volume climbing twenty percent a year or more sounds like nothing but good news, and mostly it is. Except that a spreadsheet three people can just about keep current today is one those same three people cannot keep current in two years, once the volume has doubled. The work does not scale by adding tabs; it scales by adding trained experts, and one of those takes about a year to produce. A fast-growing business that still quotes by hand is not in trouble yet. It is scheduled to be.

The first six of these tend to arrive as complaints, and they are worth listening for around your own building. Note the sentences that keep recurring: “only two or three people can quote this properly,” “a quote takes four days, sometimes two weeks,” “there is a spreadsheet with forty tabs, one person built it, and she is retiring,” “we found out there was a problem after the order was already booked,” “engineering reviews every quote, even the routine ones.” Any one of these is an anecdote. Three or four of them, said by different people in different meetings, is a pattern.

If there is a single sentence worth tuning your ear to, it is 'only she knows.' It sounds like a compliment, and it is one, but it is also a confession: the knowledge that keeps your quoting process alive is real, valuable, undocumented, and walking toward the door on its own schedule, not yours.

Where this genuinely does not apply

Not every configured product has this problem, and it is worth saying so plainly, because half the value of any diagnostic is knowing when to set it down.

The product is genuinely simple — a short list of options that barely interact. A better price list solves it.
There are no hard limits. If nothing has to add up, there is nothing to enforce.
Errors are cheap and reversible. If a wrong answer costs an apology, nobody will pay to prevent it.
Every job really is a one-off, engineered from first principles each time. No repeatable structure means no model worth building.
Variety is low — under about a hundred valid variants, and a table still does the job.

We say this for a reason that has nothing to do with modesty: telling a company that its problem does not need solving buys more credibility than any product demonstration, and it is exactly why, when we do say a problem is real, people tend to believe us.

A fifteen-minute self-test

Five questions, asked honestly about your own business, tend to settle the matter faster than any workshop:

How many valid variants of this product can we actually sell? Under a hundred, this is probably not your problem yet. Thousands — or “we genuinely don't know” — and it is.
What happens when the specification is wrong? Listen for unbuildable, illegal, uncertifiable, penalty, lost margin. If the honest answer is “we just fix it,” there is no urgency yet.
How many people can do this correctly today? A number under five, with one of them near retirement, hands you both the problem and its deadline.
What must add up — weight, power, cost, capacity, footprint — and do we know that number cold, right now? If someone can name it immediately, it is real, and it binds.
What are we running this on today, and who built it? A spreadsheet, a rules-based tool outgrown years ago, or a real system — the answer tells you how much runway is left.

A word about AI, since everyone is asking

A system that talks fluently about your product is not the same thing as a system that can promise the quote is right, and the difference matters more, not less, as the talking gets better.

Modern language models are superb readers and explainers, and increasingly good at drafting a plausible configuration. What none of them can do — no matter how large, or how confidently they appear to “reason” about the problem — is certify that every rule holds and every total stays inside its budget. A model's fluency is not a guarantee, and a wrong answer that reads smoothly is more dangerous than one that reads awkwardly, because nobody thinks to check it. That distinction, between a system that talks well and a system that promises correctly, is the subject we take up properly in the next paper in this series.

This is the first of three papers

Recognizing a configuration problem is, in our experience, the easier half of the job — once it has a name, most executives realize they have been arguing about the symptom for years without ever naming the cause. What to do about it is a longer conversation: why the decision-tree-and-rules approach used by most “configure, price, quote” software eventually collapses under its own weight as a product grows, why a constraint-based engine avoids that collapse, and what such an engine needs to do, specifically, to sit safely underneath a large language model rather than simply behind a form. That is exactly what the next two papers in this series set out to answer.

Appendix: Recognizing This in Your Own Sector

The four properties in Section 1 look a little different in every industry. Below are ten shapes we see most often — eight where the “product” is hardware, and two where it is a contract. None of this is required reading; it is here in case one of these is closer to home than the abstractions above.

Power generation and grid equipment

Turbines, generators, transformers, switchgear, HVDC links, wind installations. The depth runs from plant to island to machine to component, and every unit is engineered to a specific site: a grid code, a load profile, and ground conditions that never quite repeat. What must add up is output rating, grid-code compliance, footprint, weight, thermal load, capital cost, and delivery date, all at once. Get it wrong and the result is a bid priced on a machine that cannot be built, or a unit that cannot be certified for the grid it was sold into. The tell is hearing “every project is bespoke” and “we won the bid, then found out what it actually cost.”

AI data centers and IT infrastructure

The depth runs hall to row to rack to server to GPU, alongside the electrical and thermal chains that shadow it. Power is the scarcest resource in the industry, and a naive model can easily overstate deliverable capacity by roughly a fifth, because power distribution units come in discrete ratings, cooling equipment eats into rack space, and redundancy halves what looks usable on paper. What must add up: provisioned megawatts, usable capacity after redundancy, rack units, row slots, cooling capacity, capital cost. Errors here are measured in tens of millions of stranded dollars — capital that cannot be energized. The tell: “we sized it in a spreadsheet” and “we found out at commissioning.”

Commercial vehicles, off-highway equipment, and rail

Gross vehicle weight and axle loads are not guidelines, they are law: exceed them and the vehicle cannot legally operate, yet the weight is the sum of decisions made by a chassis manufacturer, a body builder, and a customer who never spoke to one another. Depth runs chassis to body to axle configuration to powertrain to payload. What must add up: gross vehicle weight and axle loads, payload against curb weight, duty cycle, emissions compliance, range. Wrong means the vehicle cannot legally operate, cannot serve its intended route, or carries warranty exposure nobody priced in. The tell: “the body builder got the weight distribution wrong,” “the customer ordered the wrong axle.”

Flow, motion and fluid systems

Pumps, valves, actuators, filtration, hydraulics — deep catalogs sold mostly through distribution, which means the people configuring them often understand the catalog less well than the factory that built it. Depth runs system to assembly to component to the material and seal selection that must survive whatever is flowing through it. What must add up: pressure and temperature ratings, flow, compatibility with the medium, certification class. Wrong means a seal that fails in service, a pump that cannot be certified for that fluid, or a channel-sold quote that simply cannot be built as specified. The tell: “distributors quote it wrong,” “application engineering reviews every order by hand.”

Medical devices and diagnostics

Two constraints most industries do not face at once: regulatory clearance is granted per market and per configuration, and the installed system must physically fit a room that already exists. The same analyzer sold into three countries is, on paper, three different products. Depth runs system to module to assay or consumable to service plan, and separately market to clearance to labeling. What must add up: room footprint and access, power and water, throughput, clearance status per market, and service coverage. Wrong means a device that legally cannot be sold in each market, cannot be installed in the room it was quoted for, or a service contract quietly priced below its own cost. The tell: “regulatory reviews every variant by hand,” “we found out at installation.”

Electrical equipment and power management

Switchgear, UPS systems, distribution and protection equipment, where the governing rules are already written down in standards that nobody rereads at quoting time. Depth runs lineup to section to breaker to trip unit, and separately system to feed to distribution to load. What must add up: fault current, continuous derating, breaker coordination, arc-flash energy, redundancy topology, enclosure space. Wrong means a lineup that fails its coordination study, or equipment that cannot be code-approved as configured. The tell: “the application engineers catch it,” “it failed the coordination study.”

Semiconductor and electronics manufacturing equipment

Extremely high value per unit, deep configurability, and utility envelopes that bind hard. Depth runs tool to module to chamber to process kit, and separately fab to bay to utility envelope. What must add up: cleanroom footprint, throughput, power, gas and exhaust handling, vibration tolerance, process compatibility. Wrong means a multi-million-dollar tool that cannot meet the process spec or physically fit the utility envelope it was quoted against. The tell: “every tool is configured by the process team,” “the quote takes weeks.”

Network, communications, and process plant

Grouped together because they share a shape — systems assembled from catalogs where reach, capacity, and interoperability constrain each other, and the deal is quoted long before it is actually engineered. Depth runs network to site to equipment to link, and separately plant to unit to skid to component. What must add up: reach and distance limits, power budget per site, capacity, throughput, footprint, and utilities. Wrong means a link that will not close, a site that cannot carry the load it was sold on, or a plant that misses its throughput target. The tell: “every enterprise deal is bespoke,” “sales promises what engineering cannot deliver.”

Warranty and service contracts on capital equipment

The “parts” here are coverage tier, response-time commitment, spares provisioning, and geography, and they interact in ways that are easy to miss: a four-hour response commitment in a remote region requires a spares depot within a certain radius, which in turn requires enough contract volume in that region to justify the depot at all. What must add up is the oldest number in the business — the price must cover the true cost of the promise — and margin is exactly where it tends to go quietly wrong. The tell: a contract renewed for years that nobody has ever actually costed clause by clause, and an honest “we don't actually know if that one makes money” when asked directly.

Regulated tariff and service-plan portfolios (telecom, insurance, leasing)

Hundreds of plans across dozens of markets or service areas, each a bundle of price, terms, and entitlements that has to satisfy three things simultaneously: it must be deliverable by the underlying provisioning or underwriting system, it must be priced consistently against every other plan already in the portfolio (no plan should be strictly worse than another on every dimension, or customers will arbitrage the gap), and it must be filed correctly with the regulator that governs it. Wrong means a plan the operational system cannot provision, a filing that is late or inconsistent and draws a regulatory penalty, or a portfolio quietly cannibalizing itself. The tell: “we found out the system couldn't actually provision that plan after it was already live.”

Suggested Further reading

" Complex Product Configuration Requires a Constraint-Based Approach " — the technical case for constraint-based configuration, with architecture and object-model detail.

" The Business Case for Constraint-Based Configuration " — a condensed overview for CIO/COO/CRO audiences.

" Requirements for a Constraint Server Behind an LLM Front End " the correctness/completeness/propagation/consistency requirements from Section 5, in full technical depth.

" Pricing Is a Configuration Problem " - A Constraint-Based Approach to Enterprise Quote-Time Pricing, the Section 4 argument, developed at length with a Google Cloud worked example.

" Guiding AI Agents to Reason Correctly " – shows how Predictika constraint engine can act as a reasoning co-pilot to existing AI Agents to ensure correct behavior.

" Not All Constraint-Based Systems Are the Same " — a broader comparison of several well-known constraint-based configuration engines (Oracle, Tacton, Configit), for readers weighing more than one constraint-based vendor, not just a rules-based one.

About Predictika

Predictika builds a patented constraint-based configuration engine for complex products, pairing a declarative modeling language with a logic core whose lineage runs from foundational AI research at Xerox PARC to proven, large scale enterprise configuration at Selectica. The company applies that engine both as a configuration core for complex products and as a deterministic validation layer beneath LLM driven assistants, giving natural language systems the soundness that high-cost-of-error domains require.

About the author

Dr. Sanjay Mittal is the founder and CEO of Predictika and the architect of its constraint-based reasoning engine. He began his career as a research scientist at Xerox PARC (1982–1990), with pioneering work in artificial intelligence and constraint reasoning. He went on to found Selectica, which defined enterprise sales configuration (CPQ) for large organizations, building it from inception to a $5 billion IPO and serving customers such as IBM, Cisco, Dell, GE, Hitachi, Disney, AT&T, and Reliance. Dr. Mittal was the inventor of Selectica's industry leading configuration engine and holds six patents from that work. At Predictika he has carried the constraint-based approach into the era of large language models, with further patents — including U.S. Patents 11,544,475 and 11,914,970 — covering the deterministic validation of LLM driven systems. He holds a B.Tech. from IIT Kanpur and a Ph.D. from Ohio State University.