An integrator’s quoting process rarely fails at the pricing. It fails at the part nobody writes down: someone reads a PDF, remembers a similar job from eighteen months ago, checks whether that gripper is still available, and asks an engineer a question in a chat thread that never gets attached to anything.
Two weeks later the customer asks why the number changed, and the answer lives in four places.
The thread is the asset
The useful unit of work here is not the quote. It is the thread: the spec sheet, the assumptions someone made about it, the questions that came back, and the version of the answer that was actually sent.
Automating “generate a quote” without capturing the thread produces a faster version of the same problem. You get a number sooner and still cannot say how it was reached.
So the first thing to build is not a model call. It is a place where an inbound RFQ becomes a record with a stable identity, and every subsequent artifact attaches to that identity: the extracted requirements, the questions, the component decisions, the sent document.
What the machine should do first
Extraction, not judgment.
Given a spec sheet, an agent can reliably pull payload, reach, cycle time, duty cycle, environment, mounting constraints, and the certifications the customer named. That work is tedious, high-volume, and checkable, and checking a table is much faster than assembling one.
What it should not do first is choose the cell layout or commit to a lead time. Those depend on knowledge that lives in your engineers’ heads and in supplier conversations that are not in any document. An agent that guesses there produces a plausible answer with no trace, which is worse than no answer.
Make the gate the interface
Put the human approval where the cost of being wrong is highest: before a number reaches the customer.
The gate should present three things and nothing else. What the system extracted. What it assumed. What it would send. A reviewer who has to open the source PDF to check the gate is not being helped by it.
When the gate is designed properly, two useful things follow. The reviewer’s corrections become training data for the extraction step, because you now know which fields get changed and how often. And the trace of what was assumed is already written down when the customer asks in a month.
The failure mode nobody plans for
The thread survives the first quote and dies on the revision.
A customer comes back with a changed requirement, someone opens the original record, and the fastest path is to start a new one. It is faster because the tooling made it faster, and after a quarter the archive is full of quotes with no lineage, each one a snapshot of a conversation that no longer exists.
The fix is unglamorous: a revision has to be cheaper to create than a duplicate. If it is not, people will duplicate, and no policy will stop them.
What to measure
Not time saved. Time saved is the last thing to measure, because it is the easiest to fake and the hardest to attribute.
Measure how often the reviewer changes an extracted field, and which one. Measure how many RFQs reach a sent quote without a question going out. Measure how long a thread sits waiting on an engineer.
Those three numbers tell you where the next piece of automation belongs. Time saved tells you whether the last one worked, which you will find out anyway.