AI order entry for UK distributors and merchants: where the confidence threshold has to sit

Somebody in your business spends their morning retyping orders. They arrive as email text, as a PDF attached three messages into a thread, as a spreadsheet using the customer's own column headings, and as a phone call that becomes a handwritten note. Someone reads each one, works out what the customer actually wants, and types it into the system. It works right up until that person is on holiday, or it is the last week of the quarter, or volume goes up and headcount does not.

We have built one of these. The claim we publish is deliberately plain: we built an AI order-entry agent for a UK builders' merchant that reads incoming orders and writes them straight into their CRM, replacing a planned offshore hire budgeted at over £20,000 a year. We are not going to attach a percentage or a time saving to it, because we have not measured one we can stand behind and an invented one would tell you nothing. What is worth your time is the shape of the problem, which is unusually favourable, and the single design decision that decides whether the thing is still running in a year.

Order entry qualifies for AI on four conditions, and most processes do not

The conditions are worth naming, because they let you judge everything else on your list.

The input is unstructured and varied. Language models earn their cost when the input resists a template. Order entry resists templates permanently, because your customers set the format and will not change it to suit you.

The output is highly structured. Customer, delivery address, required date, then lines of product code, quantity, unit and price. There is a right answer and it is checkable, so the work can be graded rather than admired.

The rules are knowable. Which products substitute for which, which customer sits on which price list, when a delivery charge applies. Somebody knows all of it, and what is not written down could be.

A system of record is waiting to receive it. You are not asking a model to produce something for a human to interpret. You are asking it to complete a form that already exists.

That combination is rarer than it sounds. "Summarise our competitive position" has no structured output and no system of record. "Decide which quotes to chase" has no checkable right answer inside the week you need one. Order entry passes all four, which makes it the strongest candidate in most distribution businesses and, oddly, seldom the first thing attempted. Fail the second or fourth condition and you are looking at a knowledge tool rather than an agent.

What actually arrives is the reason a person still does this job

The variance is the whole problem, and it is worse than people outside the process assume:

• The same customer sends a different format most weeks, because a different person sends it.
• Products described by nickname, by a code superseded two catalogue revisions ago, or by what they were called at a business you acquired.
• Quantities in mixed units. Ten. Ten boxes. Ten packs of a hundred. A length in metres for something you hold per metre and price per pack.
• Handwritten annotations on a scanned PDF, and the annotation is usually the important part: "as before but not the 25mm".
• A purchase order attached to a reply, buried in a thread whose subject line is about something else.
• A second email an hour later saying to ignore the first one.

This is why templates lose. A template works until the customer changes theirs, and you find out when the order is wrong. Rules engines lose for a related reason: they handle the cases somebody enumerated, and this variance is not enumerable. It is also why the job has stayed manual. The person doing it applies knowledge of your customers that has never been written down anywhere.

What changed recently is the input side rather than the reasoning side. On models with vision capability the API extracts both the text and an image of each page of a PDF and sends both to the model, so a scanned purchase order with a note in biro is now in scope in a way that character recognition followed by pattern matching never really was. The practical constraint is size rather than messiness: each file must be under 50 MB, which is also the combined limit across all files in a request.

What it has to get right, and the check that decides each one

Four jobs, and none of them is "understand the order". That framing produces demos instead of systems. Each job is a check with a pass or a fail.

Notice what is absent from that table: how confident the model says it is. A model's own reported confidence is not a control. It correlates loosely with being right and can sit comfortably high while being wrong. Build the threshold out of facts you can check independently instead, an exact match against your catalogue, a price retrieved from your own price list, a unit that exists on the product record. Those tests are deterministic, and they hold when the model underneath changes, which it will.

The confidence threshold is the design decision, and setting it too high is what kills it

Everything above serves one question. At what point does the agent write the order, and at what point does it put the order in front of a person?

Set the line too low and you find out quickly. Wrong orders reach the yard, someone on the trade counter loses confidence, and the project acquires a reputation it does not recover from. Everybody anticipates this failure, which is precisely why it is not usually the one that happens.

Set it too high and nothing visibly goes wrong, which is why it is the one that does. Every order routes to a person for review. That person now reads the order and also checks a machine's version of it, which is more work than reading the order was. Nobody can point at a defect. The agent is quietly worse than the process it replaced, and inside a month the reviews are being rubber-stamped or the system is switched off. A threshold set high enough to feel safe on day one is high enough to be useless by day thirty, unless somebody is actively moving it.

Three things make a threshold workable.

Escalate the line, not the order. The most common design error and the most expensive. If one line cannot be resolved, most implementations park the entire order, so the human workload barely moves, because orders with one awkward line are most orders. Write the lines that pass, hold the one that does not, and tell the reviewer which line and why.

Escalate with the working shown. "This line is either A or B, here is the original text" is a five-second decision. "Please check this order" is a five-minute one. What the reviewer sees decides whether the system saves anyone time.

Move the threshold on evidence, weekly at first. Every escalation is a labelled example handed to you for free. If the agent has escalated the same category for a fortnight and a person has agreed with its first candidate every time, promote that category. If something it writes keeps being corrected downstream, pull that category back. A threshold nobody revisits is one set by whoever guessed on the first day, and it will be wrong in both directions at once.

Stock and quoting are the same machine pointed at a different question

Availability belongs at the point of order, not the point of picking. Confirming an order and ringing back the next day to say two lines are on a lead time costs more goodwill than saying so in the acknowledgement. An agent that reads an order but cannot see stock is a drafting tool.

Substitution is a commercial decision, not a technical one. Whether a customer will accept an equivalent, and whether you want to sell it at that margin, is your rule and not a model's judgement. Write the equivalence rules down, hold them where the business can edit them without a developer, and let the agent apply them. If nobody will own those rules, the agent should offer the substitution to a person rather than make it.

Quoting is order entry with the price left open, running the same four checks against customer-specific pricing, contract terms and volume breaks. One failure is specific to it: do not let the model calculate the price. It should retrieve the price from the customer's terms and assemble the quote around it. Arithmetic is not what you are paying for, and a model that computes a volume break will eventually compute one wrongly in a document carrying your name.

When it fails, it is usually the product data, and that is not an AI project

The most common reason one of these does not work is that the catalogue cannot reliably be matched against. Being blunt about this changes what you should be buying.

The symptoms are familiar. Descriptions that only mean something to someone who has worked there for years. Superseded codes still active alongside their replacements. The same physical item under three codes inherited from three acquisitions. Units recorded inconsistently between the ERP and the price list. A description field quietly used as a notes field for a decade.

The test costs nothing. Take fifty recent orders, hand them and the catalogue to somebody competent who has not worked there for ten years, and count the lines they cannot resolve. Whatever defeats them will defeat an agent. No amount of model quality touches it. This is a data project, it is phase one of the work, and a supplier who does not say so before you sign is selling you the interesting part and leaving you the rest.

Duplicate customer records are the same problem on another axis. Three records for the same builder, and only one carries the agreed price list and the credit terms. An agent that picks the wrong one applies the wrong terms to a real order, and the customer finds out before you do. Those controls apply whenever software writes to a live record and are worth understanding before you commission anything: we have written separately on governing AI write-access to your CRM.

The third failure is the quiet one. No audit trail. If you cannot see what the agent read, what it matched, what it rejected and why it escalated, you cannot tune the threshold, so the system never improves on day one. You also cannot answer a customer who insists they ordered something else. Log it per line, decided at design time. Nobody has bolted this on after an incident and been pleased with the result.

The agent has to reach the systems holding stock, price and the customer

None of this works if the agent cannot get to the answers, and the answers are not in the email.

The shape is consistent across distributors, merchants and wholesalers. An ERP or trade counter system holds the catalogue, the stock and the pricing. A CRM holds the customer, the agreed terms and the history. Somewhere the documents land, usually a shared mailbox nobody has audited in years. The agent needs read access to the first two and a write path into whichever system owns the order.

Most of the cost and nearly all of the risk sit here rather than in the model. Reading an order well is close to a solved problem. Getting a validated order into a trade ERP specified before anyone in the building had heard of an API is not, and that is the part to scope carefully and to make a supplier be specific about before you sign.

Reading and writing also carry different risk. Reading stock is low-stakes and easy to back out of. Writing an order is a system-of-record write, and it needs the shape of every value enforced rather than requested. Structured Outputs holds a model's answer to a JSON schema rather than to a polite request for valid JSON, so a quantity field receives a number or the write is rejected. Reject rather than coerce, because a tidied-up wrong value is far harder to spot than an obviously broken one.

Does a workspace agent already do this?

This has to be asked honestly, because a good deal of what used to need engineering no longer does. OpenAI introduced workspace agents on 22 Apr 2026 and describes them as an evolution of GPTs. They run on a schedule, can be triggered, run in the cloud while the user is offline, work in Slack as well as ChatGPT, connect to external apps, carry version history and approvals on write actions, and can be shared across a team. For a lot of operational work that is now sufficient, and where it covers the job nobody should be quoting you for a build.

Order entry sits outside it, for reasons about this job rather than about the product:

• The end of the process is a schema-enforced write into a system of record. A well-written prose summary of an order is not an order.
• The same input has to produce the same output, against a threshold you set, tune and can explain to a customer.
• The systems holding trade stock and contract pricing are frequently not ones the connectors reach.
• You need a per-line audit trail you own, both to improve the threshold and to settle a dispute.
• As at 08 Aug 2026, if another system triggers a run, the agent's response cannot currently be retrieved through the API. You can start the work from your order mailbox, but you cannot get the answer back and act on it, which is not an order pipeline.

Where a subscription genuinely helps is proving the reading half before you commission the building half. Point one at the same fifty orders you used for the catalogue test, have it produce structured drafts into a document, and have the person who does the job today mark them. Poor drafts have taught you something cheap about your product data. Good drafts have given you a labelled sample to hand to whoever builds the real thing, and a better idea of where the threshold should start. Prove it somewhere that will still exist, though: Agent Builder shuts down on 30 Nov 2026, so it is not the place for a prototype you intend to keep. The wider boundary between a configured assistant and a built system is covered in Custom GPTs versus a properly built agent.

What to settle before you spend anything

Order entry passes the four conditions more cleanly than almost anything else in a distribution business. The input resists templates, the output has a schema, the rules already exist, and a system is waiting for the result. Stock and quoting are the same machinery aimed at adjacent questions, and they open up once the first one works.

The questions to put to whoever proposes to build it are not about the model:

• Run your product matcher against fifty of my real orders and show me the lines it could not resolve.
• Where does the threshold sit on day one, who is allowed to move it, and what evidence moves it?
• Does it escalate the line or the whole order, and what exactly does the reviewer see?
• What does the log record for each line, and where does that log live?
• What is your assessment of my product data, and what does phase one look like if it is poor?

If those five have answers, the choice of model is a detail you can revisit. If they do not, the model is irrelevant and what you were shown was a demo.

We built an AI order-entry agent for a UK builders' merchant that reads incoming orders and writes them straight into their CRM, replacing a planned offshore hire budgeted at over £20,000 a year. We are a HubSpot Diamond Solutions Partner and an OpenAI Select Partner, we build AI implementations on whichever platform suits the workload, including OpenAI, and we resell nothing and take no margin on your usage.

If you are earlier than this and still weighing the options, start with what ChatGPT and the OpenAI API actually do for a UK business.

Request a quote. Bring fifty recent orders and your product catalogue, because that is what the first honest conversation is actually about.