Is this process ready to automate? Five questions

Most automation projects that disappoint don’t fail because the technology couldn’t do the work. They fail because the process wasn’t ready. Nobody could say exactly how it worked, the exceptions turned out to be half the job, or the agent needed access to systems nobody was comfortable opening up.

The good news is that you can usually tell in advance. A short, honest look at the process before anyone builds anything will sort the strong candidates from the ones that need tidying first, and from the ones that should stay with a person.

The official advice points the same way. Earlier this month, Dynamic Business reported on the Australian Cyber Security Centre’s guidance on adopting agentic AI, written with partner agencies in the United States, Canada, New Zealand and the United Kingdom. The message, as the article summarises it, is to start with clearly defined, low-risk tasks, avoid giving agents broad access, and expand only after checking how the agent behaves. That guidance was written for government, critical infrastructure and larger industry, but the principle scales down neatly to a business of ten people.

This article gives you five questions to put to any process you’re thinking of automating, what a good and a bad answer sound like, and a simple way to score the result.

Before you start: pick one process and write it down

The questions only work on something specific. “Admin” is not a process. “Turning a website enquiry into a CRM record and a reply” is. So is “chasing unpaid invoices at 14 and 30 days” or “booking a site visit after a quote is accepted”.

Pick one, then write down how it actually happens today. Not how it’s meant to happen. Sit with the person who does it, or ask them to talk you through the last five times. Note:

• what starts it (an email, a call, a form, a date)
• each step, in order
• every system they open along the way
• where they make a judgement call
• what “done” looks like

This step alone often turns up surprises. The process that “takes two minutes” turns out to involve three systems and a phone call. That isn’t a reason to give up. It’s the information you need to answer the questions honestly.

Question 1: Does it happen often enough to matter?

Automation has a setup cost: designing the flow, connecting systems, testing, and keeping it running. That cost is worth paying for work that repeats. It’s rarely worth paying for something that happens a few times a year.

Ask:

• How many times does this happen in a typical week or month?
• How long does each one take, start to finish, including the switching between tasks?
• Does the volume spike at certain times, such as end of month, after a marketing campaign or after hours?

You don’t need precise figures. A rough tally from the last month is enough. What you’re looking for is work that is frequent, roughly the same each time, and currently eating into time that someone would rather spend on something else.

Timing matters as much as volume. A process that only happens a few times a week can still be a strong candidate if those few times arrive at 9pm and sit unanswered until morning. Speed of response is a legitimate reason to automate, separate from hours saved.

A good answer: “We get a few of these most days, each one takes ten to fifteen minutes, and a lot of them arrive after hours.”

A warning sign: “It comes up every couple of months, and it’s different every time.”

Question 2: Can you write the rules down?

This is the question that sorts most processes. An AI agent is far better than older automation tools at reading messy inputs: a badly worded email, a scanned form, a caller who explains things out of order. What it still needs is a clear statement of what to do once it understands the request.

Try writing the decision rules on one page. For example:

• If the enquiry is from inside our service area and about a service we offer, create a contact, reply with available times and notify the sales lead.
• If it’s outside our area, reply politely with a referral and log it.
• If it’s a supplier pitch, file it without replying.

If you can do that, the process is a good candidate. If every attempt ends with “well, it depends”, you’ve learned something useful: the process lives in someone’s head. That knowledge needs to come out and be agreed before any system can follow it, and getting it written down is valuable even if you never automate.

Watch for rules that rely on information the agent won’t have. “We give regulars a bit of leeway” is a rule, but only if the agent can tell who the regulars are. Often that means a field in the CRM that doesn’t exist yet.

A good answer: “There are about five scenarios and we can list what we do in each.”

A warning sign: “Only Jo really knows how to handle these.”

Question 3: What happens when it doesn’t fit?

Every process has exceptions. The question isn’t whether they exist but how many there are, whether you can recognise them, and what should happen to them.

Look back at your recent examples and count how many went the standard way and how many needed something unusual. If most went the standard way, an agent can handle the bulk and pass the rest to a person. If the “unusual” ones are a large share, the process probably isn’t stable enough yet.

For each kind of exception, decide:

• How will the agent recognise it? A missing field, a keyword, a value over a limit, a customer flagged in the CRM.
• Where does it go? A named person, a shared queue, a task with a due date.
• What does the customer hear? An honest holding reply is better than silence or a guess.

We go into handover design for phone calls in what happens when an AI receptionist can’t help?, and the same thinking applies to email and web enquiries.

Some actions should never be fully automated, whatever the volume. Refunds, credits, cancellations, anything that commits money or can’t easily be undone usually needs a person to approve it. The Australian Government’s Guidance for AI Adoption: Foundations recommends matching human oversight to how autonomous the system is and what’s at stake, and building in points where a person can pause, override, roll back or shut the system down. Our article on whether an AI agent should ask before it acts covers how to draw that line in practice.

A good answer: “Most go the standard way. The odd ones are usually missing information, and we’d want those sent to the office manager.”

A warning sign: “Honestly, no two are the same.”

Question 4: Can the agent reach the systems it needs, and should it?

An agent that can only read and write text isn’t much use. To do the work, it needs to look things up and take actions in your systems: the CRM, the calendar, the job management tool, the accounting package, the shared inbox.

There are two parts to this question.

Can it reach them?

List every system the process touches and check how each one can be connected. Most modern cloud software offers some way for other systems to read and write data, though what’s available varies by product and sometimes by plan. Older desktop software, spreadsheets on someone’s laptop and paper forms are harder, and sometimes the right first step is moving that information somewhere more accessible. Our article on how AI agents integrate with a CRM explains the common approaches.

A process that depends on information nobody has recorded anywhere, such as a price that changes depending on who you ask, isn’t ready until that information lives in a system.

Should it?

Access is where most of the real risk sits. The cyber security guidance reported by Dynamic Business warns specifically against overly broad access, giving examples like a calendar bot that can see all meeting data or an email assistant that can write to any inbox. The practical rule is least privilege: give the agent access to the specific records and actions this process needs, and nothing more.

Ask:

• Does the agent need to write, or only read?
• Does it need every customer record, or only those created through this channel?
• Can its access be limited to one mailbox, one calendar or one pipeline?
• Will every action it takes be logged somewhere you can review?

We set out a fuller checklist in AI agents acting without permission: what to check now.

Personal information

If the process handles personal information, privacy needs to be part of this question, not an afterthought. At the time of writing (October 2026), the Privacy Act 1988 doesn’t apply to every business. The OAIC explains that a small business with annual turnover of $3 million or less is generally not covered, but there are many exceptions, including health service providers and businesses that trade in personal information.

For businesses that are covered, the OAIC’s guidance on privacy and commercially available AI products says privacy obligations apply to personal information put into an AI system and to output that contains it. It recommends due diligence on whether a product suits its intended use, and advises against entering personal information, particularly sensitive information, into publicly available generative AI tools.

There is also a change coming. The OAIC has confirmed that from 10 December 2026, entities covered by the Australian Privacy Principles must include information in their privacy policy about the kinds of personal information used by computer programs that make, or substantially help make, certain decisions. If the process you’re automating involves the agent making or shaping decisions about people, that’s worth checking before you go live.

This is general information, not legal advice. If your business handles health, financial or other sensitive information, get advice on your own circumstances.

A good answer: “It all happens in our CRM and shared inbox, both of which can be connected, and we can limit the agent to the enquiries pipeline.”

A warning sign: “It needs access to everything, and half of it is in a spreadsheet on the boss’s laptop.”

Question 5: Who owns the outcome?

This is the question most often skipped, and the one that decides whether an automation keeps working six months later.

Someone in the business needs to be responsible for the process once it’s automated. Not for the technology, but for the result. That person:

• checks that the work is being done correctly, especially in the first few weeks
• reviews the exceptions and decides whether the rules need changing
• notices when something upstream changes, such as a new service, a new price list or a staff change, and makes sure the agent is updated
• is the person a customer’s complaint lands with if something goes wrong

The National AI Centre’s foundations guidance makes the same point at a broader level: assign a senior leader as the overall owner of AI governance, and as AI use grows, name an accountable person for each AI system. It also recommends keeping a simple register of the AI systems you use, including AI built into tools you already pay for. For a small business, that register can be one page.

Testing and monitoring belong to the owner too. The same guidance notes that AI systems can change their behaviour over time, so checking once at launch isn’t enough. A short weekly review of a sample of the agent’s work is usually plenty to start with.

A good answer: “Sam runs the front office and will own it. She’ll review the exceptions every Friday.”

A warning sign: “It’ll just run itself.”

Don’t forget the running cost

Alongside the five questions, think about how the tool is priced before you commit. AI products are increasingly charged by use rather than a flat monthly fee. In an IT Brief report published on 13 October, advisory firm Pretian Squared warned Australian small businesses that consumption-based pricing (per credit, token or task) carries the most risk of bill shock, because agents can run up costs whether or not their output is useful. Its suggestions were to track total monthly spend, read the pricing metrics closely and set usage limits before rolling agents out.

That fits naturally with the volume question. If you know roughly how often the process runs, you can ask any provider what that volume would cost under their pricing, and set a limit that would catch a runaway loop before it became expensive.

Scoring the answers

Give each question a simple rating:

Question	Ready	Needs work	Not yet
1. Volume and timing	Frequent or time-sensitive	Occasional but predictable	Rare and irregular
2. Rules	Written on one page	Partly written, some debate	Lives in one person’s head
3. Exceptions	Few, recognisable, routed	Several, some unclear	Most cases are exceptions
4. Systems and access	Connectable, narrowly scoped	One system hard to reach	Scattered, or needs broad access
5. Ownership	Named owner, review planned	Owner unclear	Nobody

There’s no magic total. As a rough guide:

• Mostly “ready”: a good first project. Start with the standard path, route the exceptions to a person, and expand once you’ve watched it work for a few weeks.
• A mix of “ready” and “needs work”: fix the gaps first. Writing the rules down or tidying where information lives is often a few hours’ work, and the process is better for it whether you automate or not.
• Any “not yet” on rules, exceptions or ownership: leave it with a person for now. These are the gaps that cause automations to fail quietly.

Start smaller than you think

When a process scores well, the temptation is to automate all of it at once. Resist that. A sensible first version handles the most common path end to end, passes everything else to a person, and logs every action. Once you’ve reviewed a few weeks of real work and the exceptions have settled, you can widen what the agent handles.

That staged approach is exactly what the cyber security guidance recommends, and it’s how you build the kind of trust that lets an automation take on more over time. It also gives you something concrete to measure against your own baseline: how long the process took before, how quickly customers heard back, and how often a person had to step in.

For a broader view of which kinds of work suit automation in the first place, see what can AI agents actually automate?. If you’ve run the five questions and want to talk through a process that scored well, the 3xRMD Flow page explains how we approach the work between the work.