Before Automating a Business Process, Examine the Process

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A service team proposes automatic approval emails because requests take too long. The current queue tells another story: many requests arrive without the evidence an approver needs. An automated message would move incomplete cases to the same overloaded person faster.

Illustrative scenario. The process may still benefit from automation. The question is which part of the delay is repetitive work that a system can safely remove, and which part is an unresolved decision about evidence, authority or exceptions.

Measure where the work actually waits

Take a sample of recent requests from receipt to final decision. For each, record when it entered a queue, when someone first acted, how often it returned for missing information, and why it was held. Separate processing time from waiting time. A team can spend minutes sending emails while requests wait days for complete evidence. Automating the minutes would have little effect on the customer’s total wait.

Map the journey from the requester’s side too. What did the form ask for? Could the person reasonably supply it at that moment? Was the status visible? Did a rejection explain what to correct? The process crosses screens, messages, staff decisions and records. A flowchart of the email step alone will miss the service.

Classify the work before assigning it to software

Divide cases into routine, incomplete, disputed and exceptional. For each class, identify the evidence, decision rule, owner and route back to the requester. If staff disagree about what counts as complete, capture that disagreement as a policy question. An automation rule cannot responsibly settle it just because a field can be made mandatory.

Suppose the team removes an unnecessary approval and clarifies the evidence list. That may shorten the journey without new technology. If routine cases still consume staff time, automate a clearly defined step and leave a human route for exceptions. If the decision depends on judgment or potential harm, specify who may intervene and how the decision is recorded.

Pilot the rule with real edge cases

Before a broad rollout, test the proposed workflow on representative historical cases and a bounded group of new ones. Include a missing attachment, conflicting data, a duplicate request, an absent approver and a corrected submission. Check whether the system gives the requester a truthful status and an accessible route to help. Record false routing and manual recovery effort, not just how quickly messages were sent.

The stop condition matters. If requests enter a state with no owner, or the automation communicates an approval that has not occurred, pause and repair the rule. A fast wrong decision can be harder to correct than a slow manual one.

Decide what success means

Use a small set of measures tied to the original problem: total time to a usable decision, share of requests complete on arrival, number of returns for missing evidence, exception backlog and customer understanding of status. Compare these with the baseline and note volume or seasonality changes. A fall in staff clicks alone is not proof that the service improved.

There may be a case for automation even if it does not shorten the main queue: better traceability or fewer manual transcription errors can be valuable. State that objective honestly, cost the ongoing maintenance and assign someone to review the rule when policy changes.

A practical sequence

• Observe recent cases and locate waiting, rework and exceptions.
• Settle evidence and decision ownership with the people accountable for the process.
• Remove unnecessary steps and test a clearer intake without code where possible.
• Automate only a defined repeatable part, with exception and recovery paths.
• Review customer outcome and operating burden after the pilot.

Research grounding: the UK Government Service Manual on mapping a whole service recommends examining online and offline touchpoints, backend processes and evidence users must provide. Its digital functional standard also describes documenting people, tasks, data flows and decision points. These public-sector references support the method; the approval queue is fictional.