Why Quoting Is Hard to Automate

I have spent the last year building a quoting engine for custom manufacturers. Not a configurator, not a price calculator, not a chatbot that looks up rates. An engine that reads a full bid package, pulls out every requirement with a page citation, surfaces where the drawings and the specification disagree, and drafts the quote in the shop's own pricing logic. The reason why quoting is hard to automate became clear to me about three weeks into the project, when I realized the problem was not the AI. The problem was that quoting has none of the infrastructure that makes AI work everywhere else.

A developer named Matt Pocock recently posted an observation that stopped me in my tracks. He said knowledge work is "SO much harder to automate" than code, because software development has four structural advantages: automated feedback loops, well-organized documentation, version control, and systematized delegation. His post has a quarter million views as I write this. And every single line of it maps, with painful precision, to why quoting custom parts remains manual while code practically writes itself.

The companion piece on quoting custom gangways and docks walks through the nine decisions a bid package never makes for you. This one is about the structural reason those decisions stay with a person, what it would take to change that, and what we have learned trying.

What code has that quoting does not

Before going through the four advantages one by one, here is the summary. Software developers spent decades building infrastructure that makes their own work delegatable to machines. Estimators never did, because there was never a machine to delegate to. The estimator was the system. Understanding this gap is the first step to understanding why quoting is hard to automate.

Each of these deserves a closer look, because the absence of each one creates a specific failure mode for anyone trying to automate quoting.

1. Code has automated feedback loops. Quoting does not.

In software development, you write a test. It passes or it fails. Instantly. A type checker catches mismatches before you even run the program. Continuous integration runs the full test suite on every commit. You know within minutes whether your change broke something, and you know exactly which test failed and on which line.

In quoting, the only feedback loop is: did we win the job, and did it make money? That signal arrives weeks or months later, if it arrives at all. If you lose, you usually do not know why. Was the price too high? Was it a relationship? Did the general contractor go with the incumbent because they have worked together for twenty years? If you win and the job bleeds money, you might not connect the loss to the specific line that was wrong, because by then forty other jobs have moved through the same spreadsheet and the estimator has already overwritten the cell.

There is no red and green signal. There is no "your quote on line 47 was wrong because you read the spec on page 112 as requiring stainless when it said galvanized." There is just: we got the job, or we did not.

This absence has a specific consequence for AI. Without a feedback loop, you cannot measure whether the AI is getting better or worse. You cannot run a regression suite after every change. You cannot tell the difference between an improvement and a regression until a real job goes sideways.

We understood this early enough to build the solution before anything else: the blind test. Set aside ten jobs the system has never seen. Run each one end to end, from package to quote. Compare the system's answer to the estimator's filed quote. The pass bar is agreed in writing before anyone sees a score: seven of ten totals within fifteen percent of the filed number. A package the system cannot process counts as a miss, not an exemption. Scoring happens live so nobody tunes on the test set.

We publish the full protocol at mavlon.co/pilot, including our own failure registry: forty-four classes of mistake we have logged, sorted by kind, with the guard that prevents each one now. It is the quoting equivalent of a test suite's coverage report, and it is the only objective measure that any of this works. Without it, every vendor's accuracy claim is a marketing number.

The most instructive thing about the blind test is that it forced us to define what "right" means. In code, the test either passes or fails. In quoting, a quote that is twelve percent above the filed number might be perfectly reasonable if the estimator knowingly underbid to win the relationship. A quote that matches to the penny might be wrong if it arrived at the right total through cancelling errors, with one line too high and another too low. We score line-level accuracy separately from total accuracy for exactly this reason. A correct total from wrong steps is worthless.

2. Code has well-organized documentation. Quoting knowledge is invisible.

In software, every function has a name, parameters, and a return type. Libraries have documentation pages. Stack Overflow has over fifty million answered questions. If you need to know how to parse a date string in Python, you can search for it and get the answer in three seconds, with working code you can copy.

In quoting, the knowledge lives in five places, and none of them are searchable.

Place one: the Excel formulas. Not the values in the cells. The formulas. This distinction sounds obvious, but it was the single biggest lesson of our first month building a quoting engine. When you open a workbook in normal mode, you see numbers: a unit price of $84, a total of $12,600, a margin of 18%. When you open it in formula mode, you see the actual logic: this cell is that cell times 1.15, that cell references a rate table on a hidden sheet, this one is a MAX function that picks the higher of two vendor quotes. We missed a cost worth tens of thousands of dollars across an entire set of past quotes because it was stacked into a formula that looked like a simple rate cell in values mode. The value said $230. The formula said =$F$12 + $G$47*1.08, which meant the rate plus a second structural member that nobody had told us about. Read formulas, not values. Always.

Place two: the rate corrections from memory. Aluminum went up eight percent last month. Marine-grade 5086 sheet is harder to source from the usual vendor right now, so the estimator is buying from the backup at a premium. The spec calls for a specific brand of hardware, but the estimator knows from experience that the engineer will accept the generic equivalent at half the price. None of this is in the workbook. It is applied as a mental override on the number the formula produces, and if you ask the estimator to explain their number, they will say "I just adjusted it." Adjusted how, by how much, based on what? "I just know."

Place three: vendor relationships. Minimum order sizes. Real prices versus list prices. Lead times that matter for liquidated-damages clauses. Which vendors actually deliver on time and which ones you pad an extra two weeks for. This is competitive intelligence, and no company puts it in a searchable database. It lives in the estimator's phone contacts and in the email threads they never delete.

Place four: spec interpretation conventions. When the spec says "or approved equal," does the consulting engineer actually mean the named brand, or is the phrase there because it was copied from another project's boilerplate? We wrote a separate guide on this question alone because the answer is worth thousands of dollars per project and it varies by engineer, by agency, and sometimes by the day of the week. When the spec says "galvanized per ASTM A123," does the shop hot-dip everything, or do they mechanically galvanize the small hardware? These conventions accumulate over years and are never written down. They are the difference between a quote that the field validates and one that triggers a change order on day one.

Place five: judgment. That general contractor always pays sixty days late, so the estimator adds three percent for carrying cost. That consulting engineer red-lines every submittal on the first round, so the estimator budgets extra review hours. This marine district likes to add scope through "clarifications" during award, so the estimator holds a contingency they do not show. These are not rules. They are patterns that accumulate over a career, and the estimator applies them without thinking about it.

When we started building a quoting engine, we thought the workbooks were the documentation. They are the tip. The documentation is the estimator. And when that estimator retires, the documentation walks out the door. We wrote about this specific problem in how to capture estimator knowledge before it walks out.

3. Code has version control. Quoting rates expire silently.

In software, every change is tracked. Git records who changed what, when, and why. You can revert to any previous state. You can compare two versions side by side and see exactly what moved. The diff is the most important debugging tool in a developer's kit.

In quoting, when a rate changes, the old rate is gone. The estimator updates the spreadsheet and the previous number is overwritten. There is no diff. There is no commit history. There is no "blame" command that tells you which rate was in effect when a particular quote went out.

This creates what we call era effects, and they nearly broke our engine build before we understood them. Here is what happened. Early on, we flagged a group of quotes as outliers because they were fifteen to twenty percent above the average for the same product type. They were not outliers. They were from a six-month window when one material vendor had raised prices and the shop had not yet switched to the backup supplier. Once we accounted for the era effect, the estimator's judgment was consistent to within three percent. We had been measuring the aluminum market, not the estimator.

The discipline we adopted: every comparison carries two numbers, the raw gap and the era-normalized gap. The difference between them is the rate delta, tracked on its own line. Without this, you cannot separate "the estimator was wrong" from "the world changed." And in a year when material prices swung by twenty percent in either direction, the world changed on almost every job.

A subtler version of the problem: rate eras overlap. The estimator might have updated their aluminum rates in March but not their stainless rates until June. A quote from April sits in two eras simultaneously. If you normalize the aluminum but not the stainless, you introduce an error that looks like an estimating mistake but is actually a measurement artifact. Tracking rate eras per material, per vendor, per product line is tedious work. Nobody does it unless they are building a system that has to learn from historical data.

This is the version-control problem. Code's entire history is one command away. Quoting's history is an overwritten cell and a fading memory of what the number used to be.

4. Code has systematized delegation. Quoting is all context.

In software, you can write a ticket: "Parse the date field from the API response and format it as YYYY-MM-DD." A junior developer can pick that up, write the code, test it, and close it. The specification is self-contained. The work can be delegated because the context travels with the ticket.

In quoting, you cannot write a ticket that says "price this floating dock." The reading is the work. The estimator has to read the entire package and decide which structures are theirs. Then they have to interpret every ambiguity: is the product a polyethylene tub float system or an encapsulated-foam system? Are the piles by others or included in the dock scope? Is the gangway aluminum or FRP? Is the deck material specified or left to the fabricator? What is the tide range, and does the gangway length satisfy the ADA slope requirement for that range?

Every one of those decisions changes the price, and every one of them depends on reading the package. You cannot decompose "price this dock" into subtasks the way you decompose "build this feature" into components, because each subtask depends on what the estimator found in the previous one. The spec interpretation informs the material choice, which informs the vendor selection, which informs the price, which informs the margin. It is all one continuous act of reading and judgment.

To see how much interpretation matters, look at what happens when six experienced marine contractors price the same structure from the same public bid package. In FDOT letting E4Y47, six bidders priced an identical 4,000-square-foot aluminum floating dock. The prices ranged from $110 to $300 per square foot, a 2.7x spread. The gangway line ranged from $75 to $300 per square foot, a 4x spread. Same package, same day, same structure. The spread is not sloppiness. It is six estimators making six different sets of interpretation decisions from the same ambiguous documents.

This is the fundamental reason CPQ tools struggle with custom manufacturing. A CPQ assumes the configuration space is known: you select a size, a material, a finish, and the price comes out. For configured products like cabinets, switchgear, or modular enclosures, this works well, and we have said as much in our buyer's guide to AI quoting software. For custom products where the "configuration" emerges from reading 179 pages of drawings, specifications, and addenda, there is nothing to configure until someone reads the package. The CPQ starts where the estimator ends.

Why generic AI breaks on quoting

Most AI tools for business assume that at least some of the four advantages exist. CRM AI assumes structured deal data in a database. Legal AI assumes documented case law and written precedent. Coding AI assumes well-formed repositories with type systems, tests, and searchable documentation. These are tools that make existing infrastructure more productive.

Quoting AI has to work without any of them. It has to be the infrastructure and the tool simultaneously. It has to create structured data from unstructured documents, build the equivalent of "documentation" from the estimator's past work, track rate changes over time, and hold enough project context to make the whole thing usable. That is a fundamentally different engineering problem from making a CRM smarter or helping a developer write code faster.

This is why "just use ChatGPT" hits a wall, and we wrote about exactly where that wall is. A ChatGPT or Claude assistant loaded with rate cards can genuinely help with lookups, quote letter wording, and clean single-sheet specifications. It works for that. We also wrote a guide for building one yourself, because sometimes that is the right answer.

The wall is that ChatGPT assumes you will provide the context, the rates, the conventions, and the judgment framework. It is a tool for knowledge work where the knowledge is already accessible. In custom quoting, the first job is making the knowledge accessible at all. That job takes months, not minutes, and it requires the estimator's active participation, not just their data.

What building the harness actually looks like

So what does it take to build the infrastructure that code already has? Here is what we have learned, stripped to the principles. The specifics come from building a quoting engine for custom fabrication, but the pattern applies to any custom manufacturer whose RFQs arrive as bid packages priced by an engineer.

Step one: get pairs. Every unit of learning requires a bid package AND the company's own answer: their filed quote, their costing workbook, their internal pricing sheet. One without the other is half a case study. The bid package tells you what was asked. The answer tells you how the estimator interpreted it. The gap between them is where the knowledge lives. If the company can only provide their quotes without the original packages, you cannot learn anything, because you cannot see the decisions.

Step two: reverse-engineer the costing identity. How does this company actually compute price? What is the margin structure: cost-plus, or price divided by one minus margin? How do they handle markup on subcontracted items versus in-house fabrication? When did material rates last change, and by how much? This step is done when your reconstruction of their math reproduces their filed totals to the cent on their own workbooks. Not within five percent. To the cent. If the reconstruction is off, every downstream comparison is comparing your model to their reality, and you will never know which differences are the engine's errors and which are the model's.

Step three: mine the conventions. Go through the pairs and find the patterns. The admission bar is strict: at least three independent projects showing the same convention, at least an eighty percent fit rate across the corpus, and a stated mechanism, a reason it works, not just a correlation. "The estimator adds fifteen percent to stainless hardware" is a finding. "Stainless hardware costs more" is an observation. Below the bar, it is a flag for the estimator to decide at quote time, a bracket showing the range of past answers, or a question to ask the customer. Never a silent default. A silent default is a guess with no accountability.

Step four: build the blind test from day one. Take roughly a third of the past jobs, the ones with the best-documented answers, and set them aside permanently. Never mine them. Never read them. Never peek to see how the engine would do "just as a check." They are your only objective measure, and the moment you contaminate them, you are flying without instruments. Ten held-out jobs is the minimum for a meaningful test. More is better. The blind set must be quarantined by project name, not just by folder, because a copy of a blind project in another location re-admits the leak.

Step five: separate era effects from real errors. Every comparison needs the raw number and the era-normalized number. The rate delta goes on its own line. Build a rate-era timeline before you score anything. Without this discipline, you are debugging the commodity market, not the engine, and you will chase phantom errors for weeks.

This is the harness. It is not glamorous. Most of the work is reading workbooks, asking the estimator "why did you do this," and writing down what they say in a form that is testable. It takes weeks, not days. But without it, any AI built on top is guessing confidently, which is worse than guessing hesitantly.

Where quoting automation is today

The honest answer: where code was before version control, before continuous integration, before package managers, before Stack Overflow. Decades of infrastructure separate a 1995 codebase from a 2026 codebase. Quoting has had none of that investment, because until very recently, there was nothing to invest in. The estimator was the entire pipeline: reader, interpreter, calculator, and quality checker, all in one person.

The tools that exist today fall into three lanes. First, CPQ tools built for configured products: Epicor CPQ, Tacton, Salesforce CPQ. They work well for products with a known option tree and struggle when the "options" emerge from reading a bid package. We wrote honest guides on Tacton and Epicor CPQ that explain when to stay on them and when the lane does not fit. Second, geometry-based should-cost tools like aPriori, which derive cost from 3D CAD models. Excellent for what they do. They need a 3D model, which bid-package work does not have. Third, bid-package-reading tools: this is our lane, and we are honest about how young it is.

The structural gap Pocock identified is the reason all three lanes are limited. CPQ has no reading layer. Should-cost has no package layer. Bid-package reading has no pre-built harness. Everyone who works in this space is building infrastructure and product at the same time, which is why progress looks slow from the outside and feels frantic from the inside.

Why quoting is hard to automate, and what to do about it

Why is quoting hard to automate? Not because the math is complex. The arithmetic of a custom quote is multiplication and addition. It is hard because the infrastructure does not exist. Code has tests, documentation, version control, and delegation frameworks because generations of developers built them, incrementally, over decades. Quoting has none of those things because the estimator was the system, and there was never a reason to build the infrastructure around them.

AI for quoting does not start by replacing the estimator. It starts by building the harness that makes the estimator's knowledge visible, testable, and transferable. The blind test is the test suite. The mined corpus is the documentation. The rate-era tracking is the version control. The structured output is the delegation framework. All four have to exist before the AI layer on top does anything useful.

If you are evaluating quoting software, the single most important question is not "how fast does it read a package" or "what model does it run on." It is: "what is the feedback loop?" How does the system know when it is wrong? How do you know when it is wrong? If the answer is "our engineers review every quote," that is not a feedback loop. That is the estimator doing the same job with an extra screen open.

A real feedback loop is a blind test with held-out jobs, a published pass bar, and a failure registry you can read. We publish ours at mavlon.co/pilot. If a vendor will not publish theirs, ask yourself why.

Everything else, the reading speed, the conflict detection, the draft quote, follows from having the harness in place. Without it, you have a chatbot that sounds confident and gets the float family wrong. We know, because ours did exactly that before we built the harness to catch it.