Field note
Four quotes that did not add up, and what each one taught us
In some trades the quote is not a document about the product. It is the product. Four times this year, in three systems we built, it was wrong, and every time the arithmetic was fine.
By Eugene Romanov·Published
The short answer
In trades where the price is calculated from measurements, the quote is the product, and it fails in a particular way: the arithmetic is right and the number is wrong. Four defects from three systems we built show the pattern: a room switched off but still charged, totals rounded separately, one commission read two ways, and payment terms present in the link and missing from the PDF.
SHT-02Field note
When the quote is the product
A wall-covering installer, a sauna builder and an auto broker have one thing in common. Before anyone can say yes, someone has to turn measurements, options and terms into a single number, and that number is what the customer is buying. Get it wrong and nothing else in the system matters. These four defects are from three such systems, all built by us and all in production, and each is in a public build log with the commit that fixed it.
1. The room that was switched off and still charged
In WallFlow, our own estimating product for wall-covering installers, an estimate is a set of rooms, and a room can be switched off without being deleted. The calculator filtered walls by their own flag and never checked the room's, so a disabled room's area, panels, rolls and money all went into the totals. The printed document made it worse: it showed only the enabled rooms and totalled all of them. Every line of the arithmetic was correct. The question it answered was not the one the customer asked. Fixed in 24c8fff, 19 August.
2. Total, Paid and Balance that did not add up
In the auto broker's system, the buyer's page rounded Total, Paid and Balance each on its own. Each figure was correctly rounded, and the three visibly failed to add up in front of a car buyer. The same week we counted fourteen different ways the product printed a dollar, and found one amount shown as 612.5 on one screen and 613 on the next. We demonstrated the mismatch on a scratch deal of our own before fixing it in 32ef950 and b9b5a4e, and deleted the deal afterwards.
3. One commission, two rules
The same system's dashboard resolved a percentage commission against the gross amount owed, while every other screen used the base after costs. Two adjacent screens showed two different numbers for one deal, and both were faithful to their own rule. The rule now lives in one place, the database, and every screen receives the dollars with the row instead of working them out again (62de441).
4. Terms in the link, missing from the PDF
In the sauna builder's system an estimate exists twice: as a link the client opens and as a document they download. The payment terms appeared in the link and were missing from the document. One fact, rendered twice, disagreeing (438ad72). Closing the hole that let it through turned up five more places where money was printed badly, including a total sent to a phone without its cents (17b4ae8).
The pattern
None of these was a sum done wrong. Each was a fact computed or printed in two places, where the two disagreed: a flag on the wall and a flag on the room, three roundings instead of one, a rule in the dashboard and another everywhere else, a template for the link and another for the PDF. A test of the function passes in every one of these cases, because the function is right. What is wrong is that there are two of them.
What we do differently now
Anything a customer pays is computed in one module, and every screen and document goes through it. Money is formatted by one function, and a guard test fails the build if a file formats it any other way. And a change to a quote is checked on the rendered document the customer will actually receive, not on a passing build, because three of these four were only visible there.
A check you can run on your own quotes
Take one real estimate and open it in every form a customer can see it: the link, the PDF, the text message, the invoice. Read the total, the deposit and the balance from each one. If any two disagree, by a cent or by a line, you have the defect this note is about, and it is already in front of your customers.
SHT-04FAQ
Questions this post answers.
- N01Does an off-the-shelf CRM have the same problem?
- It can, in a different place. A general CRM usually leaves the calculation to a spreadsheet or to the person typing the quote, so the second copy of the rule lives in someone's head. The defect is the same: one fact, two places. A system built for one trade can put the rule in one place because it knows what the rule is.
- N02How do we know these are real?
- Each one is a row in a public build log on this site, dated and naming the commit that fixed it, from three systems in production. The logs leave out the clients' own figures and names, by a rule written down before the first row was chosen.
- N03What is the smallest change that prevents this?
- Pick the one number customers pay, find every place it is computed or printed, and make all of them read it from one place. That is usually a smaller change than it sounds, and it removes the whole class of defect rather than the one instance you noticed.