What to Ask an AI Quoting Vendor

Every AI quoting demo looks good. The package is chosen, the drawings are clean, and the number lands in ninety seconds. You learn almost nothing from it.

What separates a system you can defend a quote with from one that produces a confident number is visible in five questions, none of which are about accuracy percentages. We sell one of these systems, so read this as the test we expect to be put through. A vendor who flinches at any of the five is telling you something.

What does it do when it isn't sure?

It should tell you, and show you the sheet the doubt came from. Start here, because this single behavior says more than any benchmark.

A quoting system that resolves ambiguity by guessing is more dangerous than one that misses. A miss gets caught in review; someone notices the line is not there. A confident wrong answer gets quoted, because it looks exactly like the four hundred correct lines around it, and nobody audits a line that looks finished.

Any real RFQ package is full of ambiguity. Which revision governs. Whether the workbook's quantity breaks or the cover letter's are the real ones. What the note on sheet 14 does to the finish called out on sheet 3. The system will meet all of it.

So ask what happens at that moment. If the answer is anything other than "it tells you," keep looking.

Then make it prove the claim. Hand over a package with a genuine contradiction in it, a spec that fights a drawing, and watch whether the conflict comes back as a flagged exception with the sheet and the evidence attached, or quietly disappears into a number.

What has to be configured before it reads a drawing?

The honest answer is "your rates and your systems." The answer to worry about is "your documents."

If a system needs templates, a naming convention, or a data model before it can read a drawing, that setup cost does not land once. It lands every time a customer formats things differently, which for most suppliers is every new program. The work gets pushed onto your estimating team under the name of onboarding, and the week you were trying to remove comes back as preparation.

The test costs you nothing. Send the ugliest package you have, the one with the scanned legacy prints and the revision history sitting in an email thread. Not your best-organized program. A system that only works on a tidy package has not been tested against the thing you actually do every week, and you will discover that in month four instead of week two.

What does it connect to, and who does the integration?

It should reach your PLM and CAD, your ERP, your CRM, and the drives where past quotes actually sit, and the vendor should be able to name who does that work. This is the question that decides whether you are buying a reading tool or something that remembers.

Reading a drawing is the easy part now. The value is in the system knowing what that operation cost the last time you quoted it, which revision your PLM says is current, and what the customer meant in the clarification thread from the last program. None of that exists unless the system can reach where your history lives: PLM and CAD, ERP and procurement, CRM, and the shared drives and workspaces where the past quotes actually are.

Ask for the specific connector list, not the word "integrates." Ask what is read-only and what writes back, and insist that write-back is the last thing switched on rather than the first. Ask who does the work and how long it took at the last three customers.

Expect the honest answer on timing to be uncomfortable. The integration work is rarely technically hard and is almost always organizationally slow, because it needs someone in IT who owns each system and a security review nobody scheduled.

Where do our drawings actually go?

You should get named infrastructure, a named subprocessor list, and a stated retention term, in writing. Customer prints are the most sensitive documents in your building. A tier-one's print set is somebody's unreleased product, usually under an NDA with teeth.

Four things to get in writing:

• Tenant isolation, so your data is separated rather than co-mingled with other suppliers'.
• No cross-customer training, so your cost structure never becomes a feature in someone else's model.
• A SOC 2 report you can read, not a badge on a website.
• A plain answer on model calls: which providers, in which regions, under what retention terms.

Your own customers will eventually ask you these questions during a supplier audit. It is easier to have the answers before they do.

Can you prove it on quotes we have already sent?

They should say yes without hedging, because it is the only demo that can be graded. A vendor-picked package proves nothing; you have no way to know what was quietly excluded.

Bring a package you have already quoted, ideally one your current process struggled with, and have it run live. You already know the right answer, which is exactly what makes it a test rather than a presentation.

Then compare line by line against what your team produced. Where the two differ, ask which sheet the difference came from and why. That tells you more than any accuracy figure, because it is measured on your drawings, in your formats, against an answer you already trust.

From there, run it alongside the process you have rather than in place of it, with an estimator approving everything that goes out, until the comparison stops being interesting.

A vendor who will not be graded on a package you have already answered is telling you the demo was the product.

What you will be asked for in return

None of this is free on your side, and a vendor who implies otherwise is describing a demo rather than a deployment. Four things get asked of you:

Your packages exactly as they arrive. Not cleaned up, not renamed, not with the scanned sheets swapped for CAD-native ones.

Your rates, your routings, and your past quotes. A should-cost built on generic industry rates is a should-cost for someone else's shop, defensible in a demo and indefensible in front of a customer asking why your number moved. All of it already exists inside your business and goes over as it is, with no cleanup step first. Expect to be asked for the quotes you are not proud of, because the ones that lost on price and the ones that won and then bled margin mark where the current process is already wrong.

Read access, and the internal time to arrange it. See the third question. The bottleneck is your IT calendar, not the connector.

An approval gate you actually hold. The system drafts and the estimator signs, and that has to survive the days it is inconvenient. Your quality system needs the signature to mean a person reviewed the thing, and an auditor will eventually ask whether the approval is a control or a checkbox. A deployment that quietly grows an auto-approve path for small parts has removed the control, and the first time that matters will be the first time something goes out wrong.

That last one is the only item on this page that no vendor can do for you.