Sooner or later, a rule change will turn out to be wrong. A price is entered in the wrong currency, a dependency is too strict, a part number pattern breaks for one size. That is not a failure of the people involved — it is what happens when products change every week. The real question is how far the damage spreads, and how fast you get back.
Every change is versioned
A quotation was produced under the rules as they stood on that day. If you cannot reconstruct that version, you cannot explain to a customer why their price was what it was — and you cannot tell whether a complaint is about the product or about the rule.
Each stored configuration should carry these three things. Without them, a stored configuration is only an approximation of what you actually sold.
Rollback in minutes, not a backup restore
Ask specifically about rollback. Reverting a faulty update should take minutes and should not require restoring a backup of the whole system — with everything else that was changed since then.
The scope matters as much as the speed
It should be possible to update — and roll back — a single product series or a single component on its own, without the whole system going through a release.
Whole-system release
Every change waits for the next release of everything.
Release per series
Each series moves on its own schedule.
If every correction means a full update, small fixes wait for the next release window, unrelated changes travel along with them, and a mistake in one series forces a rollback of all the others.
Why large rollouts get postponed
Whoever still thinks in large data rollouts will keep postponing them. When every release is big, risky and expensive, the natural response is to make fewer of them — and the configurator falls further behind the actual products with every month that passes.
Small releases per series reverse that logic. Each one is cheap, easy to check and easy to undo, so there is no reason to wait.
A fast path, agreed in advance
A planned release cycle is usually right. But there should also be a defined fast path for corrections — agreed before go-live, not improvised the first time a wrong price reaches a customer.
What to ask before you buy
- Is every rule change versioned — with who changed what, and when?
- Does each stored configuration record its rule version and price basis?
- How long does a rollback take, and does it need a backup restore?
- Can we release and roll back one series without touching the others?
- What is the agreed fast path for an urgent correction?
These are questions 5 to 7 of our buyer’s checklist for product configurators, together with question 22 on release cycles. How changes are approved before they reach this point is covered in Who Owns Your Product Rules?