How to stop retyping order emails into your system

The job being replaced

It looks like this. An order arrives by email. Someone opens it, reads it, and types the customer, products, quantities and delivery details into your order, stock or accounts system. Then the next one.

At a handful a day, it’s a nuisance. At hundreds a day, it’s somebody’s job. And every one is a chance for a typo to become a wrong delivery.

I run a system like this for a UK glass manufacturer. In the last 30 days it read 7,369 emails, from typed purchase orders to photographed, handwritten faxes. The case study covers it in full. This post is the general version: how it works, and what I learned building it.

Three ways to do it

Which one fits depends on what your emails look like.

1. The emails are already structured

Some customers and suppliers send orders as a spreadsheet, a CSV file or a fixed-format email generated by their own system. Every order has the same layout.

These are the easiest. The automation reads the attachment or the fixed layout with plain rules. No AI needed.

2. The emails are consistent but written by people

Regular customers often send orders the same way every time, just typed out. “Hi, can we have 4 x product A and 2 x product B, delivery Thursday.”

Rules can handle a surprising amount of this, especially if each customer has their own pattern. It gets fragile when there are lots of customers each writing differently.

3. Every email is different

This is where AI earns its place. A language model reads the email the way a person would and pulls out the details: who it’s from, what they want, how many, when, where to.

The important part is what happens next. The model’s answer isn’t trusted on its own. It’s turned into a fixed set of fields and checked, just like a careful person would check their own typing.

The checks that make it reliable

This is the difference between a demo and something you can rely on. Before anything is entered into your system:

• Does the customer exist? Match the sender against your customer list.
• Do the products exist? Every product code or name must match something you sell.
• Do the numbers make sense? Quantities within normal ranges, totals adding up, dates in the future.
• Has this email already been read? Every email has a unique message ID, so the same one can never be processed twice.
• Is anything missing? No delivery address means no automatic entry.

If every check passes, the order goes straight in. If any fail, it doesn’t.

When an email can’t be read

Some won’t be. A forwarded chain with three orders in it, a photo of a handwritten note, a customer asking a question instead of ordering.

Those go to a short queue for a person to handle, with the reason attached: “product code not recognised” or “no delivery date”. Your team stops reading hundreds of emails to find the orders, and starts checking the few that need a person.

That queue is a feature, not a flaw. A system that never asks for help is one that’s quietly guessing.

What I learned building one

The general approach above is the easy part. The detail is where the work is. A few things that came up in the order system I run:

• Dates are harder than products. A day name with no date, “ASAP”, a handwritten date in a margin, a date range, two dates that disagree. The system now counts lead times in working days and flags anything doubtful for a person to confirm, rather than guessing.
• Learn from every correction. When staff fix a date or a product match, the fix is kept against that customer and used the next time. A customer whose forms kept being misread now gets read the way staff corrected it.
• Forms lie. Printed tick boxes on a blank form were being read as ticked. Schematic pages for each unit were being counted as extra units. Some email programs strip line breaks, so “2 - 1235 x 395” ran into the next line and a size of 395 became 3952. Each of these was found on real orders and fixed with a test so it stays fixed.
• Domain knowledge matters. Glass is cut to the size below, so 667.5mm has to round down to 667mm, not up. No general-purpose tool knows that.
• Match the model to the document. Typed PDFs go to a cheaper, faster model. Photos and scans, where handwriting causes misreads, go to a stronger one. That keeps the AI bill in proportion.
• Keep the people in the loop. Every order still passes two checks by two different people before production. The system’s job is to do the reading and sorting so those checks are quick.

Getting orders into your system

The other half of the job is the system the orders go into. In order of preference:

1. An API. Most modern order, stock and accounting systems have one. The automation enters the order directly, the same way your team does.
2. An import. If there’s no API, many systems accept a spreadsheet or CSV import. The automation prepares the file.
3. Something else. Older systems sometimes need more creative approaches. That’s worth finding out before you commit.

You don’t have to do this part first. In the glass system, staff still key checked orders into the production system, with everything already read and laid out for them. An import file that sends orders straight in is the next stage, now in testing.

What about the data?

The emails contain customer details, so it matters where they go. For fixed-format emails, no AI is involved. Where AI is needed, it can be a commercial service under business terms or a model on servers you control. Where your data goes explains the options.

Is it worth it for you?

Count the order emails you get in a month and estimate how long each takes to enter. Multiply them together. If it comes to dozens of hours a month, it’s worth a look. What AI automation costs has the typical prices and a way to work out the payback.