Inbox to Structured Record
Work that arrives as prose in an inbox, read and written into the system of record as a row.
The message is the trigger. Sender, intent and detail are read out of it, and the row lands in the system that owns it. Every run leaves a record.
How the work runs
Watch the inbox for a week
What actually arrives, in what forms, including the messages people have stopped noticing are unusual. A week of real traffic is worth more than a description of the process.
Agree the schema and the ambiguity rules
What gets extracted, and what should happen when a message is incomplete or contradicts itself. Those rules come from the person who currently makes that call in their head.
Run it beside the person doing the job
The automation extracts and the person still keys, and the two are compared until the extraction is trusted. That comparison is also where the accuracy figure comes from.
Hand it the writes
The automation starts creating records, with the exception queue and run monitoring live from the first day.
What this is
Every business has an inbox where work arrives as prose and has to become a row. An order, an enquiry, a booking, a claim, a referral, a request for a price. It is the same job whether that inbox belongs to sales, dispatch, claims or the front desk.
This automation reads the inbound message, pulls out the values that matter, and creates or updates the record in the system that owns it. What it does with an ambiguous message is agreed in advance rather than left to the model.
It is scoped by the message type. One recurring inbound message on one channel is a project. Every email the company receives is not.
What gets built
The extraction is the visible part. The matching, the write and the exception queue are what make it usable.
The field schema
Exactly which values come out of a message, what each one may contain, and what the automation does when one is absent.
Reading the messages you actually get
Forwarded threads carrying quoted history, the attachment that holds the real detail, three messages that are one order, and the customer who writes in a single paragraph.
Attachment handling
The message says see attached and the detail is in a PDF or a spreadsheet. The attachment is read into the same schema as the body rather than left for somebody to open.
Matching to what already exists
Deciding whether this sender is an existing customer and whether this is a new job or an update to one, before anything is written anywhere.
The write to the system of record
The row lands in the CRM, the job system or the accounting package through its own interface, with the original message linked from the record.
The acknowledgement
A reply to the sender stating what was understood. It is a courtesy and it is also the fastest way an extraction error surfaces.
An exception queue
Anything the automation is unsure about goes to a person, with the original message beside the fields that were pulled from it.
Run monitoring and a written trail
Every run records what arrived, what was extracted and what was written. A disputed record can then be reconstructed instead of argued about.
Where the work arrives as prose
Four inboxes that are, in practice, order forms.
-
A freight order in an email
Lane, dates, equipment and references written as prose, read out and written as a load so acceptance happens in minutes rather than after a queue. This is the shape with the most documented volume behind it.
-
A message on a phone
Enquiries arriving by text or a messaging app, including voice notes that get transcribed before they are read. The record lands in the CRM and the sender gets a confirmation of what was captured.
-
A web form with a free-text box
The structured fields are already structured and still get retyped. The paragraph underneath, where the customer explains what they actually want, is read into the same schema as the rest.
-
A marketplace or portal notification
Leads and orders arriving as templated email from a platform with no export and no interface. The message is the only interface there is, so it gets read as one.
The parts that decide whether it survives
Reading one email correctly is a demonstration. These are the things that separate that from a system nobody has to watch.
Running twice has to be safe
Automation platforms deliver at least once, so a network fault can replay a step. Anything writing to a system of record is built to tolerate a retry, or one order lands as two. That is the builder’s problem on every platform in this class.
Model output has to be constrained to a schema
A paragraph of free text cannot be written to a database column. The extraction is forced into a defined structure and validated, and anything failing validation goes to the queue rather than into the system.
Exceptions are most of the build
The clean message is an afternoon. The value is in the missing order number, the thread that arrives out of sequence, and the two messages that turn out to be the same job.
Inbound content is written by somebody else
Everything reaching this automation from outside — the message body, the attached PDF — is content the business does not control. The design keeps retrieved text separated from instructions and puts a person in front of anything irreversible.
The credential store is the sensitive asset
An automation platform holds standing access to the mail system, the CRM and the finance system, usually broader than any single employee’s. Self-hosting it means owning a container, a database, backups, TLS and upgrades, which is a fine choice made knowingly.
Failure is silent by default
An automation that stops working rarely announces it. Run logging, alerting on failed runs and a daily count of records created are part of the build rather than an addition to it.
Where this pays
Order and booking intake
Orders and bookings arriving by email or web form that somebody retypes into a system by hand. The retyping is where both the delay and the transcription errors come from.
Quote and rate requests
Requests that sit in an inbox until somebody has time, in markets where response speed decides who gets the work. The ones that arrive overnight are consistently the ones answered last.
Referrals, applications and intake
Inbound paperwork that has to become a record before anyone can act on it, in practices, clinics and agencies. Somebody currently opens each one and keys it into the system by hand.
Anyone with a shared mailbox
A generic address several people watch, where the rule for who picks up what lives in somebody’s head. Two people action the same message, or neither of them does.
Frequently asked questions
Most CRMs, accounting packages, and job or practice management systems, along with anything in Microsoft 365. Where a system has no usable interface, the route it does support is identified during scoping.
It goes to an exception queue with the original message beside the extracted fields. Guessing is a design choice, and this is built not to.
Somebody owns the exception queue. The change is that the routine messages stop needing to be read, not that nobody looks. The queue shrinks as the ambiguity rules get written from what actually turns up in it.
n8n, Azure Logic Apps or Power Automate. Logic Apps and Power Automate suit a Microsoft-centred estate; n8n suits one with more systems outside it.
Yes, and that is the usual choice when messages carry customer data. Logic Apps Standard supports virtual network integration and private endpoints, and n8n runs as a container in an account you own.
One message type into one system is normally two to four weeks. Most of that is spent on the messages that do not follow the pattern.
Name the inbox
The address where work arrives as prose and somebody retypes it into a system. That is the place to start.