01 The brief: what was hard
Claim emails land in a shared inbox. Somebody opens each one, hunts for the claim number, finds the claim, and drags every attachment onto it by hand. The number hides in the subject line, or in the body, or nowhere at all.
The cost is not only time. A document filed on the wrong claim is a quiet mess that somebody finds later. And there was no in-house engineering team, so the fix could not be a codebase that needs a babysitter.
If you run marketing ops, you know this inbox. Swap claims for briefs, asset requests and approvals. The paperwork arrives, somebody sorts it, and the real work waits.
02 The process
I started with questions, not a build. What does a claim number look like? Which mail system does the team use? Is there a test copy of the claims system to work against? Each answer cut the scope down to a short sprint: the core path first, then the edges, like replies, a review folder and error handling.
I picked tools that live inside the insurer's own cloud: Power Automate for the workflow and Azure OpenAI for the reading. That meant no new vendor, no claim data sent out to one, and a low-code flow the insurer's own staff can change.
Cheap rules go first and AI goes second. A simple pattern looks for the claim number in the subject line. Azure OpenAI reads the body only when the pattern comes up empty. The flow confirms the claim exists before it files anything, and anything it cannot place goes to a person. I would use the same order on a marketing request inbox.
AI agents drafted the flow, a Python version of the pipeline, and a stack of invented test claims, some clean and some tampered. I set the scope, made the calls, and verified the build against those claims. AI fraud scoring stayed on the roadmap. A proof of concept earns trust by doing the boring part well first.
03 Inbound paperwork, sorted before anyone opens it
- inboxA claim email lands in the shared inbox, and Power Automate picks it up.
- readA simple pattern looks for the claim number, and if it comes up empty, Azure OpenAI reads the email and returns the number with a confidence score.
- checkThe flow confirms the claim exists in the claims system before it touches a file, and the Python build also runs plain rule checks, like a document dated before the loss.
- routeMatched mail goes onto the right claim with every attachment, the sender gets a confirmation, and each step lands in an audit log.
- review folderAnything unmatched or flagged waits in a review folder, and an adjuster gets a message to decide.
04 The result
- 5 stationsinbox, read, check, route and review, in that order every timesource: the proof-of-concept flow (confidential)
- 0 new vendorsthe workflow runs on tools already inside the insurer's own cloud, so no claim data goes to a new partysource: proof-of-concept scope (confidential)
I designed the workflow, directed the AI that built it, and verified it, with no in-house engineering team involved.