Email Data Extraction Automation
A mailbox is a queue of work in an unstructured format. Orders, enquiries, bookings and updates arrive as prose, sometimes in the body, sometimes in an attachment, sometimes at the bottom of a thread with nine replies above it.
Discuss your projectWhat we extract
Orders sent by email
Still how a great deal of B2B ordering happens. Products, quantities, delivery address and required date, pulled from the body or an attached order form and written into your order system.
Enquiries and leads
Contact details, what they are asking about, budget or timescale where stated, written to your CRM as structured fields rather than as a pasted email body.
Booking and appointment requests
Who, what, when, including the ambiguity — "next Tuesday afternoon" is interpreted against the email's own date and flagged if it is genuinely unclear.
Supplier confirmations and shipping updates
Acknowledgements, dispatch notices and tracking numbers matched back to the order they belong to.
Forms and applications sent as attachments
Where the real content is a PDF or spreadsheet and the email is just the envelope.
Remittances and payment advices
Which invoices a payment covers, which is the information that makes cash allocation possible rather than manual.
Why email is harder than it looks
A PDF invoice has a layout. An email has whatever the sender typed. The same customer will send an order as a bulleted list one week and a sentence the next, and the information you need may be in the body, in an attachment, in an image pasted into the body, or implied by the thread.
Threads are the specific difficulty. The newest content sits at the top, above a quoted history that may contain an earlier, superseded version of the same order. A naive extraction reads the whole message and takes figures from the quoted part, producing an order the customer cancelled two replies ago. So the pipeline separates the new content from the quoted history first, and where a thread genuinely amends an earlier instruction it is routed to a person rather than guessed at.
Then there is the noise: signatures with addresses and phone numbers that are not the delivery address, legal disclaimers, out-of-office replies, and automated notifications that look like real messages. Each needs recognising and discarding rather than extracting.
How it runs
- 01
Connect the mailbox
Microsoft 365 or Google Workspace, read-only on a shared mailbox rather than an individual's. We do not need, and would not ask for, access to personal inboxes.
- 02
Classify first
Is this an order, an enquiry, a remittance, a reply in an existing thread, or noise? Nothing is extracted until the type is known, because the fields depend on it.
- 03
Separate new content from quoted history
Then read body, attachments and embedded images as one document set.
- 04
Resolve the sender
Matched to an existing customer or supplier record where possible, which supplies the context that makes the rest unambiguous — their usual delivery address, their price list, their account terms.
- 05
Validate and route
Do the products exist, is the quantity plausible, is the delivery date possible. Clean records go through; anything uncertain goes to review with the original email beside the extracted fields.
- 06
Write and acknowledge
Into your order system or CRM, with an acknowledgement back to the sender if you want one — which also surfaces misreadings quickly, since customers correct an acknowledgement that is wrong.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch