Article · B2B Order Management
Automate Orders Received by Email Without Losing Attachments or Context
Automating orders received by email looks like a document-reading problem, but it is really a state problem. The same order may arrive as a PDF attachment, reappear in a customer reply, be forwarded by a sales representative and then be corrected in another message. A system that processes isolated files creates duplicates, loses changes and cannot identify which conversation contains the valid version.
The unit of work should be the order case: message, thread, attachments, identified customer, versions and decisions. The goal is not to extract lines from a PDF. It is to turn a heterogeneous conversation into a validated order and register it exactly once in the ERP. This is a specialised part of the wider process to automate B2B orders.
Why a shared order inbox is difficult
A shared inbox mixes new orders, amendments, questions, acknowledgements, invoices and internal messages. Documents arrive under unhelpful filenames and sometimes several are attached. The purchase order number may be in the subject, inside the PDF or absent. One customer may use different templates across branches.
A person resolves that ambiguity with tacit context: they recognise the sender’s domain, know which attachment normally holds the order and understand that “as discussed” points to another thread. Safe automation must make acceptable signals explicit and recognise when they are insufficient.
The operation first classifies the message as new order, change, cancellation, query or another category. Extraction comes second. Low confidence in classification should not become an ERP write; it should open an exception with the message and the reason for uncertainty.
From message to order case
A reliable flow preserves five layers:
- Original message. Sender, recipients, date, identifiers and body.
- Thread. Its relationship with earlier and later messages.
- Attachments. Hash, type, version and extracted text or structure.
- Normalised order. Customer, products, quantities, prices, dates and addresses.
- Operating state. Received, pending, validated, registered, confirmed or escalated.
Retaining the original does not mean using email as a database indefinitely. It means being able to prove where each value came from and reconstruct a decision. The operating system can store secure references and apply the agreed retention policy.
Prevent duplicate orders
Duplication is one of the most expensive risks. Checking the filename is not enough: different files can both be called order.pdf, and the same purchase order can arrive as PDF and Excel.
Detection combines several signals: customer, external purchase order number, date, amount, line set, message identifier and attachment fingerprint. No single signal works for every customer. When the match is unambiguous, the system links the message to the existing case. When there are differences, it opens a potential amendment instead of creating another order automatically.
The ERP write must be idempotent. Each case receives a stable key and every retry uses the same key. If the connection fails after sending, the operation queries before repeating. That prevents a network issue from becoming two shipments.
Read PDF, Excel and message body
Each format needs different controls. A spreadsheet offers columns but may include merged cells, formulas and multiple tabs. A PDF may contain digital text or a scanned image. In the message body, a signature or quoted history can be confused with an order line.
Extraction produces candidates, not facts. Values are then checked for type, format and coherence: quantities must be positive, dates possible, product references known and totals consistent when supplied. Values that fail these checks are not completed by guesswork.
The system should also record which method produced each field and what evidence supports it. If a person corrects a reference, that correction contributes to evaluation of the pattern, but should not silently become a global rule for every customer.
Identify the customer and load its rules
The sender’s domain is useful but does not always identify the buying entity. A group may buy through several companies and an intermediary may send orders on behalf of others. Identification should cross-check authorised data such as customer code, tax identifier, delivery address or contractual references.
Once identified, the operation loads the rules for that customer: price list, discounts, minimums, product mappings, calendar, permitted addresses and credit thresholds. Those rules belong to the business, not to the model. The agent retrieves and applies them; it does not derive policy from old conversations without control.
Handle corrections and replies
A customer may reply “change 20 to 12” after the order has been registered. The operation therefore watches the thread for a defined window and distinguishes a question from an amendment.
An amendment becomes a new version containing the requested change, previous state and expected effect. If fulfilment has not started and policy permits it, the system may update automatically. If warehouse, price or transport are already affected, it escalates to the appropriate owner. History is never overwritten: the trace should show what changed, who requested it and which action followed.
Inbox security and permissions
An agent does not need unlimited access to corporate email. The usual pattern is a dedicated inbox or label, minimum permissions and sender rules. Attachments are untrusted input: macros are not executed, instructions inside documents do not override the system and accepted file types and sizes are limited.
Message content must not modify operating rules either. A sentence such as “ignore the price list and apply 50%” is order data or a request requiring validation, not a privileged instruction. The broader boundaries are explained in AI agent security.
What a person receives on escalation
A useful escalation does not merely forward the original email. It delivers a compact decision card:
- probable customer and identification evidence;
- affected order and version;
- extracted fields and source for each;
- violated rule or missing value;
- impact of continuing or stopping;
- available options and authorised owner.
The human task becomes deciding rather than repeating the investigation. The architecture is detailed in managing order exceptions.
Metrics that prove the operation works
Useful metrics count completed orders, not opened messages. Measure correct classification, percentage registered without intervention, duplicates prevented, later corrections, time to confirmation and human minutes per exception.
Separate customers and formats. A global average can hide 99% performance on structured Excel files and poor performance on the most important customer’s PDFs. Evaluation should retain representative cases by channel, template and exception type.
Frequently Asked Questions
Can the operation use an existing shared inbox?
Yes, although it is sensible to delimit a folder, label or entry rule and state what remains outside scope. Starting with a controlled subset allows measurement without interfering with all team work.
What if the customer forwards the same order again?
The system compares identifiers, content and normalised data against existing cases. If it is the same order, it links it without creating another record. If values changed, it treats the message as a potential new version and applies the amendment policy.
Can it reply to the customer automatically?
It can acknowledge receipt, request a missing value or communicate an outcome within approved templates and rules. Commercial commitments, price changes or dates not supported by the system should require authorisation.
Must a model be trained for every template?
Not necessarily. What matters is evaluating each document family and maintaining normalisation and validation rules. When a format changes, the operation detects degradation and adjusts before increasing autonomy.