One illustrative order email followed through all six steps, from the inbox notification to the logged order, with the checks, the review queue and the cost per email.
Here is an email of the kind that lands in an orders inbox every few minutes. It is illustrative, like the business in this post:
Hi, can we get 12 cases of the sourdough 800g and 6 rye for Thursday? Same as last week otherwise but drop the croissants. PO 4471. Thanks
Automating it takes six steps: catch it, classify it, extract the order as structured data, check that data against your records, send doubtful ones to a person, then create the order and log it. At current model prices the AI part of handling this email costs well under a cent. Most of the work sits in steps 4 and 5. Below, PO 4471 goes through each step at a made-up wholesale bakery getting 250 order emails a weekday.
Step 1: Catch the email the moment it lands
Gmail can push a notification the moment mail arrives, through Google Cloud Pub/Sub. The Gmail push notification guide has two details that bite later: the watch must be renewed at least every 7 days, and each mailbox is capped at one notification per second, with the excess dropped.
So treat the notification as a nudge. It carries only the mailbox address and a history ID. Store the last ID you processed and, on every nudge, fetch everything since then. Dropped notifications in a Monday rush then cost you nothing.
Outlook does the same through Microsoft Graph, where a message subscription lasts at most 10,080 minutes. Schedule renewal for both and alert someone when it fails.
Step 2: Decide what kind of email it is
An orders inbox is never only orders. For the bakery we'd use six labels: new order, change to an existing order, cancellation, complaint, invoice or remittance, and everything else. PO 4471 is a new order that leans on an old one, the sort of email a keyword rule gets wrong. "Drop the croissants" would sail past a filter looking for "cancel".
Ask the model for the label, a confidence score (a rough sort key, not a probability) and one sentence saying why. The sentence is what your staff will read when they disagree. Complaints go straight to a person, whatever the score.
Step 3: Pull the order out as structured data
Extraction turns the email into fields your order system can take: customer, PO number, delivery date, and lines of product, quantity and unit. Don't ask for JSON in the prompt and hope. On Anthropic's API, structured outputs constrain the reply to the JSON schema you supply.
That covers the shape, not the truth. The same page says a refusal or running out of tokens can still break the schema, and that number limits such as a minimum or maximum aren't supported. A schema can insist quantity is an integer. It can't stop the model attaching the 6 to the wrong loaf.
Two phrases in PO 4471 the model shouldn't resolve itself. "Thursday" becomes a date in your code, from when the email arrived. "Same as last week" means fetching that customer's last order from your system. Have the model flag both and let the code fill them in.
Step 4: Check it against your own records
This is ordinary code with no AI in it, and it decides whether the whole thing can be trusted. The bakery's checks:
- Each product line matches one SKU. "Sourdough 800g" should hit one product, but "rye" with two rye loaves in the catalogue is a question.
- Quantities sit inside the range that customer normally orders. Twelve cases from a café that orders three is worth a look.
- The PO number is new, which catches the same email forwarded twice.
- Thursday is a delivery day on that customer's route, and the account isn't on credit hold.
Each failed check records a plain-words reason for the reviewer.
Step 5: Send the doubtful ones to a person
The review rule is where you choose the error rate you can live with. A sensible starting rule for orders: an email goes through on its own only when it's labelled a new order, every line matched one SKU and every check passed. Everything else lands in a queue showing the email beside the draft order, failed checks highlighted. When we build AI automation for order processing, anything sensitive sits behind a human approval like this, so the risky calls stay with your team.
PO 4471 goes to the queue. "Rye" matched two products, and last week's order brought in a croissant line the email asked to drop. In this illustrative run the reviewer picks the 600g rye and approves in about 20 seconds.
Expect a busy queue for the first fortnight. It shrinks as you add per-customer aliases ("sourdough" means the 800g for this café) and tune the ranges, the kind of rule where a fixed no-code filter strains, as covered in when Zapier stops being enough for order workflows.
Step 6: Create the order and keep the receipts
Once approved, the system creates the order in whatever you run (a Shopify draft order, an ERP, even a spreadsheet) and replies with the lines and delivery date it booked. If something was misread, the customer spots it fastest.
Log the email, the label and reason, the extracted JSON, each check and every reviewer edit. That answers "why did we send 12 cases?" in a minute, and the edits are what you tune against.
Here is the whole trace for PO 4471:
| Step | What happened to PO 4471 | Decided by |
|---|---|---|
| 1. Catch | Pub/Sub nudge arrives, message fetched from the stored history ID | Code |
| 2. Classify | New order. Reason given: quantities, a delivery day and a PO number | Model |
| 3. Extract | Two lines, PO 4471, "Thursday" and "same as last week" flagged as references | Model |
| 4. Check | Rye matched two SKUs, last week's lines loaded, croissants removed | Code |
| 5. Review | Rye 600g chosen, order approved | Person |
| 6. Act | Order created for Thursday, confirmation sent, log written | Code |
What error rate should you expect?
Nobody can give you that number for your inbox before seeing it, and a vendor who quotes one up front hasn't earned it. It depends on how messily your customers write and how many near-identical products you sell, so measure it before going live.
Have someone who knows the customers hand-label 200 emails from last month: category and correct order lines. Run the pipeline over them and count errors per field, not per email. Then run in shadow mode for two weeks, the system drafting every order while staff still key them in, and compare.
After launch, watch the error rate on orders that went through with no review. An illustrative bar: if more than one in 50 auto-approved orders needs fixing afterwards, tighten step 4 before widening anything.
What this one email cost to process
About four hundredths of a cent on the cheaper model. Illustrative figures: classification and extraction together send 2,000 tokens (instructions, a catalogue excerpt, the email) and get 400 back. At Anthropic's published rates for Claude Haiku 5.5, $0.10 per million input tokens and $0.50 per million output, that's $0.0004 an email. At 250 emails a weekday over 22 weekdays, 5,500 emails, the month comes to $2.20. On Claude Sonnet 5.5, at $2 and $10 per million, the same month is $44.
The Batch API halves those prices, but batches run asynchronously and Thursday's bread order shouldn't wait in one. Start on the smaller model and move up only for the step where it falls short on your labelled emails. The model bill won't decide this. Build time and review-queue minutes will.
The first automation is usually live in two to four weeks, after an audit in week one. The first job needs nothing built, though: export last month's orders inbox and start labelling those 200 emails.
Questions about automating an orders inbox
Can it read orders sent as PDF attachments?
Yes. Data in PDFs and forms can be extracted the same way as the email body, and the same checks in step 4 apply. Put a few scanned or photographed order sheets in your 200-email test set, since their image quality varies most.
Do we need to move from Outlook to Gmail?
No. Outlook and Microsoft 365 mailboxes send change notifications through Microsoft Graph, and the rest of the pipeline is the same. Stay on whichever mail system your team already uses.
Will our order emails be used to train someone else's model?
Not on the systems we build. They run on infrastructure you control, with scoped access and an audit log on every action, and we never train third-party models on your data.
What happens to emails that arrive while the system is down?
They wait in the inbox. Because the pipeline stores the last history ID it processed and asks for everything since then, it catches up on restart instead of losing the gap. Alert someone if the mailbox watch or subscription fails to renew.
