When is AI quote automation the wrong build?

In four situations, and three of them are common. When the shipped agent already covers your requests; when your catalogue cannot support matching; when quoting is not actually the slow part; and when nobody has capacity to review what the agent produces.

We build these systems. The cases below are the ones where we would tell you not to.

Is the request already covered by something you own?

Then buy nothing and build nothing. If your requests arrive by email, name catalogue items, run to a modest number of lines and price through your standard engine, Microsoft's Sales Order Agent is the answer and it is already in Business Central.

The honest test is your own quote log, not a feature comparison — sort last quarter's requests against the published envelope and count what genuinely falls outside. Chapter 7 does that sorting.

A build justified by a handful of exception requests is a build that will be maintained forever for a handful of exception requests. That arithmetic rarely survives contact with a second year.

Can your catalogue actually carry the matching?

This is the case we see most often, and it is the one people least want to hear, because the fix is unglamorous and it is not an AI project.

Every matching approach — Microsoft's and anyone else's — reads what your item records say. Microsoft is direct about the dependency:

"Although the agent can find products based on vague and incomplete descriptions, the quality of product information in Business Central affects its effectiveness. You can improve the agent's ability to find products by enhancing descriptions, attributes, categories, and extended text of your inventory items."

And more pointedly, on naming:

"How you name your products can affect agent output. For example, using cryptic abbreviations versus friendly names can reduce output quality."

Cryptic abbreviations are the norm in MRO and industrial distribution, because item codes were built for people who already knew the catalogue. An agent does not.

If your descriptions are abbreviations, your attributes are empty and your item references are incomplete, matching quality is capped by the data long before any model choice matters. Spend the money on the catalogue. The same work makes search and every future system better, and it is the one investment that is not wasted if you never build the agent.

Is quoting actually the slow part?

Measure before building, because "quoting takes too long" is often three different problems wearing one name.

Time the stages separately: request to first draft, draft to internal approval, approval to sent. Then look at where the days actually sit.

• If the delay is draft to approval, the constraint is a person's calendar and an agent produces drafts that wait longer in the same queue.
• If the delay is waiting on a supplier price or date, quoting is downstream of the real problem — and that is a surface the quoting agent does not touch.
• If the delay is request to first draft, that is the one an agent genuinely compresses.

Only the third case is a quoting-agent problem. Building for the first two produces faster drafts that sit in exactly the same queue, which is a real and expensive way to be disappointed.

Is there anyone to review the output?

Review is not an optional setting you can trade away for throughput. It is designed in, and Microsoft says why:

"Email messages generated by the agent might contain incorrect information. The agent is designed to ask a human to review and edit every outbound message if necessary."

The agent "always involves designated Business Central users to review and approve all outgoing messages before it sends them to customers."

So the agent does not remove the person; it moves them. They stop drafting and start approving — higher-value work, and still work. In an eleven-person distributor where the same person handles quotes, purchasing and escalations, that capacity has to come from somewhere.

An agent producing drafts nobody has time to check is worse than no agent, because it manufactures confident documents at a rate the review step was never sized for.

What are we not claiming?

Zero delivered engagements. No distributor is running this today, no number in this cluster describes anyone's business, and nothing here is a measured result. We build these on request, against your catalogue and your Business Central, and the working system is shown on a call.

And we are not claiming the build is usually right. Three of the four cases above end in "do not build", which matches what we actually see when we look at a quote log.

What is worth doing instead?

The cheaper moves, in the order we would take them:

• Fix the item data. Descriptions, attributes, categories, item references. It raises the ceiling for every system you will ever run, and Microsoft names it as the lever on matching quality.
• Turn on what you already own. If you run Business Central and your requests fit the envelope, the agent is there.
• Time the three stages. A week of measurement decides whether the constraint is drafting at all.
• Then scope narrowly — one request type, one customer segment, one line type — and only where the envelope genuinely does not reach.

None of that starts with a model. The sequence matters more than the technology, and getting it backwards is the most expensive thing in this whole subject.

If you are weighing this build, the fastest way to a real answer is to look at what you already have. Book a 15-minute call and bring last quarter's quote log and a sample of your item descriptions — we will tell you which of the four cases you are in, including when that means building nothing.

Sources

• Sales Order Agent overview — Business Central
• FAQ for Sales Order Agent — Business Central

This article is part of our work on the RFQ quoting engine.