Order mailbox connection
A dedicated mailbox is monitored, and every incoming message is filed as its own case together with attachments, sender and timestamp.
Blueprint 01
Intelligent Order Processing
Emailed PDF orders become checked orders, with human approval where it counts.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.
Part of
AI Process AutomationStarting point
The problem.
Customer orders reach your organisation as an email with a PDF attached, each sender using their own layout. A member of staff opens the attachment, reads out the customer details and line items, transfers them into the order system and matches article numbers against the master data. The work is repetitive but demands full attention, because a transposed digit may only surface at dispatch.
Before · After
The same process, twice.
On the left, the process as it typically runs today. On the right, the same process once an application takes over the repetitive steps.
Today
How the process runs if nobody changes anything.
- 01Email arrives in the mailboxSystem
- 02Open the PDF attachmentHuman
- 03Look up the customer recordHuman
- 04Look up article numbersHuman
- 05Retype the line itemsHuman
- 06Check prices and termsHuman
- 07Raise a query by emailHuman
- 08Create the order in the systemHuman
- 09Write and send the confirmationHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Email captured automaticallySystem
- 02Attachment read and structuredSystem
- 03Validated against master dataSystem
- 04Deviation raised for approvalHuman
- 05Query with the customer, case visibly waitingHuman
- 06Order created in the systemSystem
- 07Confirmation drafted for sendingSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Interactive
The process, station by station.
The walkthrough stops at the point where a person decides. It continues only once you approve.
Flow
Step 1 of 7
- Inboxrunning
- Read the documentwaiting
- Match the customerwaiting
- Check master datawaiting
- Human approvalwaiting
- Create the orderwaiting
- Draft the confirmationwaiting
A dedicated order mailbox receives the email and files the message and its attachment unchanged. Before a case is created, the order number, subject and message thread are checked against open cases — amendments, cancellations and replies to queries land there, not as a second order alongside.
The visualisation runs in your browser along a fixed sequence — nothing is uploaded, nothing is sent and no language model is called.
- A dedicated order mailbox receives the email and files the message and its attachment unchanged. Before a case is created, the order number, subject and message thread are checked against open cases — amendments, cancellations and replies to queries land there, not as a second order alongside.
- The system reads the PDF and transfers header data and line items into one consistent data model.
- Sender, letterhead and order details are matched against the customer master data until the assignment is unambiguous.
- Article numbers, units of measure and terms are checked against the master data held in your systems.
- Anything that stays unclear or deviates from the master data goes to a responsible person for a decision: approve, approve with corrections, or query with the customer. In the last case the item visibly waits for the reply — with a deadline and an owner, rather than sitting in a mailbox.
- The approved order is created in the system of record through its interface.
- The created order produces a draft confirmation that can be reviewed before it is sent.
Features
What the system would need to do.
Every line is a commitment about future work — not a description of something that already exists.
Layout-independent extraction
Line item recognition relies on structure and meaning within the document rather than fixed coordinates, so an unfamiliar sender layout can still be processed.
Match against master data
Every recognised line item is mirrored against the article master, units of measure and customer-specific terms before it is passed on.
Confidence per field
Each field carries an assessment of how reliably the value was recognised, and below a defined threshold the case does not continue automatically.
Approval view with source
The recognised value and the matching place in the original document sit side by side, so a decision is possible without searching through the PDF.
Traceable case record
For every order the original document, the recognised values, later changes and the approving person remain available as one connected history.
Draft confirmation
The created order produces a reply draft in your own text template, which can be edited or released before it is sent.
Integration
What a system like this typically connects to.
Categories rather than vendor names — which product you run is decided by the system landscape you already have.
Email mailbox (Microsoft 365 or IMAP)
ERP or inventory management system for order creation
CRM for customer and contact records
DMS or file store for the original documents
Article and pricing master data from your line-of-business software
Notifications through your internal chat
Architecture
How this would be built.
One example structure in layers. Not the only one possible — but one we can justify.
Capture
- Mailbox connector that opens a case
- Object storage for original documents
- Queue for incoming cases
Understanding and checking
- Document processing with layout and text analysis
- Language model call with a fixed output schema
- Rule set for the master data match
- Confidence and threshold logic
Deciding and booking
- Approval interface with roles and permissions
- Order creation through the ERP interface
- Retry and error handling
Operations
- Event log per case
- Metric and error monitoring
- Encrypted storage with retention rules
Metrics
How success would be measured.
These are the figures that would be measured during a project. Deliberately no values are shown — there is no measurement they could come from.
Processing time per order
would be measured from the arrival of the email to creation in the system of record
Number of manual steps per order
would be counted from the user actions recorded in the case log
Error rate during data capture
would be derived from later corrections made to orders already created
Share of orders without manual intervention
would be calculated as the ratio of cases completed without an approval step to all cases
Time to order confirmation
would be measured from the arrival of the email to the sending of the confirmation
Expansion
Start small, then grow.
A project of this kind does not begin with the full build. It begins with the part that carries its weight soonest.
First stage: one mailbox, one document type
The build starts with orders from a manageable group of senders in a single mailbox; extraction and validation run, and creation in the system of record follows approval.
Second stage: breadth and rules
Further sender layouts, customer-specific terms and special cases such as partial delivery or drop shipment are added, and the thresholds are adjusted using the cases gathered by then.
Third stage: adjacent documents
Order confirmations, dispatch advices and incoming invoices follow the same pattern, so a document is understood once and then used several times.
Do you recognise your own process?
If your order intake looks like this, a first conversation can establish which of these steps hold up in your organisation and where the approval point sensibly sits.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.