Before You Automate a Council Workflow: A Practical Review Method for Finding Rework First.

Before choosing a tool, understand the work

Improvement requests sometimes arrive already framed as a solution: automate an intake step, replace a spreadsheet, or add a new portal. Those may eventually be sensible choices. But if the underlying problem, decision rules or hand-offs are unclear, a new tool can preserve the confusion and make it harder to see.

A useful workflow review starts with the work itself: where a request begins, who acts on it, what information moves with it, where it waits, what decisions are made and how the service user knows what happened.

This guide offers a practical review method for one council workflow. It is not a case study or a claim about any particular council’s systems, performance or results. The examples are illustrative only.

1. Frame a question small enough to answer

Avoid a broad brief such as “improve customer service” or “digitise the process.” Instead, define a review question with a service, a start and end point, the people affected and a decision the review should inform.

For example: Where does a council’s service-request process create avoidable delay or repeat handling between receiving a request and assigning it to the team responsible? The review might cover one request type and its main intake channels, rather than every service request managed by the council.

Set the boundary before mapping. State what is in scope, what is not, the period or sample to examine, the sponsor who can make decisions and how success will be judged. A question such as “reduce time to assignment without increasing misrouted requests or excluding residents who use non-digital channels” is more useful than “make the process faster.”

The Australian Public Service Commission’s problem-framing guidance warns against defining a solution before understanding the problem and recommends clear objectives, boundaries, stakeholder input and a way to determine success. It was written for APS taskforces, not as a council requirement, but its scoping questions are useful for a local service review. [3]

2. Map what people actually do

A procedure describes the intended process. A review needs to understand the process people experience and perform. Speak with the people who receive, assess, transfer, approve and close the work. Where appropriate, include service users or their representative voices. Consider frontline, back-office, policy, digital, records, privacy and service-owner perspectives where they affect the workflow.

Examine a normal case and at least one exception: incomplete information, an urgent request, a transfer to another team, a system outage or a request that is reopened. Ask people to show how they handled the work, not just describe the formal steps. Use records or timestamps only where access is approved and appropriate; do not copy personal information into a map or workshop board unnecessarily.

A simple map can show four connected layers:

- Service-user steps: how someone makes a request, supplies information and receives an update.

- Work steps and decisions: what staff do, who decides, and what causes a referral or return.

- Information and systems: what is recorded, where it is re-entered, and which record is relied on.

- Queues, controls and exceptions: where work waits, how priority is set, and what happens when the usual route fails.

The Australian Public Service Academy’s Service Mapping 101 guide recommends starting with a clear mapping question, identifying stakeholders and information gaps, and choosing a map that suits the intended outcome. It describes journey maps as a way to examine service interactions and reveal pain points. The map is a way to structure inquiry; it does not prove that every case follows the same path. [2]

3. Separate observed friction from assumed causes

Mark what the review has actually seen and what still needs testing. A staff member saying “the system causes the delay” is important evidence about their experience, but the cause may also involve incomplete requests, unclear eligibility rules, queue priorities or an approval step.

Look for patterns such as repeated data entry, missing information, avoidable hand-offs, work returned for correction, unclear ownership, status-chasing, long queues or a decision that depends on one person’s memory. Check whether the issue affects all users or particular channels or groups. A faster online process is not an improvement if people who need another way to access the service are left behind.

Use a small, proportionate sample to understand frequency and variation. For example, record the number of hand-offs, elapsed time between key steps, requests returned for more information and unresolved exceptions. State the sample and period. Do not turn a handful of observations into a claim about the whole council.

The current Australian Government Digital Service Standard says digital government services should be user-friendly, inclusive, adaptable and measurable. It includes criteria to know users, do no harm, monitor a service and keep it relevant. The standard applies to Australian Government services; for councils, treat these as useful design prompts unless a particular requirement applies locally. [1]

4. Choose the smallest useful change before automating

Not every friction point needs software. Possible first changes might include clarifying what information is required, removing a duplicate approval, agreeing a hand-off owner, improving a status message, or making an exception route visible. These changes still need review against local policy, delegations, records, privacy, security and accessibility requirements.

Consider automation only when the rule is sufficiently clear, the input information is reliable, exceptions can be handled, an accountable owner is identified and the expected benefit justifies the cost and risk. If the process has inconsistent interpretations, automation may simply apply those inconsistencies more quickly.

For a proposed change, agree in advance:

- what will change and for whom;

- what must remain safe, accessible and auditable;

- how staff will handle exceptions or reverse an error;

- who can approve, monitor and stop the test; and

- what evidence would justify keeping, changing or stopping it.

5. Test whether the service improved

Choose a small set of measures linked to the review question. Depending on the workflow, that could include time to assignment, the proportion of requests returned for missing information, repeated hand-offs, status enquiries, unresolved exceptions or feedback from the people using and delivering the service.

Record a baseline before the change and use the same definitions afterwards. Look at quality and access as well as speed. A reduction in average processing time may hide a growing backlog, a higher error rate or worse access for people using a non-digital channel. The Digital Service Standard’s emphasis on monitoring, user experience and ongoing relevance supports this discipline, but each council should select measures suited to its service and local obligations. [1]

An illustrative example

Imagine a hypothetical council receiving a common maintenance request through a web form, email and telephone. Staff transfer details into a queue, then re-enter some information when assigning the work. Residents sometimes contact the council for status because the next step is not clear. This is an illustration, not a C51 client example.

A review would first define which request type is in scope and what “assigned” means. It would trace a sample from receipt to assignment, talk with staff who receive and route requests, and check how the service user is told what happens next. It would note where information is repeated, where requests wait, how incomplete or urgent requests are treated, and what record is authoritative.

A candidate test might be a clearer minimum-information rule and a named owner for the first hand-off. The team could compare assignment time, returned requests and status enquiries before and during the test, while checking that urgent and non-digital requests still have a safe path. The review should not claim the change worked until the measures show what happened.

A five-day mini-review

For one bounded workflow, a short review could follow this sequence. The timing is a planning template, not a statutory standard.

Day 1: agree the question, boundary, sponsor, participants and success measures.

Day 2: walk through normal and exception cases; draft the current-state map.

Day 3: validate the map with staff and, where suitable, service users; record friction and a small baseline.

Day 4: compare improvement options, including non-technology changes; check risks and dependencies.

Day 5: agree a small test, owners, measures, review date and stop/change criteria.

Useful outputs are a current-state map, an evidence-based issue log, a short list of options and a test plan with named owners. The map is not the outcome. The outcome is a better-informed decision about what to change and how to tell whether it helped.

A workflow review may conclude that automation is not the right next step. That is still a valuable result if it prevents investment in a tool that would digitise unclear rules, preserve unnecessary work or create new service risks.

[1] Australian Government, Digital Transformation Agency, Digital Service Standard (https://www.digital.gov.au/policy/digital-experience/digital-service-standard).

[2] Australian Public Service Academy, Service Mapping 101, accessible guide PDF (https://www.apsacademy.gov.au/sites/default/files/2024-07/Service%20Mapping%20101%20Guide%20-%20accessible%20version.pdf).

[3] Australian Public Service Commission, Define the problem — APS Taskforce Toolkit (https://www.apsc.gov.au/initiatives-and-programs/aps-mobility-framework/taskforce-toolkit/scope/define-problem).