Do not transfer chaos into any software
If a company has five price lists, three spreadsheets and ten rules that exist only in people’s heads, entering everything into software will not automatically create a good system. It will simply give the chaos a user interface. Start by mapping what is sold, what each product consists of and which choices change technical feasibility or price.
The aim is not to develop proprietary software, nor to introduce the most complex solution on the market. It is to create a structure clear enough to select a proven professional solution that fits your business — and implement it to the extent you need.
1. Build a product hierarchy that sales understands
Separate windows, doors, sliding systems and accessories, then profile systems, models and construction types. Names should be stable enough to work in both sales and configuration. If the same product has three internal names, resolve the synonyms before automating them.
A useful hierarchy does not have to copy accounting or warehouse codes. It should follow the way a user makes decisions while assembling a quotation.
2. Separate base prices, surcharges and rules
For every price component, identify whether it is a base price, linear-metre item, area item, piece price or percentage surcharge. Then define the condition that activates it. A dark colour may add a surcharge and at the same time require different reinforcement; those are two different types of rule.
When price logic and compatibility are not buried in one formula, a professional solution is easier to configure correctly, test, maintain and explain to sales.
3. Document exceptions before implementation
Standard cases are usually quick to model. Time is lost on exceptions: a maximum size for one combination, a different threshold, safety glass above a certain area, hardware that cannot be combined with a certain handle. List those rules and identify who has authority to confirm each one.
If the team disagrees about a rule, that is not a software problem. It is useful evidence that the current business process does not yet have a single answer — and should be aligned before configuration begins.
4. Keep services, discounts and commercial logic separate
Installation, removal, transport and finishing may follow completely different logic from the manufacturing price. The same applies to customer discounts, margin and commercial corrections. Separate layers allow the technical calculation to remain stable when commercial policy changes.
Define whether a discount is visible to the customer, whether it changes displayed unit prices and which items it applies to. A small ambiguity here can create a large difference in the quotation total.
5. Prepare real quotations to validate the solution
Before deciding on and launching a configurator, select ten to twenty representative quotations: a small window, large portal, colour surcharge, special door panel, several glass packages, installation and a few exceptions. Agree the expected price and specification for each case.
These examples help you verify whether the selected solution correctly covers everyday work and later check price-list or rule changes safely. That is far safer than judging it by clicking around until the result “looks right”.
Start with what you genuinely need
Not every company needs a complex system, and there is no need to model every historical edge case before the first use. Start with the products that represent most sales, stabilise the flow from configuration to quotation, and then add rarer variants when there is a business need.
A well-chosen configurator is more than a price calculator. It becomes a shared language for sales, engineering and management — the place where the company can see what it really sells and under which rules. If you would like to see whether Okvir.io can simplify this work and save your team time, the right next step is to test it with your own quotations.
