How Much of a Business Process Should You Automate?

Automate as much of a business process as can be completed reliably, with a clear responsibility for the steps and failures that need a person. That may mean one task, a handoff, several connected steps or the complete process. The right boundary depends on how the work is done and what happens when something goes wrong.

We begin by looking at the process a company performs now, or by asking for a description of what it wants to start doing differently. A new process deserves the same consideration as an established one. The useful question is which parts can run reliably and which decisions should remain with someone who can take responsibility for them.

Describe the process you want to run

Before deciding the scope, describe the work from its starting point to its intended result. What starts it? What information does it need? Which actions and decisions follow? What counts as complete?

Include the handoffs between people and systems. A task may look straightforward in isolation, while the next step depends on someone interpreting an incomplete request or deciding whether an unusual situation is acceptable. Those dependencies help determine where automation can begin and where it should stop.

If you are introducing a new way of working, describe the intended process in the same terms. You do not need to create a manual version first. You do need to explain the result, the decisions involved and who is responsible for them.

Choose a boundary that fits the work

One task can be a sensible scope when it has clear inputs and a defined result. A handoff can be the useful boundary when information needs to move from one person or system to another. Several connected steps may belong together when each can be completed reliably and the transitions between them are clear.

A complete process may also be suitable. Assess the whole chain, including the decisions and dependencies that connect its steps. A reliable opening step says little about whether the process can reach its intended result.

We normally reduce the proposed scope when the complete process does not have a sufficient chance of succeeding reliably. If one step needs a person, the surrounding steps may still be useful to automate. The boundary can sit around that decision, allowing the workflow to continue once the person has handled it.

For a concrete, hypothetical example, consider an internal purchasing request. A system could record a complete request and route it to the appropriate manager. The manager could retain the decision to approve it. After approval, another automated step could pass the request to the team responsible for purchasing. A missing required detail or a failed transfer could be flagged to an assigned person. The appropriate scope would depend on whether those steps and handoffs can work reliably.

Give human involvement a defined purpose

Keep a step with a person when it cannot be completed reliably by the proposed automation. Privacy-sensitive work or a decision whose failure would create too much risk may also warrant human handling. These decisions depend on the particular process and the consequences involved.

Define what the person must decide, what information they need and how their answer allows the work to continue. Human involvement needs the same clarity as an automated step: someone must be able to recognize the issue and act on it. The process still depends on that person having the information, authority and availability to respond.

Workflow software can support this arrangement. For example, AWS documents workflows that can wait for human approval. This illustrates one way to combine automated work with a human decision. The suitable mechanism depends on the systems involved.

Include exceptions in the scope

Decide how the workflow should respond when a required input is missing, an action remains incomplete or a step stalls. Identify what needs to stop and what the responsible person needs to see. That person also needs a clear way to resolve the issue and determine how the process continues.

For each exception, name an owner. An alert is useful only when someone understands what requires attention and can take the next action. The automated boundary and the human responsibility should therefore be assessed together.

Write down the proposed scope

A short description can make the decision concrete enough to discuss:

• Process: what starts the work and what counts as complete.
• Automation: which tasks, handoffs or connected steps should run automatically.
• Human decisions: what remains with a person and why.
• Exceptions: what must be flagged and who handles it.
• Continuation: how work proceeds after a decision or a resolved failure.

Bring that description, or show us how the work happens today. We can assess a suitable scope for automation around the process you run or want to introduce.