Workflow automation · Translation operations
From an unstructured email request to assigned, reviewed, and auditable work.
I embedded with an operations team, mapped a manual request and billing workflow, defined success with the people doing the work, and shipped an AI supported system with 14 stages system around the email and cloud tools they already used.
The original workflow
A request arrived as client correspondence rather than a clean record. An operator had to identify the work, extract project details, choose and contact a worker, monitor the reply, track the deadline, relay completion, handle QA, and keep the billing trail coherent across the whole exchange.
The system converts each request into a stateful Cosmos DB document, uses Azure Functions to advance it, reads and writes the existing mailbox through Microsoft Graph, and applies language models only where the input is genuinely ambiguous: classification, extraction, and drafting.
Operator interface
These views use the dashboard markup, styling, and interaction model from the private production repository. The records are sanitized and representative; no client, worker, mailbox, or deployment data is shown.
Private source reviewed locally · interface captured from the working project · representative data substituted before capture
Implemented state machine
Turn an incoming request record into an operator alert and a worker selection task.
Contact workers in the priority order chosen by the operator.
Classify accept or decline replies, follow up, expire the offer, and advance the queue.
Prepare the assignment confirmation after a worker accepts.
Send a reminder before the recorded deadline.
Detect the worker’s completion message in the correct thread.
Draft the client update and send it to the operator for review.
Open the client feedback window and persist its deadline.
Identify a QA report and attach it to the right project.
Forward the report and its attachments to the assigned worker.
Require completion language in the past tense before marking revisions done.
Route the final client message through review before forwarding.
Close work after the QA window of ten days expires without a report.
Surface projects that have remained in one state longer than expected.
Actual test material
cases across six operational scenarios
Evidence boundary: these counts come from the project’s actual CSV validation matrix. The available snapshot has blank outcome columns, so this page does not claim a model accuracy percentage. Raw rows are not published because they include real operational correspondence.
What changed after deployment
Logs showed what the system did, but conversations with the team explained why they hesitated to use it.
The system still classifies, routes, drafts, and tracks. The operator owns the final outgoing message.
The system handles routine work, while the operator decides what is sent to the client.
Production engineering
Every trigger that can send email first acquires a write lock in Cosmos DB. Updates based on ETags prevent two concurrent invocations from sending the same message.
Conversation IDs, sender validation, timestamps, and a global set of used messages keep one inbox message from advancing multiple projects.
Recipient overrides redirect messages addressed to clients and workers during local and integration testing.
Completion and QA revision messages are delivered to the operator with an explicit banner that requires review before forwarding.
Source policy
The implementation repository, deployment configuration, and individual validation messages are intentionally private. This case study exposes the system boundary, workflow logic, and verified aggregate evidence without publishing client or worker correspondence.