Order emails in, purchase orders out
What the customer asked for, in the words of the call, and what this prototype sets out to prove. Buyer names are left out on purpose.
“The input will be your email. Only the order email should be taken into the consideration.”
“The output will be — the PO has to be inserted into the ERP system … and then the flow starts from there.”
“It has to know which product the customer is requesting and it has to choose that, and then color, size, and which logo has to go on which product.”
“If it's a t-shirt, they will say left chest … or back, full back, or sleeve.”
“We can code all those things out. But if we figure out a way to automate that, it'll be fantastic.”
| Input | A dedicated order inbox the shop and its buyers can send to. Seeded with 100–200 invented emails; buyers' real samples follow. |
| Sort | Only new orders and order changes go forward. Quotes, artwork approvals, shipping questions, newsletters and spam are labelled and left alone. |
| Read | Product out of hundreds, colour, size run, and every logo with its location, method, size and ink or thread. |
| Store | One row per field: the value, the email's own words it came from, and the check code ran on it. |
| Enter | A complete PO in a mock ERP, a PO list with the order flow, and a full PO screen. |
| Ask | An incomplete order is held with a drafted question to the buyer — never guessed. |
| Confirm | The buyer gets back exactly what was entered, and confirms it. |
| ERP | Level 1: the confirmed PO becomes a sales order; blanks are checked against stock and the shortfall is ordered. |
| Floor | Level 2: one job ticket per decoration, held until the proof is approved, scheduled before the in-hands date. |
| Invented data | Every buyer, email and order on these screens is made up. Your own products, buyers and sample emails replace them. |
| Mock ERP | The purchase orders land in a stand-in ERP. In the rollout the same PO posts into your own ERP. |
| Mail not wired yet | The inbox here is a picture of one. The live version reads a real Gmail inbox — next step. |
| 1 | A dedicated Gmail inbox is set up for the demo, and sample order emails are sent to it — including yours. |
| 2 | The system reads every unread email in that inbox, keeps only the orders, and creates the purchase orders. |
| 3 | Each email it has handled is labelled in Gmail, so it is never read twice. |
| 4 | A live demo: send an order email, press Read unread mail, and watch the PO appear. |
| 5 | Measured on a set of 200 sample emails with known answers, so the accuracy is a number, not a promise. |
Inbox — orders only go forward
The dedicated order inbox. Every unread email is read and sorted first; only new orders and order changes become purchase orders. Everything else is labelled and left alone.
Click any field on the right — the line of the email it came from lights up on the left. Nothing is filled in that the email does not say.
Purchase orders
Every order the desk has entered, and where it is in the flow, plus the orders held for a buyer’s answer. Open a row to see the values that were picked up from the email and stored.
PO detail
The full purchase order as it lands in the ERP. The small grey line under each block names the email line it was read from.
Behind the scenes — one row per field
This is the scratch table the desk writes before anything reaches the ERP: the stored value, its type, the exact words it came from, and the check that code ran on it. A field whose check fails never posts.
Review queue
When an order is missing something the shop needs, the desk does not invent it. It holds the order and drafts the question back to the buyer for a person to send.
Buyer confirmation
Once the PO is in, the buyer gets back exactly what was entered — so a wrong size or colour is caught before a single shirt is printed.
Order workflow
Once the buyer confirms, the PO goes into the ERP and the shop's own flow starts: level 1, the order and the blank garments it needs; level 2, one job ticket per decoration on the production floor.
Connect & ERP
The prototype proves the hard part — reading real order emails into a correct PO. Connecting a company's own mail and ERP is standard integration work, called out here so nobody mistakes the demo for the rollout.
One dedicated Gmail inbox
- A demo inbox the shop and its buyers can send to
- Read-only access; nothing is deleted or moved
- Seeded with 200 invented emails, each with a known right answer
Gmail, Outlook, Apple Mail
- Google Workspace / Gmail: OAuth sign-in, read-only scope, Google's security review
- Microsoft 365 / Outlook: OAuth through Microsoft Graph
- Apple Mail on macOS and any other host: IMAP with an app password
A mock ERP with a real PO screen
- Purchase orders, lines, sizes and decoration stored as shown on Behind the scenes
- Order status from received to shipped
Embedded in the shop's own ERP
- Posts the same PO through the ERP's API
- Or a file drop (CSV) or EDI 850 where the ERP takes those
- Product and colour lists read from the ERP, not typed
Every number on the finished use case comes from a run
| Measure | Over | Result |
|---|---|---|
| Order emails told apart from everything else | 200 emails | measured after build |
| Right product, colour and size run | every PO line | measured after build |
| Right logo on the right location | every decoration | measured after build |
| Incomplete orders held, never guessed | every incomplete email | measured after build |
| Cost per order read | every model call | measured after build |