Inbox to Structured Record
Inbox to Structured Record
Work that arrives as prose in an inbox, read and written into the system of record as a row.
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 you get
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.
How it works
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 matters
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.
Who it is for
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.
Questions
Frequently asked questions
Which systems can it write to?
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.
What happens when a message is unclear?
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.
Does somebody still read the inbox?
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.
Which platform is it built on?
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.
Can it run in our own tenant?
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.
How long does one take?
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.
Also on this site
Name the inbox
The address where work arrives as prose and somebody retypes it into a system. That is the place to start.
(844) 422-7000