By Artem Korsakov ·
Consider a client inquiry: an air handling unit is needed for a warehouse, the area and approximate airflow are known, and there is a requirement to operate in winter. The manager can promise a response time but cannot assemble the equipment configuration alone. They forward the email to an engineer. The engineer clarifies parameters, selects a fan, heater, filters, and automation, and returns the list. The manager transfers the composition into a quote template, adds prices and discounts. The client changes one condition, and the cycle repeats.
Each step individually looks reasonable. Delays accumulate from handovers between people, and the actual calculation takes up less than half of the journey.
Where time is lost
If we break down one inquiry into steps, there are usually five handovers:
- The manager receives the inquiry and sees that there is not enough data for selection.
- The engineer asks clarifying questions, the manager forwards them to the client and waits for a response.
- The engineer selects the composition and checks the compatibility of components.
- The manager transfers the composition into a quote, calculates the price and agrees on a discount.
- The client asks to change a parameter, and compatibility checking starts over.
At each handover, the inquiry sits in someone else's queue. The engineer is busy with a current project, the manager agrees on discounts by evening, and the client responds the next day. Even if the selection takes an hour, the path to a quote stretches over days.
Подпись: Illustrative example. The selection itself takes an hour, and together with clarifications and approvals about three hours. The rest of the time, the inquiry waits in others' queues.
The second problem is repeatability. Two managers with the same inquiry may issue different quotes because they asked different engineers or used different old files as templates.
Why rules live in heads
Selection relies on rules known by the engineer. Which heater is not paired with which fan. When protection for a heat exchanger against freezing is needed. Which filters are mandatory for the room class. Which combinations are technically possible but not produced. Some of these rules are recorded in a catalog, others are scattered across old emails, and some are not recorded anywhere.
As long as rules are not written down, the manager cannot check the configuration alone. They do not know which combination is strictly forbidden and which is permissible after an engineer's check. Therefore, everything goes to the engineer, including typical inquiries where the solution is obvious.
Configuration systems build work on explicit rules. For example, Tacton describes constraint-based configuration: permissible combinations are defined by rules, and an incompatible option cannot be assembled. This means such a class of solutions exists. Whether it suits a specific company depends on whether their rules are written down.
What changes when constraints are recorded
When compatibility rules are moved from an engineer's experience into a system, work is divided differently:
- The manager assembles typical inquiries themselves; the system does not pass incompatible options;
- Engineers receive only non-standard cases and resolve them with recorded justification;
- Quotes are formed from verified compositions, without retyping emails;
- A parameter change by the client immediately shows what else needs to be changed in the composition.
Constraints are of two types, and it is useful to distinguish them from the start. Hard constraints cannot be bypassed: physically incompatible components, executions not in production. Soft constraints can be lifted by an engineer: non-standard power reserve, rare option combinations. If a system mixes these types, it either forbids too much or allows errors.
A configurator does not replace an accounting system. Nomenclature, prices, and production remain where they are currently managed, for example in a production management module of 1C (a Russian accounting and ERP platform). The configurator takes reference data from there and returns an approved specification. The exchange order is determined during implementation.
Check: where your calculation gets stuck
Take the last ten quotes and answer the questions. Answers will show whether there is sense in recording rules.
- How many compositions did the engineer select from scratch, even though a similar one already existed?
- How many times did the client change parameters after the first quote and how many days did each repetition take?
- Can a manager without an engineer say whether a combination of two options is permissible?
- Is there a recorded list of forbidden combinations, or does it exist only in employee experience?
- Would quotes from two managers match for the same inquiry?
- Where is it recorded why an engineer allowed a non-standard option?
If the answer to questions three and four is "no," the bottleneck lies in the rules. Speeding up email forwarding is pointless in this case: the engineer will remain the only one who can say "this works."
Where to start
The first step does not require choosing a system. A list of rules for one product line is needed: which parameters the client sets, which components depend on them, which combinations are forbidden, and who resolves exceptions. The list will be useful for any option: a ready-made configurator, modification of an accounting system, or custom development. It is also convenient to use when training new managers.
The list should include roles as well. Who accepts the inquiry, who has the right to grant a discount beyond standard, who approves non-standard compositions, and who sends quotes to clients. If there is no responsible person for any step, the inquiry will wait there the longest. It is useful to note data sources as well: where prices come from, where the current list of executions is located, and who updates it. Without this, even well-written rules quickly diverge from what production actually releases.
In a demonstration scenario, one can trace the general chain: the configurator does not pass an incompatible combination, a non-standard option goes to an engineer for resolution, the client receives a specific version of the quote and confirms exactly that one.
Continuation of the topic: From client requirements to specification and quote: how equipment configurator works.
Sources and scope of example
Sources confirm the described functions of ready-made products, not demand or payback for custom development. Scenarios and amounts are educational. Demonstrations work with fictional data; real integrations, AI, payments, and external publication are not included in them.