AI order processing: where a model helps, and where it must not

AI order processing is worth building for one half of the job: turning a message, a photographed slip, a PDF or a filled form into a candidate order record. It must not be the authority on the other half — the price, the credit, the stock committed — because those mistakes leave the building and come back as complaints. The split holds while a person reads the proposal before the order becomes real, and collapses once volume outgrows that reading.

What does a model do well on an order?

It removes the retyping. An order arrives as a WhatsApp message mixing Arabic, French and English, as a photograph of a handwritten slip, as a PDF from a pharmacy, or as a form filled during a phone call. A person reads each and types it into one screen.

The useful part is that all four inputs come out in one shape: who ordered, which items, in what quantity, for which date, to which address, plus the note that fits nowhere. It also does the normalisations a clerk does without thinking — a carton converted to the unit the shop sells, an item named two ways matched to one code.

What comes out is a proposal in a queue, not a row in the order table.

Which decisions must stay with a person?

The ones whose cost is paid outside the building — not because the model is weak, but because it has no access to the reason behind the answer.

Decision	What the model may do	What the person does
Unit price	read the price list it was given	apply the discount agreed last spring
Credit	show the customer's history	approve or refuse the account sale
Stock	show what the system holds	decide whether to promise it
Delivery date	propose from the rate table	confirm with the courier

The model reads the price list; it cannot know the pharmacy got a discount for accepting a damaged pallet. That fact lives in a conversation, not a column.

An order document has a settled field set — buyer, seller, line items, delivery terms — and a model fills those fields well, because the shape is standardised (OASIS UBL order document). Whether the terms apply to this customer today is answered by whoever carries the consequence.

What does a confidence score actually tell you?

Very little, on its own. A model rating its own certainty returns a number that looks like a probability and is not calibrated: high on a typed form, high on a blurred photograph, because it is generated alongside the answer rather than measured after it.

What you can measure is agreement. Run the extractor over last month's orders and compare field by field with what a clerk typed. That gives a rate per field — customer matched, item matched, quantity right, date right — and the rule is set from that, per field rather than per document. A typed form can pass silently; a photographed slip never should, whatever the extraction claims.

That sample is also the evidence a risk framework asks for before a system acts without review (NIST AI Risk Management Framework).

Which fields must a person confirm?

The price, because a wrong price is a contract; the quantity where the unit was inferred; the delivery date; any customer record that does not already exist; the total. Confirmation is an action stamped against a name, once per order.

Show the original beside the proposal, so the reviewer compares instead of reconstructing, and let the correction be the approval: fix the field, confirm once. A review step costing more than retyping gets skipped by the second week.

What must a model-made record carry to be defensible?

The input unaltered — message text, photo, PDF — stored with the order and never overwritten. The proposal as generated, including the fields it left empty. The configuration: which model, which instruction version, which price list was in scope. And the difference between proposal and confirmed record.

If reviewers keep correcting quantities on photographed orders, the diff points at the intake channel rather than the prompt, and it answers the customer who says they ordered more than they received. Recording where a value came from is ordinary data practice, not an AI speciality (W3C Data on the Web Best Practices).

How do you know it saved time?

Measure per order: time a clerk keying the order from the raw input, time a clerk reviewing the proposal, correction time when the proposal is wrong. The task pays when review plus correction is shorter than typing, on the orders that arrive most often — not on the tidy examples chosen for the demonstration.

Then measure the queue: a proposal waiting an afternoon for a reviewer delays dispatch, and a shop notices a late parcel before a saved minute. Count the exceptions too — orders needing full manual entry are the ceiling on the benefit.

What order do you build it in?

1. Write the target record first — fields, units, statuses — and who may change each one.
2. Collect real orders from every channel, including the badly photographed ones.
3. Build extraction that proposes and writes nothing, with the input shown beside the fields.
4. Run it on live orders beside the current process, across a week that includes a weekend.
5. Measure time per order, correction rate, exception rate, and the oldest item in the queue.
6. Only then let it write, with price, credit and stock as read-only lookups, keeping input, proposal and diff.

Where this goes wrong

The pilot on forms, production on photographs. The trial runs on the cleanest channel and succeeds; live traffic arrives as angled phone pictures, and the gap between them is the project.

The price list that stopped refreshing. Extraction is scoped to an export nobody re-runs, so the proposal quotes last season's price and a person confirms without looking, because the field is usually right.

The queue nobody owns at the weekend. Orders arrive Saturday, the reviewer is off, and Monday the queue is cleared in one pass without opening the photographs. A proposal with no owner is worse than a keyed order, because it looks finished.

Units inferred in silence. A carton read as a single piece reserves the wrong stock, and nothing throws an error.

What this does not cover

This is not a comparison of models or providers, and not a security review of the channels orders arrive on. It says nothing about handwriting quality, which varies by writer more than by system, and it assumes the order record and its statuses already exist: extraction into a business without an order table just fills a spreadsheet faster. It also does not cover what the customer is told — no confirmation goes out before a person confirms the record.

We build the intake and the review step that keeps the decision where it belongs, and leave the price, the credit and the stock commitment with the person who signs the order.