How do you process orders that arrive by email and PDF?

Your customers send purchase orders the way their systems let them: a PDF attached to an email, sometimes a spreadsheet, occasionally a photograph of a printed form. Someone on your team opens each one, finds the customer in your system, types in the lines, checks the codes against the product list, and sends an acknowledgement. On a busy morning, orders queue behind other emails, and the one typed in a hurry has a quantity wrong that nobody notices until the goods arrive.

This is a process with a shape. The documents vary, but what you need from them doesn't: who is ordering, what, how many, for when, and where to. That's what makes it a good candidate.

What the system reads, and how

The system watches the order inbox. For each new message it saves the attachment, records who sent it and when, and reads the document into fields. For a typical purchase order that means the customer and their reference, the delivery address, the requested date, and each line: your product code or the customer's, the description, the quantity, the unit price if they've stated it.

Reading is two different jobs depending on the document. A PDF generated by the customer's system has a layout that's the same every time, and once the system has seen a few it reads them reliably. A scan or a photo is read as an image first, which works for printed text and is less sure with stamps, handwritten notes and the quantity someone corrected in pen. The system knows the difference, and it should carry a confidence with every field it reads, because that's what decides the next step.

Checking before creating

Reading the fields is not the same as having an order. Before anything is created, each field is checked against what you already know.

• The customer matches a record in your system, by name, account number or the email domain they sent from.
• Each product code matches your product list, or the customer's code is one you've mapped to yours before.
• The quantity makes sense for that product: a pack size you sell, a volume this customer has ordered before.
• The price, if stated, matches the price list or the customer's agreed terms.
• The delivery date is possible, and the address is one you've delivered to or one the customer has given before.

When every check passes, the order is created in your system with the original document attached, and the customer gets an acknowledgement listing what was ordered and when they'll have it. When a check fails, or a field was read with low confidence, the order isn't created. It goes to a person.

The person step

The person sees the original document on one side and the fields the system read on the other, with the uncertain ones marked and the reason: couldn't read the date, product code not found, quantity unusually large for this customer. They correct what needs correcting and confirm, and the order is created from there. A minute's work, instead of the ten minutes of typing it used to be, and they only see the orders that needed them.

The same screen is where the system learns. When a person maps a customer's product code to yours, the next order with that code passes without them. When they confirm a new delivery address, it's known from then on. The share of orders that need a person falls over the first months, and the ones that remain are the real exceptions.

This matters for a reason beyond time. An order created wrongly, without anyone looking, is worse than an order typed wrongly by a person, because nobody expects it. The rule that keeps the process trustworthy is simple: the system never creates an order it isn't sure of. It asks.

Orders that should never be created automatically

Some orders should go to a person even when every field reads cleanly, because the cost of a wrong one is out of proportion to the minute saved. Write this list down before anything goes live, in the same way you'd write the conditions for an approval.

• The first order from a new customer, or from a customer who hasn't ordered in a long time.
• An order above a value you set, or a quantity far beyond what that customer usually takes.
• A price on the order that's below your floor for that product, which usually means an old price list on the customer's side and a conversation to have.
• Anything that references an order already in progress, where a change could collide with picking or shipping.
• Special instructions in the body of the email that don't map to a field: a different delivery window, a request to hold, a note about packaging.

These orders still arrive with the fields read and checked, so the person's job is to confirm, not to type. The list is reviewed after a few months, and some items move off it once the system has shown how it handles them.

What the customer notices

Two things. The acknowledgement arrives within minutes instead of hours, and it's accurate, because it's generated from the order that was created rather than typed separately. And when they email to ask where their order is, the answer comes from the same record, so the status question can be answered without anyone looking it up.

Customers who send orders as spreadsheets or in the body of an email are handled the same way: read into fields, checked, created or queried. Customers who phone orders in are a different process, and worth keeping separate until the written ones are running well.

How to start

1. Collect a month of incoming orders and sort them by how they arrived and what they look like. You'll find most of them come from a handful of customers in a handful of layouts.
2. Count them, time the processing, and count the orders that had to be corrected after creation. That's the baseline.
3. Start with the customers whose orders arrive as system-generated PDFs. They read most reliably and they're usually the highest volume.
4. Run the system in a mode where every order goes to a person for confirmation, for a few weeks. This is where product code mappings and address records get built up, and where you see how often the reads are right.
5. Switch on automatic creation for orders that pass every check. Keep the person step for everything else.
6. Add the scanned and emailed orders once the first group is steady.

What to measure

• Cost per order processed: the hours spent on order entry each month, costed, divided by the orders.
• Errors and re-work: orders corrected after creation, wrong quantities shipped, credit notes raised because of an entry mistake.
• Time from order received to acknowledged, which is what the customer feels.
• The share of orders created without a person, tracked over the first months as the mappings build up.

Invoice and document processing on our Operational Efficiency page covers this kind of work. If you'd like to talk through how your orders arrive and how many need a correction today, bring a few examples to the first call.