The agent watches the order mailbox, reads the purchase order — body text or PDF — checks it against your master data, creates the sales order, and replies with an acknowledgement in the same thread. Minutes, not tomorrow morning.
The dashboard is behind a login, because it shows live customer orders. Ask us for credentials.
Please supply against the attached PO. Delivery to our Jamshedpur yard, same terms as last month.
📎 PO-4500198231.pdf · 2 pagesOrder acknowledgement, three lines priced, requested delivery confirmed, with the ship-to ambiguity called out so your customer corrects it before dispatch — not after.
Every PO that arrives by email gets read by a person, keyed into the system by a person, and acknowledged by a person — if there is time before they go home.
Customer service spends its morning transcribing PDFs. The job needs judgment maybe five percent of the time, and it is paid for the other ninety-five.
The customer waits, then chases. The chase is another email your team answers by hand.
A blocked customer, a quantity below the minimum lot, an order that pushes past the credit limit. All catchable, all missed on a busy morning.
One inbound email runs the same path every time, and the run log records what happened at each stage — including the stages it deliberately skipped.
Reads new mail from the order mailbox and holds its position across restarts.
Allowlisted senders only, auto-replies rejected, and a ledger that makes double-replies impossible.
Reads the order out of prose and PDF attachments into a schema-validated intent.
Order, or not an order. Anything that isn't gets logged and left alone, never answered.
Customer, blocks, ship-to, materials, minimum quantities, pricing, credit limit. All deterministic.
Creates the sales order and the payload your system expects. Skipped entirely if a check failed.
Replies in the original thread — acknowledgement, or a holding note plus an internal escalation.
The interesting part of an order agent is not the happy path. It is what happens when the customer's PO is missing a material code, the quantity is under the minimum lot, or the order would break the credit limit. Every check is plain code with a recorded result — no model gets a vote on whether your rules apply.
No sales order is created. The customer gets a holding reply that names what is missing, and your team gets the escalation.
A durable ledger claims each message before work starts, so a restart mid-flight cannot produce a second acknowledgement.
Every run keeps the extracted intent, each check result, the payload, and the reply. Reconstructing "why did this order go through" takes seconds.
Every run as it happens: what arrived, what was extracted, which checks passed, what was sent. Password-protected, and it fails closed if the password is missing.
Scanned or generated, table or paragraph. The extraction is schema-validated, so a half-read PO fails loudly instead of booking half an order.
Only mail from customers you approved is processed. Newsletters, bounces and auto-replies are turned away at the guard.
Customers, materials, minimum lots, price lists, credit limits. The engine is deterministic and unit-tested against your rule set.
Pilots run against a simulated backend so nothing touches production. The payloads are built to the interface your ERP already exposes, so switching over is a config change, not a rewrite.
A PO that lands at 23:40 is acknowledged at 23:44. Your team reads the summary in the morning instead of the backlog.
Cost follows order volume and how many rule sets and plants sit behind it. We size it with you before anything is signed, and a pilot runs on one mailbox with a small allowlist.
A pilot runs on a copy of your mailbox with your master data and your rules. You see what it books, what it holds, and what it escalates — before it ever touches a customer.