The fastest way to kill data maintenance is a slow loop. If checking a single price change means writing a ticket, waiting for the supplier and testing by hand three days later, people stop changing things — and the configurator quietly falls behind the products.
The loop that keeps data alive
The flow should be this short: you make the change yourself, push it to a test system, and create a quotation with it straight away. You see the effect on price, part number and documents within minutes — before anything reaches production.
- ChangeA price, an option, a component — yourself2 min
- Push to testStaging with current production dataInstant
- Test quotationPrice, part number, documents — as the customer would get them1 min
- Impact reportEvery existing configuration checkedSeconds
If this loop takes days and runs through the supplier, nobody maintains the data.
Three environments, not one
Changes tested against live data are changes tested on your customers. Three environments are the working minimum:
Ask whether staging really holds current production data. A test system with last year’s prices proves nothing. And keep in mind what three environments mean in-house: three systems to buy, patch and keep in sync — in practice, staging is the first one to be cut.
Test everything, automatically
Manual testing does not scale past the first few updates, and it is the first thing to be skipped under pressure. Two things should run automatically before every release:
The first catches a rule change that breaks an existing configuration. The second catches a release that breaks the quotation itself. Neither depends on someone remembering to test.
See the impact before you approve
Running the new rules against every existing configuration and reporting the differences takes seconds for a machine and is impossible by hand. Without it, approving a rule change is an act of faith. With it, the approver sees something like this:
The decision stays with a person. But it is an informed decision, made with the facts in front of them — not discovered later in a customer’s quotation.
What to ask before you buy
- Can our own people change data, push it to a test system and create a quotation from it straight away?
- Are development, staging and production separate — and does staging hold current production data?
- What is tested automatically before every release?
- Can we see what a rule change affects across all existing configurations before we approve it?
- How long does the whole loop take — from change to released quotation?
These are questions 13, 17, 21 and 23 of our buyer’s checklist for product configurators. What happens when a change still turns out to be wrong is covered in Roll Back One Series, Not the Whole System.