A configurator-to-quote chain turns a stated requirement into a priced quote line, so the figure an engineering calculation produces is never retyped anywhere. What makes that possible is the order records are born in: a cart line arrives already carrying the project it belongs to. There is a limit as well: a company that never standardized its method has no single calculation to embed, and its first job is agreement rather than software.
The person writing the quote is not the person who ran the calculation
Resterm manufactures electric heaters. Choosing the right unit in that product family takes an engineering calculation. The calculation itself is not the hard part. The hard part is where it lives, and it lives in a person. The colleague who prepares a quote is usually not the colleague who runs the numbers, so every quote begins with a wait.
That wait looks like a communication problem from the outside. It is not. It is the direct consequence of knowledge sitting in one head. When the specialist takes leave, or several quotes come in on the same morning, or a different job already owns their afternoon, sales does not stop. It slows, and while it slows the quality of the number drops, because a figure produced in a hurry gets corrected later.
There is a second face to the slowdown that nobody measures: the quotes that never get written at all. As the queue lengthens, the smaller jobs quietly fall off it. No one records that as a loss, because a quote that was never produced leaves no trace anywhere. The cost of a specialist bottleneck is therefore never just the quotes that arrived late.
The first remedy most companies reach for is training. Someone explains the logic to the sales team and writes a guide. The guide works for a while. Then the product range widens, or the method is revised, and the guide becomes a second thing that needs maintaining. A written document does not break the dependency on the specialist. It adds another object that goes stale.
What broke the dependency was moving the calculation into the software. The user enters a heating requirement, and the software runs the engineering calculation and picks the matching electric heater. The specialist does not disappear from the process; their role moves. They are now involved when the rule behind the calculation changes, not on every individual quote.
The counter-case deserves to be written plainly. If the method has never been standardized inside the company, if every engineer works from their own approach, then there is no single calculation to embed. In that situation the first job is not software but agreement. Software does not produce a standard; it replicates the one already in place. Encoding an unsettled method just declares one person’s habit to be company policy.
Three records living in three separate places
Before the software existed, the links of the chain never looked at each other. The engineering figure was worked out in a spreadsheet. Product information sat in a document of its own. The quote was assembled somewhere else again. Each of those three places worked perfectly well on its own, which is exactly why nobody treated the arrangement as broken.
The mechanism behind the disconnect is not the number of files. It is the absence of any reference between them. None of the three records knows the others exist. What stands behind a line on a quote becomes invisible the moment the document is closed, and that invisibility is not a search problem: there is no field to search.
The bill arrives at revision time rather than on the first quote. When a customer asks to increase capacity or trim the scope, nobody can tell which input produced the current figure, so the calculation is run again from the beginning. The second quote is built on nothing rather than on the first. As revisions accumulate, that cost compounds: every round demands its own fresh calculation.
The second cost shows up in justification. When a customer asks where a number came from, the answer is held by the person who produced it rather than by the record. Even when that answer is right, the company cannot demonstrate it. A justification that cannot be shown is the weaker side of any negotiation.
The most deceptive property of this arrangement is that it causes no trouble day to day. While the person who runs the calculation is at their desk, the chain completes invisibly; the missing link is that person. The system appears to work because a human closes the gap by hand every single day. The gap only surfaces when that human is away, and that moment is rarely a convenient one.
The brief for the build can be written as one sentence: hold the engineering calculation, the product choice and the quote record on one chain. That is not an integration task, it is a foundational decision. Integration ties three separate systems together, and every tie needs its own maintenance; when one of them fails quietly, nobody notices for weeks. A foundational decision makes all three records come into existence in the same place. There is no tie to break, because nothing lives apart.
The chain starts when the input is a requirement
The first question a sales application asks tells you what kind of application it is. The conventional version asks for a product code or a model name, and that request carries a hidden assumption: the buyer already knows what to buy. For engineered products the assumption is usually wrong. The buyer does not know which unit they need. They know what they need it to do.
In the Resterm software, which sizes a heater from a stated heating requirement, the first link of the chain is the requirement itself, recorded as a record. The user types no code. They state a heating requirement, and the software runs the engineering calculation from that input and selects the matching electric heater. The step where somebody searches a catalog disappears from the flow entirely.
Reversing the input changes what the catalog is for. It stops being a surface people browse and becomes the data the calculation selects from. The user does not find the product; the software derives it. The gain is not only ease of use, it is where responsibility sits: when the wrong unit is chosen, the thing at fault is a rule rather than a colleague. A rule is an object you can correct.
The price of that arrangement is that the software has to genuinely understand how the manufacturer structures its products. We built the application on Resterm’s own product structure, and the calculation runs on top of that structure. Laravel runs the server side, Vue drives the interface, MySQL holds the records. The stack stayed small because the difficulty of the work was never scale: it was fitting the calculation correctly onto the product structure.
There is a customer-facing side to this choice as well. Once catalog browsing leaves the flow, the shape of the sales conversation changes. It no longer opens with which model would you like. It opens with how much heat for how much space. The buyer is not asked to pronounce a code they have no reason to know; they describe the thing they do know. By leaving the product name to the very end, the software makes the subject of the conversation the requirement rather than the product.
The counter-case matters here more than anywhere else in this article. Where a product is chosen by preference rather than by calculation, as with color, scent or design, a requirement-driven chain cannot be built at all. In that world the input is the product itself, and buyers recognize what they want by looking at it. Building a calculation step into that kind of catalog means writing an engine for a question nobody asked.
Selection to cart, cart to project, project to customer
Having the calculation pick a product is half of the chain. The other half is how that selection becomes a commercial record. In the Resterm application the heater chosen by the calculation drops into a cart; the cart belongs to a project, and the project belongs to that project’s customer. The records sit on one chain in MySQL.
The detail that carries the weight is when the link is formed. It is not a reconciliation performed afterwards; it is the address the record carries from the start. A cart line does not exist without knowing which project it belongs to. In systems where matching happens later, unmatched records always pile up somewhere, and one day a person cleans that pile by hand. When the link is formed as the record is created, the pile never forms.
Direction matters too. A cart line attaches to a project; a project does not attach to a cart. Built the other way round, the question of which lines belong to a given project could only be answered by scanning every cart. Because the record carries its own ownership, the quote screen produces the list rather than hunting for it.
The result reads in two directions. Forward: nothing is retyped between the technical selection and the commercial line, and the output of the calculation becomes the quote line directly. Backward: any quote can be read back to the heating requirement that produced it. The backward direction is the more valuable one, because complaints, revisions and price objections all ask the same question in reverse.
The principle is not confined to a sales flow. In AlgoCar, where the work order, the parts it consumes and the invoice run on one chain, a part is taken out of stock the moment it is booked to the job, and the invoice is issued from that same record. Nobody re-enters the movement on a separate store screen. AlgoCar is our own product rather than a client build. The industries differ; the rule that carries over is the same: an operational record becomes a commercial line without being carried by hand.
Where these links sit is a data-model decision rather than a screen decision. In the ERP work we take on, holding quote, project and customer records in one core, the first thing we write is never a screen. We write down which record is created underneath which. Screens get redrawn later; the links do not.
When the selection sets the price, what does the flow carry
For some products the price does not sit anywhere waiting to be read. It comes into existence when a choice is made. Automotive is the most visible example: what gets sold is not a stock item but the outcome of a configuration.
In the KGM SsangYong online sales channel, where trim and color decide the price, every combination of trim and color carries its own price, its own image and its own sales terms. When a visitor changes one choice, the price and the vehicle shown on screen update together.
For flow design the real question is what moves from one step to the next. Move a product code and the information arrives incomplete: a code says nothing about which combination was chosen or why the price is what it is. So what the flow carries is not a code but the record of the selection. The chosen combination is stored with its own sales terms, and that record is what travels to the next step.
The choice also changes where a price is stored. It does not live on a single product row; it lives on the record of the combination. When the sales terms of one combination change, the thing you touch is that combination’s own record rather than a product card. Changes happen at whatever level the record is kept, and if the level were wrong, a single terms change would mean touching the whole catalog.
The practical payoff shows up in a price objection. When a visitor sees a figure at checkout that differs from what they expected, where the difference came from can be read off the record. Had the price traveled as nothing more than a number, explaining the gap would once again fall to a person with a good memory.
The opposite end of the spectrum sits in the same portfolio. In fragrance retail, price and stock live on the record of the sellable unit itself, and there is neither a calculation nor a configuration step in the purchase. The shopper picks a bottle size and the price comes off that size’s record. Importing this flow pattern there would mean opening a screen for a step that does not exist.
Configurator and checkout as two steps of one flow
The most expensive place for a chain to break is the handover between choosing and paying. By that point the visitor has already decided, so everything lost at that seam is a decision that had already gone your way.
In the SsangYong sales channel, payment opens as a continuation of the configurator. The visitor moves into the purchase step without leaving the car they configured, and the selection stays in the same session. There is no handshake between two systems; there are two steps of one flow.
Describing what a gap would have caused is worth the paragraph, because in a working flow the risk is invisible. Had configuration lived in one place and payment in another, the visitor would have rebuilt the chosen car on the payment side. Re-entering data is not a comfort problem here, it is a mechanism for losing sales. Someone choosing for a second time often does not make the same choice twice; they abandon the purchase or postpone it.
There is a boundary to this integration, and it should be stated. The payment step answers to the rules of a bank and a payment provider, and we do not set those rules. One flow does not mean absorbing the payment step into our own code. It means the configuration the visitor built arrives at that step intact. The boundary is not where data is stored, but where it gets asked for a second time.
On the technical side this continuity cost nothing extra. The sales channel runs on the same Laravel, MySQL and Redis set as the brand’s corporate site, so both sit inside one maintenance skill set. There is no second stack to learn and no separate deployment path to build. This is what choosing one stack you can maintain for years, instead of a new one per project, looks like in practice.
We build cart and checkout flows in our e-commerce work in this order every time: first we write down which record travels from one step to the next, then we draw the screens. Reverse the order and each screen works correctly on its own while information leaks in the transitions between them.
How far a general-purpose quoting tool gets you
Every section so far describes a purpose-built flow, which invites a fair question: would loading a catalog into a ready-made quoting tool not produce the same outcome?
It would not, because a catalog upload moves the product list and leaves the product structure behind. Inside a generic tool a catalog is a list, and the calculation step stays outside the tool. The moment the calculation is outside, the chain is outside too: the user still works out a figure in a spreadsheet and types the result into the tool. The tool changed; the manual carry did not. That is why we built the Resterm application on the manufacturer’s product structure.
The same boundary appeared on the e-commerce side. Off-the-shelf carts do not carry a trim-and-color breakdown, and price stays tied to a single product record. The assumption inside a ready-made tool is explicit: price lives on the product record. Once price comes out of the selection, that assumption is broken, and working around a broken assumption gets more expensive than not using the tool.
The counter-case is equally clear. Where the catalog is small, price lives on the record of the sellable unit and no calculation is needed, a ready-made tool is enough. In the Kokudankokuya store, where each bottle size is its own sellable unit, the scale of the catalog called for no separate search or cache layer, and the store runs on Laravel and MySQL. A stack reduced to two components is the evidence that at this scale the correct answer is a small one.
The table below puts the four builds side by side against the same three questions: where the amount comes from, what the sales record reads back to, and which duplicate data entry the chain removes.
| Project | Where the price or amount comes from | What the sales record reads back to | Duplicate entry removed |
|---|---|---|---|
| Resterm heater selection software | The product chosen by an engineering calculation run on a stated heating requirement | A quote line, back to the heating requirement entered | Copying the calculation output into the quote document by hand |
| KGM SsangYong Online Store | The chosen trim-and-color combination, each with its own sales terms | Payment, back to the configuration record carried in the same session | Making the visitor rebuild the chosen car at the payment step |
| AlgoCar service management | The work and the parts booked to the work order | The invoice, back to the work order record that opened the job | Typing parts consumption a second time on the store screen |
| Kokudankokuya | The price held on the record of the sellable unit; no calculation step | A sale, back to the bottle size record; the scent stays one record | Opening a new catalog product for every new bottle size |
The last column is there on purpose. The value of a chain can only be measured by the duplication it removes. If you cannot write anything into that column for your own business, you do not need the chain. If you can, that duplication is coming out of somebody’s working day right now.
