---
title: "From Drawing to Quote: Designing a Quoting Assistant for Parts Made to Print"
pubDate: 2026-10-18T00:00:00.000Z
tags:
- AI
- Architecture
- Manufacturing
math: true
image: /images/blog/from-drawing-to-quote/featured.png
---
import QuoteMap from '../../components/QuoteMap.astro';
import QuoteFigure from '../../components/QuoteFigure.astro';
## TL;DR
A manufacturer that makes parts to its customers' drawings loses most of its quotes, and each one costs an expert hours of checking, assessing and pricing. The system I'd build drafts the quote within minutes of the email arriving and leaves every decision to the expert. An LLM does the reading: is this a request, what does the drawing say, what is missing. Rules the expert writes down set what is allowed, past parts that look alike propose within it, and the arithmetic is plain code. The hard parts are not the models. They are getting the rules out of the expert's head, getting history out of an old ERP, and a review screen good enough that the expert prefers it to the spreadsheet.
## How a quote gets made today
The design follows a real quoting process at a manufacturer that makes parts to print. The running example below is invented to protect the manufacturer, but the process behind it is real.
*The six stations of a quote today. Grey is mail and the ERP, teal is people. The time goes into assessing and calculating, and it sits with one expert.*
1. **A request arrives** by email to a shared inbox, with drawings as PDFs, sometimes a 3D model, and the quantities in the text.
2. **Someone checks it is complete:** a drawing, the material with its grade and diameter, the finishing steps (surface treatment, heat treatment) and a quantity. Many requests miss one, and a question goes back to the customer by hand, days later.
3. **The expert assesses it.** Can we make this, which product line is it, and which machine: a small one that needs little tooling but runs slowly, or a large one that needs an expensive tool and then runs fast? How long is setup, and how many hours to build the tool? A few hard rules, such as each machine's diameter range, and a lot of judgement, refreshed by remembering what was made before.
4. **The price is calculated** in a spreadsheet: material, setup, cycle time times the machine rate, tooling hours times the toolmaker's rate, then surcharges for overhead and margin, often for several quantity breaks.
5. **The result is typed into the ERP,** under an offer number from sales, next to the customer's payment and delivery terms.
6. **The offer goes out** as a PDF printed from the ERP.
## What the system must do
*All we know so far: a request goes in, and an offer should come out.*
### The running example
Lindqvist Outdoor, a maker of camping gear, emails a request: 45,000 tent-pole clips a year, delivery from the second quarter, drawing LO-318 attached. The drawing gives the shape, stainless spring steel 1.4310 of 4 mm diameter, and no heat treatment. For the surface it says "per customer standard", and the standard isn't attached.
*What the system reads out of the request, field by field, and where each value came from. One required field is missing.*
Two things about this request shape the design. The missing surface blocks a final price but not a draft: the draft prices the usual finish as a marked assumption and asks at the same time. And at 45,000 a year the small and the large machine cost about the same, so the right answer is two prices (more in the calculation below).
### Boundaries
- **The expert decides, the system drafts.** A wrong quote is either money left on the table or a contract that loses money for years. Nothing is sent without a person approving it; the goal is a draft good enough to approve in minutes.
- **Most quotes are lost, so effort per request is what counts.** If a quote takes $t$ hours and only one in $n$ wins, every order carries $n\,t$ hours of quoting. Halving $t$ pays off on every request, won or lost, and a same-day answer beats a competitor who takes a week.
- **Only written rules get automated.** Rules that exist only in the expert's head can't be built or tested. The first deliverable is the expert's own: writing them down, with help. Everything else goes to the similar-parts search and to the expert.
- **The systems are old and stay.** An on-premise ERP without a usable API and a mail system without a ready-made connector. Where the system can't write, the expert copies a few fields across; that is cheaper than months of integration.
- **Assemblies are out of scope.** A small share of requests, needing 3D models and a different assessment. Version one recognises them and hands them to the expert untouched.
- **Scale is small.** Hundreds of requests a year. Model costs are a rounding error; what limits the design is whether the expert trusts the draft.
## The simplest design that works
*Seven steps, still technology-agnostic. Grey is the manufacturer's mailbox, blue is the platform, teal is the expert.*
Requests arrive in the shared **inbox** as today. **Intake** sorts them and splits each into one draft per drawing. **Extraction** turns each drawing into a typed record and asks the customer for what is missing. **Assessment** proposes machine and tooling hours, **calculation** prices each variant, the expert **reviews**, and **handover** produces the offer.
Every value in the draft knows where it came from, so a wrong one can be traced to the step that produced it. Three small records carry all of it: a *request* (the email, its attachments, the customer), a *draft* per drawing (every field with its value, source and check results, plus the variants and prices), and a *change* (field, old and new value, reason, who, when). Only these cross between the steps, so each step can be replaced without touching the others.
## The components
*The same seven steps, each with the components that make it concrete. Each part below highlights its step.*
### Intake
- **Request or not:** the inbox also gets order confirmations, invoices and newsletters. An LLM classifies each email as request, not a request, or unclear. Anything unclear goes to a person, and so does any email with a drawing that isn't classified as a request.
- **Product line:** it decides the checklist, the rules, the machines and the calculation template, so it is the first decision and a visible one. The expert can change it, and everything downstream recomputes.
- **One draft per drawing:** quantities often sit in a table in the email; intake matches each to its drawing, and one it can't match becomes a missing field.
- **Replies find their draft** by the thread and the drawing number, and fill the missing field.
### Drawing extraction
A vision-capable LLM reads each page and fills a [Pydantic](/post/pydantic-ai-type-safe-hybrid-workflows) model: material and grade from the list the manufacturer actually buys, diameter in millimetres, finishing steps from a fixed vocabulary, and the notes it can't map.
- **Every value carries its source:** the title block, a note, the email, a default, or nothing. On the review screen a click on a value outlines the spot on the drawing it was read from.
- **No confidence colours.** A model's self-reported confidence is poorly calibrated, so colouring fields by it would mostly be noise. The screen shows checks instead, all in code: does the grade exist in this diameter, does the 3D model agree with the drawing, do two reads with different models or prompts agree.
- **Unreadable is a result:** a scan the model can't read leaves the fields empty and marked, and goes to the expert with the page.
- **Tolerances as a flag:** they are checked in detail once an order is won. At quote time, extraction only flags tolerances tighter than the machines usually hold, since they add operations and scrap.
- **Checklist and question:** each product line has a checklist of required fields, checked against the record, since half the answers are on the drawing. A missing field gets a drafted question in the customer's language, which also asks how long the part will run if the request doesn't say. It lands as a draft in the shared mailbox, or on the review screen to copy where the mail system doesn't allow that.
### Assessment
Assessment answers three questions: can we make it, on which machine, and how much tooling. It has two sources and shows both.
- **Written rules,** as code: diameter limits per machine, which product line runs on which machine family, minimum lot sizes, setup times. Each rule is versioned, has the expert's name on it, and is tested against past requests. Rules mostly say what is *allowed*.
- **Similar past parts,** from the ERP's article master, which records what production actually ran: material, diameter, routing, cycle and setup times, price. Tooling hours, where they were recorded at all, often live only in project folders, so linking each article to its drawing and tooling history is a data task of its own.
- **How "similar" is computed:** a filter on product line, material, diameter range and finishing narrows thousands of parts to a few dozen. A weighted score ranks them: closeness in diameter and quantity, plus the similarity of image embeddings of the drawings, cropped to the part views without title block and frame, or of shape features from the 3D model. The expert sees the parts, not the score.
*The running example in assessment. The rules allow both machines; the three most similar past parts show what each choice took before.*
When rules and similar parts disagree, or the similar parts disagree among themselves, the screen says so. That is where the expert should spend time, and it is how the expert works today, minus the remembering.
### Calculation
The calculation is the spreadsheet's cost-plus scheme, rewritten as code with tests. No model does arithmetic. For each machine $m$ that can make the part, the price of $Q$ pieces is
$$
P_m(Q) = T_m + c_m \, Q,
$$
where $T_m$ is the one-off tooling charge (tooling hours times the toolmaker's rate, here 150 euros an hour) and $c_m$ the price per piece: material, cycle time times the machine rate, finishing, setup spread over a typical lot, overhead and margin. The small machine has a small $T$ and a large $c$, the large machine the reverse. They cost the customer the same at
$$
Q^* = \frac{T_L - T_S}{c_S - c_L}.
$$
With the running example's invented numbers, 8 hours of tooling on the small machine and 90 on the large one, $T_S = 1{,}200$, $c_S = 0.48$, $T_L = 13{,}500$ and $c_L = 0.19$ euros, $Q^* = 12{,}300 / 0.29 \approx 42{,}000$ pieces, a little under one year's demand.
*Total price of the two variants over the quantity ordered, invented numbers, with the draft's 90 hours of tooling on the large machine. They meet at about a year's demand; over three years the large machine is cheaper by about 27,000 euros.*
What matters is the quantity over the part's whole life, and only the customer knows it. So the draft offers both variants whenever $Q^*$ falls within a plausible run, say one to five years of the stated annual demand, and the customer chooses.
- **Material prices** come from a table purchasing owns. A material missing from it, or a volume large enough to ask the supplier for its own price, is flagged.
- **Payment and delivery terms** come from the ERP's customer record, read-only, so the offer never states terms the ERP doesn't have.
### Review
The review screen decides whether any of this gets used. If checking a draft takes longer than doing the quote by hand, the expert goes back to the spreadsheet and the system dies quietly.
*The running example on the review screen. The diameter is selected, so its spot on the drawing is outlined. The expert has raised the large machine's tooling from 90 to 100 hours and picked a reason.*
- **Everything editable,** product line and machine included, and everything downstream recomputes on the spot.
- **One reason per change,** from a short list (misread, rule doesn't apply, differs from the similar parts, customer-specific). It takes a second, and it is what the system improves from.
- **Disagreements first:** a missing field, rules against similar parts, a price far from the similar parts' prices. Attention goes where the draft is unsure, not to every field.
### Handover
- **Offer PDF and mail** from the manufacturer's template, in the customer's language. The offer number stays blank until the ERP assigns it, so the two never disagree.
- **The ERP, in steps:** read access first (customers, terms, article master), which IT can grant without risk. In version one the screen lays out the fields in the ERP's order to copy across; later an API if there is one, or a robot that fills the ERP's screens as a last resort.
### From overrides to rules
The expert's changes are not used to retrain anything behind the expert's back. A change made once may be a one-off for one customer; the same change made repeatedly on similar parts is a rule nobody wrote down.
*The running example's change, R-1262, is the third of its kind. The overrides become a proposal, checked against the past requests that didn't produce it; the expert approves, edits or rejects it.*
- **"The same kind"** means the same field, the same reason, and parts of the same product line and material. When a few such changes point the same way, an LLM drafts the rule that would have produced them, and code checks it.
- **The check uses other requests:** the proposal is replayed on past requests that didn't produce it, so the expert sees where it agrees with what they decided.
- **Only an approved rule goes live.** The rule set stays a document the expert owns, not a model nobody can read.
## The life of one request
*Highlighted: the path the running example takes.*
The Lindqvist email arrives at 9:12. Intake classifies it as a request for formed parts; extraction can't resolve the surface, and a question to the buyer is drafted. Assessment finds no rule against either machine and proposes 90 hours of tooling, weighted towards the closest of the similar parts. Calculation prices both variants with the usual passivated finish as a marked assumption. At 9:20 the draft is waiting. The expert sends the question and raises the tooling to 100 hours, picking "differs from the similar parts": the clip's bend is tighter than on any of them. When the buyer confirms the finish and a three-year run, the draft updates, and the offer goes out within the hour.
## Tradeoffs
- **Rules first or similarity first.** Similar parts are how the expert works today and cover what no rule does, but they depend on clean history, and a similar part is evidence, not a decision. I'd go live with rules setting the limits and similar parts proposing, and give the similar parts more weight as their agreement with the expert is measured.
- **Where the LLM sits.** Reading: emails, drawings, questions to customers, rule proposals. Deciding and calculating are code and the expert. A machine choice or a price that can't be traced to a rule or a past part is one the expert can't defend to a customer.
- **Workflow, not agent.** The steps and their order are the same for every request, and the order is what makes a draft traceable. That is a [workflow](/post/workflow-vs-agent). The odd requests an agent would help with go to the expert anyway in version one.
## Running it: evaluation, rollout, security
*Highlighted: the expert's changes, which are both the evaluation and the source of new rules.*
### Evaluation
This project has what many lack: labelled history. Every past request comes with the quote sent for it, and a request is a frozen snapshot, so replaying it shows the system exactly what the expert saw.
- **Extraction:** field by field on a few hundred past requests, against what the expert entered. Wrong is worse than missing: a missing field gets a question, a wrong one a wrong price.
- **Assessment:** how often the proposed machine matches the expert's, and how far the tooling hours are off, separately for rules and similar parts.
- **No peeking:** in replay, the similar-parts search only sees parts created before the request, never the part itself or an earlier revision of its drawing. Rules are tested on requests the expert didn't use to write them.
- **Calculation:** each cost component against the expert's spreadsheet, not the final price, which moves with material prices.
- **In production:** time from email to sent offer, and edits per draft. As with [approval rates](/post/approval-rate-is-not-savings), a draft approved after rewriting half of it has saved little.
- **Not the win rate.** It depends on prices, competitors and the customer's plans; a faster quote that lost is not a failure of the system.
The expert's quote is the label, not the truth: some quotes were lost for being too high, some won for being too low. Replay measures agreement with the expert, which is what builds trust. Whether prices should change is the manufacturer's question, not the model's.
### Rollout
- **Shadow first:** for a few weeks the system drafts every request while the expert quotes as before, and the two are compared weekly. Nothing reaches a customer.
- **Then one product line at a time,** starting with the one whose rules are best written down.
### What I'd test first
1. **The rules can be written down** for most requests. If not, similar parts carry the assessment from day one, and the project waits on getting history out of the ERP. Test it in a few sessions with the expert, before any code.
2. **Drawings can be read reliably.** They vary in layout, language and quality, and some are scans. Fifty past requests, extracted and compared with what the expert entered, answer this in a week.
3. **The history is clean enough to search.** Years of parts entered under different conventions, and tooling hours that may only exist in project folders. A hand-checked sample of a few hundred shows how much cleaning comes first.
### Security
Customers' drawings are usually under a non-disclosure agreement. The documents and the model stay in the EU, in a data center the manufacturer agrees to, with no training on its data, isolation from other companies' data, and read-only ERP access until writing is worth the risk. The change log records who changed which price and why.
### What carries over
Intake, extraction, the rule engine, the similar-parts search, the review screen and the ERP handover are the same for any company that quotes to drawings. The product lines, checklists, rules and templates are specific. Keeping the two apart lets a new product line start as configuration and rules rather than new code.