The workflow that lived in three inboxes

A request arrives by email with an attachment. Someone copies the details into a spreadsheet, checks another system, asks for a missing field, and forwards the request for approval. A reminder goes out two days later. If the usual owner is away, the team searches through inboxes to work out what happened.

Nothing about the process looks large enough to justify a new platform. It still consumes time every day, and the cost grows as the company adds customers, suppliers, or staff.

The tempting fix is to connect the inbox to the spreadsheet and call it automated. That only speeds up the easy part. The real work is in missing information, unclear ownership, exceptions, and decisions that still need a person.

We start by following a few real requests from arrival to completion. What makes an input complete? Which fields are copied? Which checks are repeated? Where does the work wait, and what causes someone to send it back?

The unusual cases matter. A document may be unreadable, a customer may use an old template, an amount may need extra approval, or two systems may disagree. These are not reasons to avoid automation. They are the rules the workflow needs to expose.

Together, we choose one boundary that is worth fixing. The first version should remove a meaningful amount of coordination without taking a consequential decision away from its owner.

Incoming email, forms, documents, and system events can feed one intake route. The workflow creates a structured record, checks the required information, and routes the request based on rules the team can read.

AI can help extract or classify messy material when the input cannot be reduced to fixed fields. It should not quietly make a decision the business expects a person to own. Low-confidence results, missing information, and policy exceptions go to a review queue with the relevant context attached.

Approvals stay explicit. Reminders, retries, and escalations happen automatically, but the record shows who approved what and when. If an integration fails, the request stops in a known state and alerts the person who can act on it.

A workflow is only useful if the team can operate it. We add a simple view of work in progress, failed steps, waiting approvals, and completion time. Credentials and service permissions are documented and kept narrower than the people using the systems.

The runbook covers the common interventions. It explains how to replay a failed step, correct bad input, update a rule, and find the history of one request. The process owner knows which changes they can make and which ones need technical review.

This is what separates an owned workflow from a chain of automations that works until the person who built it leaves.