TL;DR
A deadline, a job reference, a question and a signature block all name products and quantities. Send them to a catalogue and you get order lines nobody asked for — and a delivery date that vanishes without trace.
Is a sentence in a quote email a product line or an instruction?
Both, usually, which is the problem.
A real quote request is not a list. It is a message, and inside it are the things the customer wants mixed in with the things the customer said — a delivery date, a site name, a question, a change of mind, a sign-off. Almost all of them name a product or a quantity. Several name both.
Send that message to a catalogue as though every sentence were an order line and you get two failures at once: rows on the quote nobody asked for, and conditions the customer cared about disappearing without trace.
For anyone deciding how a quoting system should read a message. 7 minute read.
The output is two lists, not one
The first design decision is to stop treating extraction as one job.
What they want — the requested lines, each with a quantity and a unit. What else they said — and that second list is not leftovers. It is a first-class output with its own categories:
- Deadline — "Needed on site Thursday"
- Reference — "for the Mill Street job"
- Correction — "scrap the insulation, we have enough"
- Question — "is that still the polished finish?"
- Requirement — "must be to the same standard as last time"
- Note — "no rush, end of the month is fine"
Classify before you match. A sentence sent to the catalogue has already been assumed to be a product, and the catalogue will answer the question it was asked.
Four sentences that all look like order lines
"Could you quote the following for the Mill Street job." Sent to a catalogue, this comes back not stocked — and not stocked is a plausible-looking outcome that a reviewer may not question. The job reference is gone. It was never a product.
"Needed on site Thursday." Same failure, worse consequence. A deadline that fails to reach the quote is how you win an order you cannot deliver on time, and nothing on the finished document shows that anything was dropped.
"Is that still the polished finish? The last lot were." This one names a real item and reads as an enquiry to any human. Matched and priced, it becomes an order line on the customer's quote for a product they were only asking about. The question mark is not at the end of the sentence, so a rule that hunts for question marks misses it entirely.
"Harper Plumbing Ltd." A company name in a signature block, matched against the catalogue and reported as not stocked. Comic on its own, and it is the case that points at the general fix.
Why this is genuinely hard: every one of them names a product
It would be easy to read the four cases above as sloppiness — obviously a question is a question. Look at what each sentence actually contains and the difficulty stops being obvious.
- "Scrap the insulation, we have enough on site" — A product name, and a quantity of nothing
- "Plus twenty more of the 22 mm elbows" — A real quantity against a real item, inside a sentence whose job is to point at a past order
- "Is that still the polished finish?" — A valid item identifier, priceable, sitting in a question
- "No rush, end of the month is fine" — A date, and no product at all
Three of those four would light up every heuristic you could write for detecting an order line. The second is the worst of them, because it is simultaneously an instruction and a genuine quantity — the twenty extra elbows really are being ordered, and the rest of the sentence points at a history lookup.
So this cannot be solved by a better product-detector. The test is not "does this name a product" — almost everything does. The test is "what is this sentence for", and that is a different question requiring a different pass over the message.
Two of the categories deserve their own treatment and get it elsewhere: corrections are chapter 4, and what happens when a line resolves to nothing is chapter 5.
The signature is structural, and that is what makes it solvable
The tempting approach to signature blocks is a filter list: drop lines that look like phone numbers, drop "Sent from my iPhone", drop job titles, drop addresses, drop legal disclaimers.
That list has no end. Every customer's mail client adds something new, and each addition is a separate rule that fires or does not.
The structure is reliable where the content is not. An email has a body, a sign-off, and then a signature — and nothing after the sign-off is a product request. One boundary, found once, replaces an unbounded list of exceptions.
It is worth stating what that is a claim about: it is a claim about email conventions, which hold well enough to be useful and not so well that the boundary should be applied silently. Cutting there is the kind of change that visibly moves how much of a message needs a human at all.
Keep what is inside the courtesy
"Could you please quote the following for the Mill Street job:" is mostly politeness wrapped around one fact. Drop the sentence; keep Mill Street job.
This sounds like tidiness and is not. A panel headed instructions from the customer is a panel someone has to read carefully, and noise there is worse than noise anywhere else — it teaches a reviewer to skim the one place that must not be skimmed. Three courteous non-facts in that list and the deadline in position four stops being read.
Microsoft filters too, and publishes what it filters
Business Central's Sales Order Agent [GA] faces the same problem and solves the first half of it the same way:
"The agent validates incoming messages and attachments against a relevance model before it processes them. The relevance model filters out messages that are outside the agent's scope. For example, it filters out offers to sell, discount requests, or attempts to access internal data."
Attachments get their own pass, and Microsoft's example is precisely the shape a real inbox produces:
"if a customer attaches terms and conditions or a privacy policy alongside a purchase order, the agent processes only the purchase order and ignores the non-sales attachments."
Its published test suite lists an Out-of-scope handling category covering "Delivery status inquiries, product support, returns and refunds—all triggering appropriate user intervention", and a Safety & guardrails category covering "Prevention of unauthorized promises (discounts, services), annotation of problematic requests, response boundaries."
That is the same instinct, applied at the message level. The filtering above happens inside a request the agent has already accepted — deciding which sentences are orders once the message is in scope. Microsoft also publishes the agent's prompt instructions, "including relevance filtering, item search priority rules, and agent behavior guidelines", in its BCApps source on GitHub — an unusually open thing to do and worth reading if you are building anything adjacent.
Put them above the lines, not beside them
One placement rule, and it decides whether any of the above was worth doing.
Customer instructions go above the requested lines, because they change how the lines are read. A correction deletes one. A reference names the job all of them belong to. A question is owed an answer before the quote is credible at all. A reviewer who meets the lines first has already formed a view by the time they reach the sentence that changes it.
And nothing sticky in the middle of the page. A floating bar slides over the panel that has to be read in order to keep visible the one that does not.
About Cognilium Cognilium builds AI systems that work in tandem with Microsoft Dynamics 365 — the decisions the ERP records but does not make. Business Central and Finance & Operations, on your own governed stack. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Curious how much of a real customer email is not a product line? Book a 15-minute call and bring one of your own — we will take it apart on the call. No deck.
Sources
Sources
Share this article
The workspace these articles describe — one queue, per-line confidence, supplier choice and the write-back — as a product for Business Central distributors.
