Three of the customer's own quotations told me more than the requirements call did
The quoting system produced a correct quotation that the business could not send.
Every number was right. The engine had priced 30-odd bespoke items from their own formulas, applied the discount, applied the tax. And it laid the result out as a generic quotation document, which is not what their customers receive, not what their customers’ purchasing departments expect to file, and not something a salesperson would put their name on.
The fix was not a design exercise. I asked for three of their real quotations and read them.
What three documents were worth
The three were deliberately different: a long priced quotation running to eight pages and over 60 line items, a bill of quantities with no prices at all, and a short two-page quote.
That set answered questions that a requirements conversation had left ambiguous, because a conversation produces what people remember about their process and a document produces what their process actually does.
Lines are grouped by area, under a bold header. Preparation area, wash area, store area, plumbing. Not by product category, not by the order things were configured — by where in the customer’s building the equipment goes. That is a grouping the software had no concept of.
The first column is not always a number. One document used a running sequence. Another used short alphabetic keys derived from the section — a two-letter section prefix and a number. The keys exist because the site layout drawings reference them, and a fitter on site matches the key on the drawing to the key on the quote.
That single observation turned an ambiguous request into a settled design: keys default to the section initials plus a running number, they are editable per line, and plain numbers remain available, because two of the customer’s own documents disagreed with each other about which to use. If the source documents are inconsistent, the feature is configurable. That is not a compromise, it is the requirement.
Every item has a specification row underneath it. Smaller type, left aligned, listing the grade and the sheet gauge of each component — top, bowl, legs, undershelf, covering, doors. This is the technical substance of the quote and it is what distinguishes a serious fabricator from someone guessing.
It is also almost entirely derivable. The system already knows the grade and the material chosen for every slot on every feature of that line. The specification row is a rendering of data it holds. That was the largest piece of unclaimed value in the entire document.
Dimensions are printed with an additive notation. Not just length by breadth by height, but a trailing addition marking a collar or a splashback allowance, and on an overhead shelf, two of them. A generic three-number dimension field cannot express that, and printing the raw numbers would have looked wrong to every reader who knows the trade.
Some items have no dimensions at all, showing a standard marker instead, because they are bought-in branded units rather than fabricated ones. The document handles fabricated and non fabricated lines in the same table with different content, which is exactly the free-text line the system supports — but confirms it must print in the main table rather than in a separate section at the end.
One section restarts its own numbering and lists consumables with individual rates and quantities, which is a different kind of line again.
The two arguments it settled
Transport, unloading and installation appear as their own line after the item total. On the review call the business had said this is charged after discount and before tax, with tax computed on the total including it. The document confirmed the position and the wording.
And in the long quotation, tax was not applied at all. It was stated as extra as applicable, and left for the customer’s own accounting to add.
That second one is the more consequential finding, because it means tax handling cannot be a company-level setting. The same business, in the same year, sends quotations with tax computed and quotations with tax declared and not computed. It is a per-quotation choice, and if it had been modelled as a company configuration the very first real quote would have needed a workaround.
I would not have found that by asking. Nobody describes their own exceptions when summarising their process. They describe the common case and genuinely believe it is the whole case.
Keeping the change cheap
The thing that kept this from becoming a large piece of work was an assumption written down explicitly before starting: sections and line keys are display and organisation only. They have no effect on pricing, on totals, or on anything the engine does.
That assumption is what let sections be added without touching the calculation path at all. A section is a label a line carries and a grouping the renderers respect. The pricing rollup sums the same lines in the same way it always did, regardless of how they are grouped for display.
It is worth stating an assumption like that in writing at the point you make it, because the alternative reading — that sections might eventually carry their own subtotals, their own discounts, their own tax treatment — is entirely plausible and would have been a much larger build. Naming which one you are building prevents a scope argument later, and if the business does want section subtotals eventually, that is a new request with a new estimate rather than a claim that it was always implied.
Three renderers, one assembler
The same grouping and the same keys had to appear in the printed document, in the spreadsheet export, and on screen in the review step.
They come from one assembler that produces the export context, consumed by all of them. This is the same reuse that keeps the redaction consistent on the public link, and the argument is the same: three renderers with their own idea of how to group lines will drift, and they will drift silently, because nobody opens all three outputs of the same quote and compares them.
The rule
Before designing any output a business sends to its customers, ask for three real examples — and insist on more than one, because the variation between them is where the requirements are hiding.
Read them for structure rather than styling. Then look at every element that carries information and ask whether the system already holds the data to produce it. The specification row nobody had asked for was the single most useful thing in that document, and it was already in the database.