How to automate order processing from email: rules, Make or an AI agent?

In wholesale, distribution and made-to-order manufacturing it repeats the same way: a customer emails an order and someone retypes it into the system. Two people, two hours a day, twenty working days — eighty hours a month in which nobody decides anything, they just retype. And retyping produces errors that are found at dispatch.

This article is about how to automate that. Not “whether” — that has been possible for years. But with what, because there are three quite different routes and each one breaks in a different place.

Why it is harder than it looks

If every customer sent orders the same way, a form would do. They do not. One writes the items in the email body, another attaches a PDF from their system, a third sends a spreadsheet with their own codes, a fourth photographs a delivery note and writes “same as last time, just 20 more”.

So the problem is not reading text. The problem is understanding: what is an item, what is a quantity, what is a note; which of your stock codes matches the customer’s “blue 40”; whether “deliver by Friday” is a deadline or a wish.

Route 1: rules and templates

The classic approach: a parser that looks for a known pattern in the email. It works very well as long as orders come from the customer’s system in a fixed format — then it is the cheapest and most reliable solution and there is no point dragging AI into it.

It breaks the moment you have many customers who all write differently. Every new format means a new template, and when a customer changes their invoice layout, the scenario quietly stops working.

When it is enough: a few large customers with a fixed format, or EDI.

Route 2: Make, Zapier or n8n with an AI step

Tools like Make or n8n can now insert a “process with an LLM” step into a scenario. For a pilot this is excellent: in a day you have something that reads an email and dumps the items into a table.

Where it breaks: on exceptions and state. The scenario is linear — the email arrives, gets processed, gets written. What if one email contains two orders? What if an item is not in the catalogue? What if the customer sends a correction an hour later? Each of these is another branch, and after the fifth branch the scenario becomes something nobody wants to maintain. And do not forget that your customers’ data now flows through another third party.

When it is enough: dozens of orders a month, a simple range, and you want to test the idea cheaply first.

Route 3: an AI agent with tools

An agent differs from the previous two in one respect: it does not get instructions, it gets a goal and tools. The goal is “create this order”; the tools are “read the attachment”, “search the catalogue”, “check stock”, “create the order in the ERP”, “hand to a human”. Between steps it decides based on what the previous step returned.

In practice it looks like this:

1. Reads the email and the attachment — text, PDF, spreadsheet, image. Extracts items, quantities, deadline, address.
2. Matches items to your catalogue. This is the hardest step and the most common reason cheap solutions fail. “Blue 40” has to end up as your code SKU-4471-BL, even if the customer wrote it differently last time.
3. Checks stock and prices directly in the ERP — via API or via MCP, if the system has an interface.
4. Creates the order and drafts a confirmation for the customer.
5. Hands exceptions to a person. Unknown item, price mismatch, missing date — the agent does not flip a coin, it flags the case and sends it to the approval queue.

That fifth point matters more than the first four. An agent forced to decide where it is unsure will start inventing. A good agent hands 10–30% of cases to a human — and that is a feature, not a failure.

When it makes sense: from roughly 15–20 orders a day, diverse customers, a range with a catalogue, an ERP with an API. We describe it in more detail on the page email order automation into your ERP.

What you need to have ready

Without these four things you cannot start properly on any of the routes:

• A catalogue in usable shape. If one product has three different codes in three systems, the agent will not fix that — it will only expose it.
• Access to the ERP. An API, the database, or at least an import format. If the ERP has none of these, a solution exists but it will cost more.
• A sample of 100–200 real orders from recent months, including the ugly ones. That is what you measure against.
• A person who will approve exceptions and has time for it during the working day. Without them the queue fills up and the project dies quietly.

Where it breaks in practice

Over the years we keep seeing the same four places:

• Catalogue matching. A solution that handled the demo on ten items starts confusing variants on a thousand items with similar names. What helps is a combination of search, customer history (“last time they ordered this”) and a confidence threshold.
• Multiple orders in one email, or one order split across three emails.
• Changes after sending. “Cancel item 3” an hour later. The agent has to know the order already exists.
• Photos and scans. OCR as a fallback is a must, but on a bad photo the system has to say “cannot read this”, not guess.

How to measure whether it works

Three numbers are enough, and they must be measured from day one of the pilot:

• Share of orders handled without a human. A realistic target with diverse customers is around 70%. Anyone promising 100% has not worked with real data.
• Error rate on the test set — how many items the agent matched wrongly. This has to be lower than the error rate of manual retyping, otherwise you have gained nothing.
• Time from email received to order created. From hours to minutes; for exceptions, seconds of approval.

None of these numbers can be stated without a test set — which is why we build it first, before tuning a single prompt.

What it costs and when it pays back

Indicatively, excluding VAT, for a small or medium company: analysis and sample €900–1,800, pilot on real emails €3,500–7,000, production rollout with ERP integration €6,000–15,000, operations from €390 a month plus model usage (tens of euros at normal volumes). We break down the ranges and the reasons they differ in how much an AI solution costs.

Payback with two people and two hours a day: roughly 80 hours a month, which at a typical hourly rate is around €1,000–1,500 a month. Production rollout pays back within about a year — plus fewer complaints caused by typos, which usually do not even make it into the calculation.

Summary

• A few customers with a fixed format: rules or EDI, no AI needed.
• Dozens of orders a month and you want to test cheaply: Make or n8n with an AI step, knowing you will hit a wall on exceptions.
• Dozens of orders a day from diverse customers: an AI agent with tools that can check stock and hands exceptions to a person.
• In every case: catalogue, ERP access and a sample of real orders first, then anything with AI.

If you can say how many hours a week someone spends retyping orders, you have a number to start from. We are happy to work it through with you — and if it does not pay off, we will tell you.