Automation starts with the exceptions

A document arrives by email. Someone downloads it, copies its data into a spreadsheet, asks for approval, and enters it again in another system. The automation opportunity seems obvious. Yet connecting those steps does not reveal the entire process.

The difficult part often appears when the file is incomplete, arrives twice, or needs a different approval. Designing for those situations from the start tells the team when to intervene and what information they need.

Begin with a concrete journey

Consider the intake of supplier documents as an illustrative example. It does not describe a client implementation or replace an accounting review; it helps organize the design questions.

The journey might have five states: received, awaiting information, under review, approved, and recorded. Each state needs a person or rule responsible for the next step. Approving a document and executing a payment must remain separate decisions.

Define the input before connecting systems

Agree on where the request arrives and what data it needs to proceed. Decide how it is identified, where the original file remains, and which information can be changed later.

If a tool interprets a document, keep a way to compare extracted data with the original. A plausible date or amount can still be wrong. The criteria for requesting review belong in the workflow.

Give every exception a destination

Before implementation, walk through these situations with the people doing the work:

• Information is missing: the request stays pending and identifies what is needed.
• The document already exists: the previous record appears before another is created.
• Approval does not arrive: the team agrees who to notify and when to escalate the delay.
• The destination system is unavailable: the state is preserved and retries do not duplicate the operation.
• Someone corrects a value: the change and the owner of the next review remain visible.

Resolving these cases does not require full automation. A clear review queue can be better than a decision that is difficult to reverse.

Separate automation from authorization

Sending a reminder, preparing a record, and authorizing an operation have different consequences. Permissions should reflect those differences. A workflow can assemble information and suggest the next step while a person keeps the approval decision.

Ask what each component needs to do to fulfill its role. Giving everything full access for convenience makes the process and its failures harder to review.

Test real work situations

Before expanding the scope, test a small set of requests: one complete, one duplicated, one incomplete, and one that must be rejected. Include an interruption in the destination system and a manual correction.

Check whether the team can understand the state of each request without rebuilding its history from email. That visibility is part of the result, alongside any repeated work that has been reduced.

To begin, choose one workflow, identify its owner, and gather anonymized examples of common situations and exceptions. That material is enough to discuss a useful first release.