How to choose the first business process to automate

1. Describe the work before choosing a tool

Ask the person who does the task to walk through a recent example. Record what starts it, where the information comes from, what decisions they make, and what counts as finished. Include corrections and follow-up work, not just the easiest case.

For each candidate, collect a small sample across normal and busy days. Note how often the task happens, active staff time per case, waiting time and how often someone must correct it. Keep active work separate from waiting: a request that sits overnight has not necessarily taken eight hours of staff effort.

If the process changes every week or nobody agrees who owns it, clarify that first. Automating an unclear rule can make the confusion harder to resolve.

2. Compare candidates with five questions

Use these questions to discuss two or three tasks. A simple yes, no or unknown is enough. This is an editorial checklist, not a validated scoring model; a high count of yes answers does not override a serious risk.

• Does this task repeat often enough to justify setup and maintenance?
• Are the inputs and normal decision rules clear?
• Can the existing tools provide the information and actions needed?
• Can an incorrect result be detected and corrected before it causes harm?
• Is there a named person to handle exceptions and judge the pilot?

3. Keep judgement and exceptions visible

Separate routine steps from decisions that require context. Copying a reference number may follow a fixed rule; deciding whether to make an exception for a customer may need a person. Your first version can prepare a draft or flag a case for review instead of completing every step automatically.

Write down what happens when information is missing, a service cannot be reached, or the same request arrives twice. Decide which cases stop for review, who receives the alert and how staff can finish the work manually. Agree how to avoid performing the same action again after a retry.

Choose a narrow starting point. Work that sends money, changes access or makes sensitive decisions needs additional controls and appropriate review; it is a poor place to assume that a quick trial is harmless.

4. Example: prepare enquiries for staff review

Imagine a small service business that copies website enquiries into a shared work list. This is a fictional planning example, not an Alvaxis customer result. Staff currently check for missing details, assign an owner and write a reply.

A limited first automation could create one work item for each new enquiry, copy only the required fields and flag incomplete entries. Staff would still choose the owner and approve the reply. The first pilot would not send messages to customers automatically.

Test a complete enquiry, one with missing details and the same enquiry delivered twice. Also test an unavailable work-list service. The agreed result might be one visible item per enquiry, a clear review flag for missing information, and an alert with a manual recovery step if creation fails. Document how staff check whether an item already exists before retrying.

5. Compare a process change, existing tools and custom software

First ask whether a clearer form, shared template or simpler handover would remove the problem. Then check capabilities already included in the tools you use. Ask the provider to confirm the required connection, permissions, limits and plan costs; do not assume a feature exists or is free.

Consider custom software when the workflow needs behaviour that the available tools do not support well. Compare the full task, including exceptions, rather than counting features. Include setup, ongoing subscriptions, monitoring, maintenance and staff training in the discussion.

Ask who will own the accounts, how access is removed when someone leaves, what records the automation keeps, and how work continues if it is paused. Use fictional records when discussing an initial proposal. Do not share passwords or real customer information in a public brief.

6. Measure the pilot before expanding it

Use the same definitions before and during the pilot. Track completed cases, active staff time, corrections, unresolved exceptions and the time spent supporting the automation. Compare similar workloads and note changes in volume or case complexity.

For illustration, suppose 100 cases per week take four minutes each before a change and two minutes each during a pilot. That is 200 minutes less direct handling. If monitoring and recovery take 90 minutes that week, the remaining time reduction is 110 minutes, before setup effort and other costs. These numbers are invented to explain the calculation, not an expected return.

Agree the decision rule in advance: continue, revise or stop. If errors increase or support effort outweighs the benefit, keep the manual route and adjust the scope. A count of successful automated runs alone does not show that the business process improved.

Bring this one-page automation brief

Use the prompts below to discuss a first version. Alvaxis offers business automation alongside websites, web apps and mobile apps/connected systems. Share the workflow and open questions to discuss whether existing tools or custom development fit the task.

• Task and owner: what repeats, and who is responsible?
• Current process: trigger, inputs, steps and finished result.
• Baseline: volume, active work time and corrections, or what is still unknown.
• Pilot scope: what runs automatically and what needs staff review.
• Exceptions: missing data, repeated requests, failures and manual recovery.
• Tools and access: systems involved, permissions and confirmed costs.
• Success and stop conditions: what will be measured, when and by whom.

More guides

• What to plan before building a membership mobile app
• Does your business need a website or a web app?
• How to write a software project brief