How to choose a business process worth automating

A useful first automation has a specific job: take an approved request, create the next task, and put it in the right person's queue. You can describe its inputs, check its work and stop it if something goes wrong.

“Automate our admin” leaves rather more room for disappointment.

To choose a business process worth automating, look for repeated work with a stable starting point, clear rules and an output somebody actually needs. Then count the work you expect to remove, including the checking and maintenance you will add. This guide helps you make that choice before buying software or asking someone to build anything.

Put three candidates on one page

Start with tasks people did recently. Ask the people doing the work where they repeat the same steps, copy information between systems or spend time checking whether something happened.

Describe each candidate with a verb and an object: create delivery tasks from approved orders; send appointment reminders; prepare the weekly project report. Give each a finish line. A report is finished when the intended reader can use it, not simply when a file exists.

For each candidate, record:

• What starts it and how often that happens.
• What information must be present.
• The steps that follow the same rule each time.
• What makes a case unusual.
• Who needs the result and who can correct it.

A trigger can be an event, a deliberate button press or a schedule. Microsoft makes that distinction in its Power Automate trigger documentation. It is useful vocabulary even if you never use Power Automate. “When an order is approved” is a much clearer starting condition than “when sales is finished.”

If nobody agrees on the starting condition, settle that first. Otherwise the automation will inherit the disagreement.

Look at the whole trip

Draw the current steps on paper. Include the pauses: waiting for a missing address, asking who approved a change, checking whether a task already exists. ASQ's flowchart guidance recommends defining the boundaries and walking through the map with the people involved.

Keep your first map small enough to discuss in one sitting. You need a truthful sequence, not a diagram worthy of its own project manager.

Beside each step, write one of four decisions:

Remove: nobody uses the result, or another step already produces it.

Simplify: a clearer form, default or shared record would remove the confusion.

Automate: the rule is sufficiently clear and the result can be checked.

Keep a person responsible: the step requires judgment, approval or handling an exception.

One process can contain all four. Preparing a proposed refund and authorizing a refund are different jobs. Scope the first without quietly including the second.

Compare the candidates without inventing a score

A number out of ten can hide the reason a workflow is unsuitable. Make the decision visible instead. This fictional shortlist belongs to the equipment-hire company in the worked example below:

The delivery task earns a pilot because the input and finish line can be defined. Invoice follow-up might save more time eventually, but a wrong message has a different consequence from a draft task needing correction. The unused report may offer the quickest saving of all: stop producing it once its owner confirms it is unnecessary.

This is why frequency alone is a poor selection rule. Consider the cost of a mistake, how easily it can be detected and whether somebody can undo it. A weekly draft report can be an easier first project than a daily customer-facing action.

A worked choice: delivery preparation

The following business and numbers are fictional, created to show the calculation.

An equipment-hire company handles 30 approved delivery requests in a typical week. A coordinator copies each request into a task list, adds the requested date and equipment, and alerts the warehouse. This work, including checking and corrections, averages four minutes per request: 120 minutes a week.

The team proposes creating a draft delivery task when a request is approved. The coordinator still checks it before release. The warehouse decides what can actually be supplied.

For planning, the team assumes one minute of review per request and 20 minutes a week for exceptions and maintenance:

The proposed saving is 70 minutes a week. If setup takes six hours, recovering that setup time would take a little over five weeks if those assumptions hold. Subscription costs, training and changes in workload belong in the decision too.

These are planning assumptions, not a promised result. A short pilot might reveal that the address needs correcting on every third request. That would change the calculation and probably the design.

Find the assumption that could erase the benefit

Review time is often the assumption worth challenging. Using the same fictional 30 requests and six-hour setup:

The arithmetic is current work − review − exceptions − upkeep. Divide setup time by the positive weekly saving to estimate time payback. This still excludes cash costs. Recovered staff time may create useful capacity without reducing payroll; describe the benefit you can actually use.

For a separate budget check, suppose this fictional team values released capacity at £24 an hour and a proposed subscription costs £35 per month. Seventy minutes a week across a four-week planning month is about £112 of capacity, leaving £77 after that subscription. With only thirty minutes saved a week, it is £48 of capacity and £13 after the subscription. Neither figure includes setup or proves a cash saving. A small change in correction effort can change the buying decision.

If volume varies, run the calculation for a quiet week and a busy week. Also ask whether the saved minutes land together. Five minutes released immediately before a dispatch cutoff can matter more than five minutes scattered across a day.

Compare this with “automate all customer enquiries.” Those enquiries might include availability, changes, complaints and requests for advice. The more useful first candidate is the part with a clear boundary and an observable output.

Write the awkward cases before the happy path wins

For the delivery example, the team needs answers to five questions:

1. A required field is missing. Does the request enter a visible review queue, and who checks it?
2. The same approval arrives twice. What identifies the original request so a second task is not created?
3. The request changes. Is the existing task updated, flagged for review or left alone?
4. The destination system is unavailable. Where does the failed attempt appear, and who can retry it?
5. The usual coordinator is away. Who can see pending work and pause the automation?

Write the intended behavior in ordinary language. Someone implementing it can choose the mechanism. Your part is deciding what the business should do.

Treat “we'll notice if it breaks” as an unanswered question. Name the signal: a failed-run alert, a daily unmatched-request list or another check that someone has accepted responsibility for reviewing.

Translate the duplicate and change questions into a concrete example before anyone builds. Request DEL-204 is approved, then the approval event is received again. The desired result is still one draft task linked to DEL-204. Later, its delivery address changes. The coordinator needs to see the changed address and decide whether the warehouse has already acted. Creating another task would conceal the relationship; overwriting a released instruction might conceal a consequential change.

Write those expectations into the brief. You need not choose the technical mechanism to insist on one request reference, visible changes and a way to reconcile approved requests against created tasks.

Run a small, observable pilot

Use representative examples, including the awkward ones. Start with draft outputs or a test destination where possible. For anything that contacts customers, moves money or changes live records, agree on the approval boundary before enabling it.

A saved configuration is only the start. Microsoft's cloud-flow designer documentation separates saving from testing and shows how individual steps expose test results. Apply the same standard to any tool: inspect what reached the destination, not just a success banner.

During the pilot, record preparation time, review time, corrections and missed or duplicated work. Keep time waiting for a person separate from time actively working. An automation may shorten one while barely changing the other.

Choose pass and stop conditions before seeing a polished demo. For this draft-task pilot, a useful proposed acceptance rule is: every approved test request is accounted for, repeat triggers do not create duplicate tasks, missing information remains visible and the backup coordinator can recover a failed attempt. A small pilot cannot establish a permanent error rate, but it can show whether these designed behaviors exist.

Keep the manual route available during the pilot. Record when someone uses it so a successful delivery does not accidentally hide a failed automation. At the review, inspect the troublesome cases first; a log full of ordinary successes will tell you less about the work you are inheriting.

Once the process earns a pilot, use the Zapier, Make and n8n comparison to examine implementation and maintenance tradeoffs. Record the keeper's responsibilities in a short SOP, and include the connection in your software handover register. Someone should be able to maintain the automation after its original builder leaves.

At the end, choose among keeping it, narrowing it, improving the input or stopping. Give the person who will maintain it a say. They are inheriting the ordinary Tuesday version, long after the demo.

Use the workflow triage worksheet to compare your three candidates. Pick the one whose result you can define, whose exceptions you can contain and whose benefit survives an honest count of the remaining work.