A request arrives in an inbox. Someone copies the details into a spreadsheet, checks another system, then asks a colleague to approve it. The task sounds simple. The work between the steps rarely is. Before choosing an automation tool, make that work visible.
Start with one bounded workflow
Pick a process with a recognisable beginning and end: triaging an enquiry, preparing a recurring report, or checking that a request is complete. Avoid starting with an ambition such as ‘automate operations’. It is too broad to test or assign to an owner.
For an Australian small business, the first useful project may already sit inside the tools the team uses every day. Start with the people doing the task and the systems they actually have access to.
- Name the trigger: what starts the work?
- Describe the finished result: what makes a task complete?
- Choose an owner who can approve changes to the process.
Watch a normal case and an awkward one
Ask someone to walk through a recent example. Record the source of each input, the decisions they make, the systems they touch and the handoffs they wait for. Then repeat the exercise with an incomplete or unusual request.
Those exceptions often reveal the real requirements: a missing reference number, conflicting records, a decision that needs experience, or an approval that cannot be skipped. A workflow map should include the path back to a person, not just the happy path.
Separate rules from interpretation
A known rule, such as routing a request by a validated account code, may suit ordinary automation. Reading an unstructured message and proposing a category may benefit from an AI model. Treat that proposal as an input to a controlled workflow, with checks appropriate to the consequences of being wrong.
Write down which actions can happen automatically and which require review. Keep customer permissions and approval authority in the application or connected system. A fluent answer is not evidence that an action is authorised.
Measure the work, then trial a small change
Establish a baseline before building: time spent handling a request, time waiting between steps, rework and exceptions. Count the human review effort as well as the work the automation performs.
Trial a narrow slice with representative examples and a way to return to the existing process. Review the failed and ambiguous cases with the process owner. Expand only when the result is useful enough to operate and the team knows what to do when it stops working.
- Agree what success means before selecting a tool.
- Test routine, incomplete and conflicting inputs.
- Document who handles exceptions and how to pause the workflow.
- Review operating effort alongside any time saved.
A USEFUL NEXT STEP
A useful first deliverable is a one-page workflow map: trigger, inputs, decisions, permissions, exceptions, owner and measure. It gives the implementation a job that can be tested.