Fix the Workflow Before You Automate It

An invoice reaches an accounts inbox. Someone saves the attachment, enters the details and forwards it to a manager. The manager asks which project it belongs to. The message returns to the original sender. Days later, another person follows up because the payment is approaching its due date.

An automation could move the attachment between those same people more quickly. It would still be moving an incomplete request.

In this illustrative process, the first useful change may be to require the project reference at submission and establish who confirms it. The next may be to distinguish an invoice that matches an agreed purchase from one that needs a commercial decision. Only then does the business know which work can proceed automatically.

Microsoft’s automation planning guidance begins with understanding the business problem and process. That sequence helps prevent a common procurement mistake: choosing an automation platform before deciding what the process should do.

The objective is to make necessary work more dependable. Sometimes that means automating a step. Sometimes it means removing the step entirely.

Gather a recent normal case and several troublesome ones. Follow each from the event that starts the work to the point where the business considers it complete. Use records, messages and the people involved to reconstruct what happened.

Record waiting as well as activity. Five minutes of data entry may attract attention while an unexplained approval queue adds three days. A process map that contains only tasks can miss the greater source of delay.

At each step, ask what information arrives, what changes, what decision is made and who is responsible for the result. These are also useful elements in Microsoft’s guidance on identifying business flows. Keep the working map understandable enough for the team to challenge it.

Be careful with the phrase “we always”. A rule may describe normal practice while concealing exceptions that matter. Perhaps urgent invoices arrive through a different channel, some suppliers use credit notes and overseas transactions require additional checks. Record these differences before describing the process as standard.

Also note the unofficial repair work. A team member may correct a supplier reference from memory or call someone to confirm a price. Automation needs either a reliable way to obtain that information or a clear point at which a person takes over. The existing workaround is evidence of a missing requirement.

Look at each approval, copy and notification with a specific question: what useful decision or control does this step provide?

A second approval may protect the business against an unauthorised purchase. It may also be a historical habit that duplicates a decision already recorded elsewhere. The answer requires the process owner’s judgement, not a developer’s assumption. Simplification should preserve the controls that matter.

Separate checking from deciding. Confirming that an invoice number is present is a check. Deciding whether to accept an unexpected charge may require context and authority. Treating both as the same kind of “approval” makes the workflow harder to design.

For the invoice example, the revised process might collect required information at entry, match straightforward cases against authorised records and send only mismatches to a named reviewer. That is a different operating design, not merely a faster version of the email chain.

The same logic applies outside finance. An enquiry form might ask for information nobody uses. An internal status update might repeat data already available in the job system. A weekly report might exist because an earlier manager requested it. Verify the current need before investing in its production.

GOV.UK’s discovery guidance emphasises understanding the underlying problem and constraints. In a small business, a focused review with the relevant staff can expose enough of those constraints to improve the process without creating a large transformation programme.

An automation is incomplete if it works only while every input is correct and every connected system responds. Decide what happens when the work cannot continue.

For each important exception, specify an owner, a visible status and a safe next action. “Send an email” is rarely a complete exception design. Which inbox receives it? How is it distinguished from routine messages? Who takes responsibility when the normal owner is away?

Consider these questions before implementation:

• If the same request arrives twice, can the system recognise it without processing it twice?

• If information changes after submission, which version is authoritative?

• If a connected service is unavailable, will the action retry safely or wait for a person?

• If approval is overdue, who can escalate it and what remains blocked?

• If an automated action is wrong, can it be corrected and can its effects be traced?

Some exceptions should stop the work. Others can enter a queue while unrelated work continues. The choice depends on consequence. A missing optional reference is different from an uncertain bank-account change.

A useful automation makes unfinished work visible rather than quietly transferring it to somebody else.

Design that visibility into the operational view. People need to distinguish completed work, work awaiting a decision and work that failed technically. A single green dashboard count can conceal all three.

A predictable rule may be handled by a standard workflow or an integration between existing systems. An uncertain interpretation, such as extracting meaning from an unstructured request, may justify an AI-assisted step. These choices carry different requirements for review and testing.

Use the simplest mechanism that meets the need reliably. Introducing AI to check whether a required field is empty adds uncertainty to a straightforward task. Equally, forcing varied natural-language requests into a rigid set of keywords may create more manual correction than it saves.

Test with representative cases, including exceptions, before allowing the automation to affect important records. Check permissions using the account the automation will actually use. A successful test performed by an administrator may hide access problems that appear during normal operation.

Agree who can change the rules after release. An approval threshold, supplier record or routing condition can alter the behaviour of the whole workflow. Record the change, test the affected cases and tell the people handling exceptions what now differs. This keeps routine maintenance from becoming an unreviewed business decision.

Release a bounded part of the workflow first. For example, automate capture and validation while keeping payment approval with an authorised person. This gives the team a chance to evaluate the quality of inputs and exception handling before expanding the automation’s authority.

When reviewing the result, count the work that remains. Faster processing is useful, but the assessment should also include corrections, follow-up messages, unresolved items and the effort required to maintain the rules. If those costs rise, inspect the design before extending it.

A well-scoped AI and automation project should begin with a process the business understands. The technology can then support a clear operating decision, with people responsible for the parts that still require judgement.