What is the number that decides whether a product configurator will actually help you sell more?
In companies selling variable products that never measured it, the share of quotes going through the engineering office often sits between forty and seventy per cent, and with one thousand one hundred quotes a year the five waste items cost between ninety and three hundred and ninety five thousand euro a year. A subscription product costs between sixty and one hundred and fifty euro per user a month plus rule modelling, a custom system starts at forty thousand euro. Below twenty five thousand euro a year of spend the product or the ERP module almost always wins, and written rules always come before the 3D model.

The sales director had eight salespeople, about twenty agents and an engineering office of six people who, on top of designing, prepared the quotes for the conveyor lines the company built to customers' dimensions. A quote took eleven working days on average to go out. When we lined up a year of quotes for the first time, it turned out that six in ten went across an engineer's desk, but only one in seven contained anything that had never been built before: the rest were variants of width, length and motor already made dozens of times. And customers who received the quote within five days signed almost twice as often as the others. That is the problem a product configurator is supposed to solve, and it is also the one no configurator solves on its own.
If you recognise the scene, this article gives you the real cost of preparing quotes by hand, the single number that tells you whether a configurator will help you sell more or just show your product in three dimensions, how to write the rules that turn a customer's choice into a price and a bill of materials, how far a spreadsheet with macros takes you, the three different things vendors all sell under the same name, the real price bands for the module of the ERP you already own, a subscription product and a custom system, and the threshold in euro beyond which the maths changes.
I have been writing software since 1999 and I have seen technical quotes come to life in many ways: machine builders answering a forty page specification, window and furniture makers with thousands of combinations of sizes and finishes, electrical panel and plant companies where every quote is a small project, technical distributors with an agent network that would like to price from a tablet in front of the customer. I also built and sold a software product used by many companies, and I know what it takes to turn into rules the way someone works when they have never written those rules down.
What I learnt, and what no vendor says during the demo, is this: the number that decides is not how many combinations the configurator can show, it is how many of your quotes need an engineer to be prepared today. The 3D model spinning on the screen is the part that sells best and earns least: it looks great at a trade fair, but it does not shorten response time by a single day. The money is in the quotes a salesperson could prepare alone that instead sit waiting on the engineering office's desk.
What a product configurator is, and what it is not
A product configurator is the system that guides whoever prepares the quote through the possible choices of a variable product, blocks combinations that cannot be built and in the end returns three things together: the price, the quote document and the bill of materials production will use to build what was actually sold. It answers a single question, for every request: can what the customer asks for be made, what does it cost and how is it built, without three different people each answering their own part.
You will find it on the market under different names, and the confusion suits whoever is selling. Sales configurator, technical configurator, quoting tool, 3D configurator, online configurator, CPQ, short for configure, price, quote. They overlap only in part, cost very different amounts and solve different problems. A viewer that shows the colour of the cover knows nothing about which motor is needed, and a spreadsheet that computes the price does not know whether that combination can leave the workshop.
The difference between showing a product and knowing whether it can be built
Almost every company that writes to me already has part of the problem covered. They have a price list, almost always in Excel, with component prices and markups. They have the ERP with bills of materials for standard items. They have the engineering office's CAD with models of machines already built. And they have a good person, sometimes two, who knows the product by heart, knows which combinations work and which do not, and every week answers dozens of questions that begin with "can we do it if".
The point is that these pieces answer questions different from yours. The price list answers what a component costs. The ERP answers how an item already coded is built. The CAD answers what a machine already drawn looks like. Your question is another one: can this combination, which nobody ever ordered exactly like this, be built, at what price and with what margin, and how does it reach production without someone retyping it. None of the three pieces sees it, because the answer lies in the rules linking the choices to one another, and today those rules live in the good person's head.
Then there is time, as always. The request reaches the salesperson on Monday, who passes it to engineering on Tuesday. The engineer looks at it on Thursday, because Wednesday was a factory acceptance test, and finds two pieces of information missing. The salesperson asks the customer, the customer answers the following week, and accounts confirm the price because steel has gone up. Eleven days. Meanwhile the customer has asked for two more quotes, and the first to arrive has set the reference price yours will be compared with.
The three kinds of companies looking for it, and looking for different things
Companies selling configurable catalogue products. Windows, furniture, pumps, modular machines, standard panels and cabinets, industrial components with smart part numbers. Variants are finite but numerous, sometimes millions of combinations. The value lies in response speed, eliminating wrong combinations and giving the sales network autonomy. Here a well built configurator brings the share of quotes going through engineering close to zero.
Companies building to order from a base that repeats. Plants, special machines, production lines, steel structures. Every quote has a new part, but almost always seventy or eighty per cent is made of modules already built. The value lies in separating the repeated part from the new one, so the engineer works only on the new part, and in getting the job into production with a starting bill of materials that is already right. The link with the true cost of the job is direct, and I covered it in job costing software.
Companies selling through dealers or directly online. Manufacturers with a dealer network, or end customers configuring the product themselves. There is no salesperson acting as a filter here, so the value lies in orders that arrive already correct, in phone calls that disappear and, this time yes, in the visual experience, because the dealer has to sell in front of their own customer. It is the only case where the 3D model really matters.
All three buy products with the same name and use different parts of them. Before you watch any demo, decide which one you are. Most of what follows applies to the first two, where the quote is prepared by someone in your company; for the third, the number that decides is not the engineering share but the share of dealer orders that have to be corrected before entering production, and I will flag where things change.
The real bill: what preparing quotes by hand costs you

This is the calculation almost nobody does, because none of these items has a line in the accounts: they are orders that never arrive, engineering hours and margin disappearing into an average. I take as a reference a manufacturer with fourteen million euro in revenue, seventy employees, eight internal salespeople, twenty agents, an engineering office of six, about one thousand one hundred quotes a year with a twenty five per cent win rate and an average order value around fifty thousand euro. It is a very common size among the people who write to me, and the numbers scale reasonably well with the number of quotes.
A warning about margin, because the whole calculation depends on it. When you reason about lost orders, revenue does not count: contribution margin does, meaning what is left after materials, outsourced work and direct hours. In companies of this kind it sits between twenty and thirty five per cent. I use twenty five, so as not to inflate anything.
Quotes lost because they arrived late
This is the largest item and the least visible, because a lost order leaves no trace: the customer simply does not call back. On one thousand one hundred quotes, every point of win rate is worth eleven orders, meaning five hundred and fifty thousand euro in revenue and about one hundred and forty thousand euro in margin. In my experience, bringing response time from two weeks down to two or three days gains between one and three points, and I count only one.
Not every lost order depends on speed, and anyone who promises to double your sales with a configurator does not know the trade. There are customers who buy on price alone, tenders where time does not matter, specifications won by whoever already has the relationship. But there is almost always a share of customers who pick the first credible supplier to answer, and you lose that share every time the quote waits in a queue.
The engineering office preparing quotes instead of designing
In the reference company the six engineers spend about forty per cent of their time on quotes: checking feasibility, sizing, choosing components, answering sales. That is about three thousand eight hundred hours a year, which at a full cost of forty five euro an hour makes one hundred and seventy thousand euro. At least half of that work concerns combinations already built, and a configurator with the right rules takes it off their desk: up to ninety thousand euro a year.
The real cost, though, is not the engineer's hour, it is what the engineer does not do while preparing quotes. Jobs already sold that start late because detailed design is waiting, product improvements postponed for two years, acceptance tests done in a rush. Nobody puts it in the calculation, and it shifts the whole company's deliveries.
Configuration errors that reach production
The chosen motor cannot handle the load and it shows at acceptance testing. The option sold is not compatible with the frame and it shows at assembly. The width was copied from quote to order with one zero missing. In the reference company it happens on one order in twenty five, about eleven a year, and each costs six thousand euro on average between remade material, workshop hours, site visits and discounts granted by way of apology: up to seventy thousand euro a year.
This is the item that comes down with the most certainty, because the cause is always the same: the configuration passes from hand to hand and is rewritten at every step. When compatibility rules live in the system and the bill of materials comes out of the configuration without being retyped, errors of this kind almost disappear. Design errors remain, and those are another matter.
Different prices and discounts for the same thing
Two salespeople quote the same configuration a month apart and the prices differ by eight per cent. One agent uses the March price list, from before the steel increase. Another applies the maximum discount to everyone, because it is the only way he knows to close. Nobody does it out of malice: the price list is a file, discount rules are an email from two years ago, and nobody sees the real margin of each quote before signing. Half a point of margin lost on fourteen million is worth seventy thousand euro; I count up to sixty thousand.
There is a side effect worth more than the money: customers talk to each other. A customer who finds out they paid more than a competitor for the same machine does not forget it, and the next negotiation starts from there.
New item codes for variants that already existed
Every closed quote becomes a new item in the ERP, with a bill of materials copied from a similar one and corrected by hand. After ten years there are thousands of codes that differ by one dimension, bills of materials where nobody knows any more which is the right one, and a warehouse holding the same component under three different codes. In the reference company about three hundred codes a year are created for combinations already built, and between coding time, picking errors and duplicate stock it adds up to thirty five thousand euro a year. The link with what sits on your shelves is direct, and I described it in warehouse management software.
The total, for a company with one thousand one hundred quotes, sits between ninety and three hundred and ninety five thousand euro a year, and no company hits all five items at the maximum. The range is wide because the real variable is not the number of quotes: it is how many of them go through an engineer. Those selling few products with few variants sit at the bottom, those selling machines with hundreds of options and an engineer who answers "it depends" sit at the top. Run the numbers with your own figures, even roughly, on a single sheet. If your total is below thirty thousand euro a year, software is not your most urgent problem, and further on I will tell you what is.
The share of quotes going through engineering: the number that decides

If I could keep only one number from this whole article, I would keep this one: how many of the quotes issued over the last twelve months needed the engineering office to be prepared. I simply call it the engineering share. It decides everything, because every function of a product configurator, from compatibility rules to price calculation to the generated bill of materials, works to bring that number down, and if you do not know where you start you cannot know whether the system you buy is bringing it down.
The reason this number matters more than the number of combinations, the 3D model and the look of the quote is that it rolls every problem we have discussed into a single figure: response time, because every trip to engineering adds days; hours taken from design; errors, because every handover is a chance to rewrite something wrongly. And it is a hard number to fudge, because a quote either went through an engineer or it did not.
How to measure it, in a day
You need two things. The first is the list of quotes with request date, sending date, product family and outcome, which almost certainly lives in the ERP or the CRM. The second is a trace of the steps through engineering, and that is what is usually missing: you rebuild it from internal requests, emails with a recognisable subject, engineers' timesheets if they keep them. At worst, you ask the engineers to mark by hand on the list for the last three months which quotes they touched: they know, and it takes them an afternoon.
If the data already sits in a database, the measurement is a query. This is the shape I use on SQL Server. Table names in your system will differ, the substance will not:
-- Share of quotes with an engineering step, by product family,
-- and average days between customer request and quote sent, last twelve months
SELECT q.ProductFamily,
COUNT(*) AS Quotes,
SUM(CASE WHEN er.QuoteId IS NOT NULL THEN 1 ELSE 0 END) AS WithEngineeringStep,
SUM(CASE WHEN er.QuoteId IS NOT NULL THEN 1 ELSE 0 END) * 100.0
/ COUNT(*) AS EngineeringSharePercent,
AVG(DATEDIFF(DAY, q.RequestDate, q.SentDate) * 1.0) AS AverageResponseDays
FROM Quotes AS q
LEFT JOIN (SELECT DISTINCT QuoteId FROM EngineeringRequests) AS er
ON er.QuoteId = q.QuoteId
WHERE q.RequestDate >= DATEADD(MONTH, -12, CAST(GETDATE() AS date))
GROUP BY q.ProductFamily
ORDER BY EngineeringSharePercent DESC;Then do the second pass, the one that tells the truth: for each quote that went through an engineer, ask whether it contained something never built before. I call the first kind necessary steps and the second habitual steps. A quote for a machine with a width already built a hundred times, which goes to engineering because the salesperson does not trust the spreadsheet, is a habitual step. The gap between the total engineering share and the share of necessary steps is exactly the part a configurator can recover. In the conveyor company it was sixty two per cent against fifteen, and on its own it was worth more than any software.
And there is a third calculation, the most convincing one when you have to explain the project to a business partner: split quotes into response time bands, zero to three days, four to seven, eight to fifteen and beyond, and compute the win rate of each band. If the win rate falls as days go up, and it almost always does, you have proof that response time is costing you orders, with your numbers and not a vendor's.
Three caveats, because the measurement is easy to distort without meaning to. Do not exclude large quotes because they are special: they are exactly the ones where a repeated module gets redesigned from scratch. Do not count only quotes recorded in the ERP, because agents prepare some of them on their own spreadsheet and send them by message, and those are often the most wrong. And measure by product family, not overall: there is almost always one family that is ninety per cent configurable pulling the average down and one made entirely to design pulling it up.
In companies selling variable products that never measured it, the result often sits between forty and seventy per cent. For those selling through dealers the measurement changes form but not substance: the number that decides is the share of dealer orders that the internal office has to correct or complete before they enter production, and the gap between that share and zero does the job the engineering share does here.
The four thresholds, and what you can do at each
Below twenty per cent: the product is already configurable. You are in the minority, and you have already done the hardest work, even if you may not know it: your product is modular and the rules are clear enough to fit in a spreadsheet. Here a configurator pays back mainly through response speed, transcription errors that disappear and agent autonomy. You can skip much of what follows and go straight to the choice.
From twenty to fifty per cent: the rules live in the engineers' heads. This is the most common band. The product is largely modular, but the rules saying what goes with what, and when a bigger motor is needed, were never written down: engineering knows them, so every doubt a salesperson has becomes a trip to engineering. Once the rules are written and put in a system that applies them, the share usually drops to fifteen or twenty five per cent within a year.
Above fifty per cent: the problem is the product, not the software. With a share that high no configurator works miracles, because if every quote really is a project there is nothing to configure. The work is different: sit down with engineering, take the last hundred jobs and look for the modules that repeat, even if they were drawn from scratch every time. They are almost always there, and modularising the product is worth more than any system. Software comes afterwards, and costs less.
Never measured: you do not know. It is the most common case of all, and it is nobody's fault: quotes live in the ERP, trips to engineering live in somebody's inbox, and nobody was ever given the job of joining them. The first job is not buying a configurator, it is doing this measurement once, over twelve months or at least three. One day from someone who knows the data is enough, and the result changes the conversation with any vendor.
The practical rule is a single one: before you buy a system that configures your product, get hold of the number that system will have to bring down, because without a starting point nobody will be able to tell you whether it worked. Serious vendors ask you for it themselves. The ones who do not will sell you the 3D model.
Rules: where a configurator earns its keep and where it falls short

This is the heart of the trade, and it is where demos are most misleading. In the demo the vendor configures a bicycle or a chair: three sizes, five colours, two compatibility rules, and in a minute out comes a formatted quote with a photo. It is all true. Then the configurator reaches your engineering office, and the engineer explains that the motor depends on width, length, load and incline, that in the food sector the frame has to be stainless steel but only in the parts in contact with the product, that beyond a certain length you need two motors and a different control panel, and that for half the questions the right answer is "it depends".
The difference between a configurator that shows combinations and one that produces buildable quotes lies entirely in the rules, and rules are your company's real asset, the one that today lives in the engineering office's heads and in the formulas of a spreadsheet. A configurator is worth exactly as much as the rules it knows.
The rules a configurator must know, or it sells impossible things
Compatibility between options. What excludes what, and what requires what. The food grade belt requires a stainless frame, the outdoor version excludes a certain type of motor, remote control requires the panel with the network module. It is the simplest kind of rule and one every configurator handles; the problem is that it is rarely written down anywhere.
Sizing. One choice imposes another, often through a calculation. Width and load decide motor power, weight decides the structure, flow rate decides pipe section. This is where many subscription products start to struggle, because rules are no longer compatibility tables but formulas, and engineering formulas have exceptions nobody remembers until they get it wrong.
Construction and regulatory limits. Minimum and maximum dimensions, combinations the workshop cannot make, certifications that change the construction, such as versions for explosive atmospheres or for food contact, and requirements for CE marking. A quote promising a non compliant machine is not an aggressive quote, it is a problem that arrives after signing.
Price. Component price list, markups by family, discounts by channel and customer, rounding, quote validity, raw material adjustments. It is the part everyone thinks they already have in the spreadsheet, and the part where the spreadsheet is most fragile, because every supplier increase has to be copied by hand into twenty cells.
Bill of materials and routing. Which codes, in which quantities and with which operations come out of a configuration. It is the rule that turns a quote into something production can build, and the one that separates a quoting tool from a real configurator.
Documents. The quote with the right terms, the data sheet, an outline drawing, the delivery date. The date in particular: a quote promising six weeks when production has a ten week backlog is not the configurator's mistake, but the configurator is the right place not to make it, as I explained in production management software.
The generated bill of materials, and why it matters more than price
Price is visible, and that is why everyone works on it. The bill of materials is not visible, and that is where money is lost, because a wrong bill of materials produces a quote with the right price for a different machine from the one that will be built. It is worth seeing how a written rule works, because it makes clear where the decision comes in. This is a C# example that compiles and runs: it checks a conveyor configuration, generates the bill of materials and computes the price with the markup.
using System;
using System.Collections.Generic;
using System.Linq;
public sealed record Configuration(int WidthMm, int LengthMm, decimal PowerKw, bool FoodGrade, bool StainlessFrame);
public sealed record BomLine(string Code, string Description, decimal Quantity, decimal UnitCost);
public static class ConveyorConfigurator
{
// Compatibility and sizing rules: any violation blocks the quote
public static IReadOnlyList<string> Check(Configuration c)
{
var errors = new List<string>();
if (c.FoodGrade && !c.StainlessFrame)
{
errors.Add("Food grade conveyors need a stainless steel frame");
}
if (c.WidthMm > 1200 && c.PowerKw < 2.2m)
{
errors.Add("Beyond 1200 mm width a motor of at least 2.2 kW is required");
}
if (c.LengthMm < 1000 || c.LengthMm > 12000)
{
errors.Add("Length must be between 1000 and 12000 mm");
}
return errors;
}
// The bill of materials comes out of the configuration, never retyped
public static IReadOnlyList<BomLine> BillOfMaterials(Configuration c)
{
var metres = c.LengthMm / 1000m;
return new List<BomLine>
{
new(c.StainlessFrame ? "FRM-SS" : "FRM-PNT", "Frame per metre", metres, c.StainlessFrame ? 410m : 180m),
new("BLT-" + c.WidthMm, "Belt per metre", metres * 2m + 0.6m, c.WidthMm * 0.09m),
new("MOT-" + c.PowerKw.ToString("0.0"), "Gear motor", 1m, 350m + c.PowerKw * 240m)
};
}
public static decimal Price(IEnumerable<BomLine> lines, decimal markup) =>
Math.Round(lines.Sum(l => l.Quantity * l.UnitCost) * (1m + markup), 0);
}The interesting part is not the code, which is trivial: it is where the rules live. In this example they live in code, so only a developer can change them. That is fine for explaining and bad for working: the day engineering decides the limit is no longer twelve hundred millimetres but eleven hundred, they have to open a request and wait. In systems that work, rules live in tables engineering edits on its own, with an automated test checking that quotes already made still give the same result. When a vendor tells you their product handles complex rules, there are three questions to ask: who changes a rule, how long it takes, and how you prove the change has not broken configurations already sold.
And there is a check that takes a day and that I always recommend: take the last fifty orders produced, reconfigure them with the configurator and compare price and bill of materials with what was actually built. If more than five orders in fifty give a different result, the rules are wrong or incomplete, and every quote derived from them is wrong with them. It is the same principle as the reconciliation between cost accounting and statutory accounts I described in management control software, applied to quotes.
How far a spreadsheet with macros takes you
Almost every Italian engineering company has the file. It is an Excel workbook with macros, built over ten years by an engineer who has since retired or by the owner's son during university, with one sheet for the price list, one for the options and one that prints the quote. That is not a flaw: it is a tool that costs nothing, that the company tailored to its own product and that often holds more knowledge than any document. I have seen companies prepare better quotes with that file than others with a one hundred thousand euro system. The point is not whether the file is enough, but when it stops being enough, because it stops quietly: it does not break, it starts costing a little more every month, and nobody notices.
The five conditions that bring it down
How many people prepare quotes. Up to three or four people in the same room, the file holds: they talk, they pass around the right version, they correct each other. Beyond six or eight, and especially with external agents working from their own laptops, everyone has their own copy and quotes start to diverge.
A price list that changes. While prices change once a year, updating the file is an afternoon. When they change two or three times a year, as happened to almost everyone with steel, copper and energy, every update is a risk, and the wrong quote is usually the one to the biggest customer.
The person who knows how to use it. If only one person can change the file, that person is the system. The day they are on holiday nobody adds the new option, and if they leave they take your product's rules with them, because the rules live in their formulas and not in a document.
The handover to production. While a signed quote becomes an order with two lines, retyping it is little work. When it becomes a bill of materials with forty codes to retype into the ERP, every order is a chance for error, and that is where the reference company's eleven wrong orders a year come from.
Versions in circulation. The agent still using the March version, the salesperson who fixed a formula for one customer and told nobody, the copy saved on the desktop as "final new". When you have to ask which file is the right one, the file has already stopped working.
My rule of thumb: if two of these five conditions hold, you are at the limit and have time to organise. If three or more hold, the file is already costing you more than a system, only you pay in lost orders, errors and engineering hours instead of invoices. And I will add something no vendor will tell you: if none or one holds, stay where you are, measure the engineering share, write the rules down in a document and postpone the spend by a year.
What you carry over and what you throw away
When you move to a system, the file is not thrown away: it is the best specification you have. Compatibility rules sit in cell validation, sizing sits in formulas, markups sit in hidden tables, exceptions sit in macros. The first serious job in a configurator project is sitting with whoever built the file, or whoever uses it most, and reading it together line by line, writing down in plain language what each formula does and why. You discover rules nobody remembered having, and a few rules that have been wrong for years.
What gets thrown away are the formulas nobody knows the reason for any more, the exceptions for customers who stopped buying five years ago and the options nobody sells. Every rule should be tested against real orders: if it is right, the system will confirm it; if it is not, you have found an error that was costing you money. If the new configurator merely reproduces the file with nicer graphics, you have bought a more expensive file.
Visual configurator, CPQ and ERP: three different things with the same name

The three families of tools have three prices and three different returns, and the order in which you put them together decides whether they work. I line them up with what they really cover, because in quotes they arrive mixed together and comparing two offers becomes impossible.
The visual and 3D configurator answers what the product looks like. Shapes, colours, finishes, accessories, a model you can rotate and zoom, sometimes augmented reality to see the machine in the customer's building. It is the part that shows best at trade fairs and on the website, and for those selling through dealers or online it really matters. On its own, though, it does not know whether a combination can be built and it produces no bill of materials: it shows the product, it does not configure it.
The technical sales configurator, the real CPQ, answers whether that combination can be made and what it costs. Compatibility and sizing rules, price with markups and discounts, the quote document, approval of discounts above a limit and, in the best systems, the bill of materials generated from the configuration. It is the part that produces the result, and the only one that works on the engineering share.
The ERP and product data management answer how the product is built. Bills of materials, routings, item codes, inventory, production orders, and where there is a PLM, drawing revisions. It almost always exists already, and it knows items already made extremely well; it knows items still to be configured poorly, because it reasons in codes and a configurable product is by definition a code that does not exist yet.
The sequence that works, and the one you see around
The sequence that works is: written rules and a modular bill of materials, then configuration with price and quote, then connection to the ERP, and 3D last, if needed. The sequence you see around starts from 3D, because it is the visible part, the owner likes it and marketing has been asking for it for years, and it produces a typical result: a beautiful model spinning on the website, proudly shown at trade fairs, that has not taken a single quote off the engineering office's desk. The vendor delivered what was promised, and the original question, why do our quotes take two weeks, is still unanswered.
There is an honest exception, and it is when you sell mainly through dealers or directly to end customers, with a catalogue product and simple rules. In that case starting from the visual side with basic rules and direct ordering costs little and has an immediate effect. But the result should be measured with the share of orders arriving already correct and the time from request to order, not with the number of configurations made on the website.
What a product configurator costs: module, product or custom

The figures below are the ones I see in quotes for Italian companies with revenue between five and one hundred million euro. They are not price lists: they are the order of magnitude to compare what you receive against, and above all they help you spot the quote that is low because it is incomplete.
The configurator module of the ERP you already own
Many manufacturing ERPs have a configuration module, sometimes called a variant or item configurator. Turning it on costs between ten and forty thousand euro, almost all configuration. It has one advantage that matters: the bill of materials is born directly where it lives, with no connections to build. It is the route to evaluate first if your product is catalogue configurable, the rules are mostly about compatibility and quotes are prepared inside the company.
The limit is almost always usability. ERP modules are designed for people who code items, not for people who sell: pricing and discount rules are basic, the quote document is the ERP's, and for an agent with a tablet in front of a customer the interface is an obstacle. If your engineering share is low and quotes are prepared by the internal office, that is perfectly fine. If quotes are prepared by an agent network, the module records configurations with great precision and nobody uses it outside the office.
The subscription CPQ product
These are specialised configurators sold by subscription, with a rules engine, pricing, quote documents, approvals and often a separate 3D module. The bands I see run from sixty to one hundred and fifty euro per user a month, depending on modules and number of users. For twelve users, across sales and engineering, that is between fifteen and twenty thousand euro a year in subscription. On top of that comes setup between twenty and eighty thousand euro, and that is where the point lies.
Setup is almost all rule modelling, and it is the item quotes squeeze to look competitive and that then grows, for two reasons that always repeat: the real rules are twice those described in the first meeting, and the generated bill of materials has to be connected to the ERP, with coding schemes that do not match. Then there is a cost that keeps going: every new family, every new option, every rule change is work on the model, done internally if the product allows it or paid to the vendor. The two questions to ask are always the same: who models the rules after setup, and what happens to my rules if I stop after three years.
Custom
A configurator built around your product starts at forty thousand euro for one family, meaning compatibility and sizing rules in tables engineering edits on its own, price calculation with markups and discounts, the quote document and the bill of materials sent to the ERP. It reaches two hundred thousand with several families, a dealer portal, 3D visualisation, a CAD connection to generate outline drawings and complex sizing calculations. Add fifteen to twenty per cent a year in maintenance, which keeps the system alive when you change ERP, when a new family arrives or when a regulation changes.
It makes sense in three cases, and outside them it is almost always a waste. When the rules of your product are your competitive advantage, for instance because you size machines with calculations no subscription rules engine expresses without forcing. When the generated bill of materials has to enter an ERP and a CAD that no product connects without customisation that costs as much as building. And when the ERP you have works and should be kept, building the missing part around it instead of replacing it, which is the most frequent situation and the most underrated.
The threshold, and the variable that is not financial
The rule of thumb I use is this: below twenty five thousand euro a year of total expected spend, subscriptions and modelling included, the product or the ERP module almost always wins. Above that, redo the maths, because at that level five years of subscription plus ongoing modelling reach the cost of building, and the difference is all maintenance, which you pay either way. In the chart, for one product family and twelve users, the break-even point falls between year three and year four.
At that point a variable that is not financial matters: how much your product will change in five years. If you expect to add families, open a dealer network, move into a sector with different regulations or buy a competitor with its own catalogue, the flexibility of a system of your own is worth the premium, because every change in a product is modelling work with its own timeline and limits. If your catalogue has been stable for ten years, the product is the rational choice and custom is a luxury.
The questions to ask before signing, and the ten quote test
Product configurator demos are all convincing, because they show simple products with clean rules and a formatted quote in a minute. The way to come out with real information is to bring your hard quotes and watch how the person in front of you reacts. It is three weeks of work, and worth more than any comparison of feature sheets.
Week one: pick your ten quotes
Pick one product family, the one with the most quotes, and take ten quotes closed over the last year. Five ordinary ones, the kind the salesperson can almost do by heart. Three with an odd variant that needed a call to engineering. One that reached production with an error. And one engineering refused because it could not be built. For each, keep the quoted price, the bill of materials produced and, where there was one, the error.
These ten quotes have a useful property: the first five tell you whether the configurator does the easy work, the other five tell you whether it knows your product. People who know the trade look at the hard ones first and ask you questions. People who only know their own product configure the five easy ones and show you the 3D model.
Week two: the same questions for everyone
Ask every vendor in the same order, so the answers can be compared. What the total cost is in year three, with the users and families you will have in three years. Who models the rules after setup, and what a day of modelling costs. How a sizing rule with a calculation is expressed, not a compatibility table. How the bill of materials reaches the ERP I have, naming the product and version, and who builds the connection. How an agent works with no connection, in a building where the phone has no signal. What happens if I stop after three years, in what format my rules come out and what extraction costs. And whether I can talk to two companies like mine, without the salesperson present.
The most informative moment is when you ask for something off script and watch how they react. Someone who knows the product tells you straight away that the rule cannot be expressed that way and how to work around it. Someone who does not, promises, and then files a development request after signing.
Week three: the test on quotes already made
This is the test I always recommend and almost nobody runs. Give the vendor the family's rules, as your engineering office describes them, and ask them to model it just enough to redo the ten quotes. Then compare prices and bills of materials with the real ones, and have the engineer who knows the product best check the result: how many of those configurations could really have been built that way.
It is not a feature test, it is a method test: you watch how many questions they ask before modelling, which rules they discover nobody in the company had ever written down, and how long it takes. Also ask that a rule change be made in front of you by someone from your engineering office, not by the vendor. If the ten quotes come back right and the engineer can change a rule alone, you have found your vendor. If they do not, you have found where the problem is before paying for it, and the problem is almost never the rules engine: it is a rule only one person in the company knows.
The three things to fix before buying anything
There are three jobs that cost little, take a few weeks and without which any product configurator delivers half its value: making the product family's bill of materials modular, writing the rules in a table, and choosing the five numbers you discuss. Do them before, not after, because after the project has started the rules are decided by whoever models them, meaning a consultant who has never seen your product being built.
The modular bill of materials. Instead of a new code for every combination sold, the product family should be described as a set of modules and variants: the frame in three materials, the belt in eight widths, the motor in five power ratings, the control panel in two versions. Every quote becomes a choice of modules, not a drawing. It is the most demanding of the three jobs, it needs engineering for a few weeks, and on its own it produces part of the result, because duplicate codes stop being created even before the configurator arrives.
Rules written in a table. Compatibility, sizing, limits and price, written in plain language in a shared document, one rule per line, with an example of a real quote that respects it and one that breaks it. Engineering validates them, sales reads them, and at that point you have two things: the specification for any configurator, and a document that on its own reduces habitual steps, because salespeople stop asking what they can now read.
The five numbers you discuss. Pick five indicators and stop there for a year. In most companies selling variable products these work: engineering share by family, average days from request to quote, win rate by response time band, configuration errors per hundred orders, and the gap between the margin quoted and the margin achieved at job close. Five numbers looked at every month change the way you sell; twenty indicators on a dashboard change nothing, and by the second month nobody looks at them.
I will add a way to start that is not a job but a choice: begin with one family only, the one with the most quotes and fewest exceptions, and run it for two months with the internal sales office before giving it to agents. Companies that start with the whole catalogue and the whole sales network at once reach month three with agents back on the spreadsheet and an engineering office correcting the system's configurations. The second attempt is much harder, because by then everyone knows the thing did not work.
If your total of the five items was below thirty thousand euro a year, here is your most urgent problem: these three jobs, not software. Do them, measure the engineering share again after six months, and only then look at products.
Where to start
You start from a small first release, because a product configurator is not an IT project: it is a project that moves a decision from engineering to sales, and decisions move well when few move at a time. The first release that almost always works is this. One product family only. Compatibility and sizing rules in tables engineering edits on its own. Price computed with markups and a discount limit above which approval is needed. The quote document. The bill of materials sent to the ERP without retyping. A single report, on the first Monday of the month, with the engineering share, average response days and configuration errors for the previous month. Nothing else.
With that scope you are operational in a few weeks with a product, in two or three months if you build custom. From then on you repeat the engineering share measurement every month. If it goes down, the project is working. If it does not, the problem lies in the rules, in a bill of materials that is not yet modular or in a salesperson who does not trust the system, and no extra feature will fix it. Everything else, agents with tablets, the dealer portal, the 3D model, drawings generated from CAD, is built on top of rules you can trust, and it costs less because by then you know what you really need.
The conveyor company's sales director, in the end, bought nothing for the first two months. He had the engineering share measured family by family, locked engineering in a meeting room for three afternoons to write the conveyor rules in a table, and had the bill of materials described as modules instead of three hundred codes. The configurator came later, built around the ERP the company already had, for one family and for the internal sales office. Within six months response time fell from eleven days to two, and the engineering share from sixty two to twenty one per cent. Agents got it in month four. The Excel file with the macros is still in a shared folder, and nobody opens it.
If you are running these numbers now and want to know which side of the threshold you are on before spending anything, send me two pages: your product families, who prepares quotes today and which systems prices, bills of materials and documents come out of, plus the two numbers from the test, meaning the share of quotes that went through an engineer over the last twelve months and the average days between request and sending. In half an hour I will tell you whether yours is a problem of rules to write, of a bill of materials to modularise, of a subscription product, of the ERP module you already own or of a custom build. When the problem is the product and not the software I will tell you that too, because a customer who buys the wrong thing comes back angry. You can get in touch to run those numbers together.
If instead you are still framing the problem, three reads sit around this one. What happens after signing, meaning how the configuration sold becomes a production plan with a real date, is in production management software. The true cost of each job, compared with the margin you put in the quote, is in job costing software. And if you want to know which product families really make you money before deciding where to start, the answer is in management control software.
Frequently asked questions
It depends on the route. The configurator module of the ERP you already own costs between ten and forty thousand euro, almost all configuration. A specialised subscription product costs between sixty and one hundred and fifty euro per user a month, plus setup between twenty and eighty thousand euro that is almost all rule modelling. A custom system starts at forty thousand euro for one product family and reaches two hundred thousand with several families, a dealer portal, 3D visualisation and a CAD connection, plus fifteen to twenty per cent a year in maintenance.
A 3D configurator answers what the product looks like: shapes, colours, finishes, often for dealers, trade fairs and online sales. CPQ, short for configure, price, quote, answers whether that combination can be built, what it costs and how the quote is written, and in the best cases it also generates the bill of materials for production. 3D shows the product, CPQ knows whether it can be made, and only CPQ takes quotes off the engineering office's desk.
Take the list of quotes from the last twelve months with request date, sending date, product family and outcome, and mark for each whether it went through an engineer, using internal requests, email or timesheets. Quotes with an engineering step divided by total quotes give the share. Then redo it separating necessary steps, meaning those with something never built before, from habitual ones: the gap between the two shares is the part a configurator can recover.
Yes, if it knows the real rules. Impossible combinations, undersized motors and mistyped dimensions disappear when compatibility and sizing rules live in the system and the bill of materials comes out of the configuration without being retyped. But a configurator with badly written rules produces errors faster and more confidently than before. The test is to reconfigure the last fifty orders produced and compare price and bill of materials with what was actually built.
When at least three of these five conditions hold: quotes are prepared by more than six or eight people or by an external agent network, the price list changes more than twice a year, only one person can use or change the file, the quote has to be retyped by hand to become a bill of materials and a production order, or different versions of the file are in circulation. With two conditions you are at the limit and have time; with none or one it is better to stay where you are, measure the engineering share and write down the rules.
With three jobs that come before any purchase: a modular bill of materials for the product family, meaning modules and variants instead of a new code for every quote; compatibility, sizing and pricing rules written in a table and validated by engineering; and five indicators kept unchanged for a year. Then a small first release on one family only, used by the internal sales office, with price, quote and bill of materials sent to the ERP. Agents come after two months, dealers and 3D later still.
Below twenty five thousand euro a year of total spend the product or the ERP module almost always wins. Custom makes sense in three cases: when the rules of your product are your competitive advantage and no product expresses them without forcing; when the generated bill of materials has to enter an ERP and a CAD that no product connects without costly customisation; and when the ERP you have works and should be kept, building the missing part around it. With twelve users the break-even between the two routes usually falls between year three and year four.
