Configure software, automate a rule, or build an AI workflow?

Use the simplest route that can do each step reliably. First check whether the work needs to change at all, then whether software you already pay for can do it through its own settings. Use a deterministic rule when the inputs are structured and the right answer can be written down in advance. Use AI only for the steps that need interpretation or generation, such as reading free-form documents or drafting text, and keep a rule or a named person responsible for the decision that follows.

Decide step by step

"AI automation vs traditional automation" is usually the wrong frame. Most workflows are a chain of steps, and each step can sit on a different route. A typical intake process might need nothing more than a shared folder for one step, a fixed rule for another, and AI for only one step where someone currently reads a messy document and decides what it says.

Google's machine learning guidance describes ML as "a specialized tool suitable only for particular problems" and advises against a complex ML solution "when a simpler non-ML solution will work" (Google for Developers, Understand the problem). That guidance is written for teams framing machine learning and generative AI problems; the principle still carries over to buying decisions.

The three routes, defined

• Configure what you already have. Use a setting, template, form, approval step or built-in feature inside software your business already licenses. Nothing new is built. Whether a given feature exists depends on your product, plan and configuration, so check the vendor's current documentation for your own account rather than relying on a sales page or this article. Settings, templates, forms and approval rules behave deterministically. Some built-in features instead use a model to read, extract, classify or draft; those are AI steps even though nothing is built.
• Automate a rule. A deterministic instruction: if this field says X, do Y. The same input always produces the same output, and you can write the expected result down before the rule runs.
• Build an AI workflow. A model reads, classifies, extracts or drafts something that a fixed rule cannot handle, usually because the input is free-form or the output is new text. Google's guidance distinguishes predictive ML, where "the output can typically be verified against reality", from generative AI, which "generates output based on the user's intent" (Google for Developers, Understand the problem).

A decision sequence for each step

Map the workflow as a list of steps first: where work arrives, what is read or rekeyed, what is checked, who approves and where the result goes. Then take each step through these questions in order and stop at the first route that works.

Before you reach step 5, set a non-AI benchmark. Google's guidance says to "first verify that your current non-ML solution is optimized" and, if there is none, to try "solving the problem manually using a heuristic" (Google for Developers, Understand the problem). Your benchmark is the best non-AI route you can reasonably run, whether that is the current process once it has been tidied up or a hand-written rule or heuristic. Measure it on the outcome you care about. If AI cannot beat it on that measure, stop.

1. Does this step need to exist? Some steps survive only because nobody removed them. If a step can be dropped or merged, do that before automating anything. Amulet's own diagnostic material lists "a no-go, a process change, an internal build or another delivery partner" as legitimate outcomes of a review (Amulet AI, AI Business BEEP).
2. Can software you already have do it through configuration? Check the tools you already pay for. Amulet's document-to-draft demonstration puts it this way for purchasing: if your system "already supports document capture, draft records and approval rules, test that path before commissioning software" (Amulet AI, document-to-draft demonstration). If a built-in feature reads, extracts, classifies or drafts using a model, treat the step as an AI step: apply step 6 and the AI-step specification below. If you cannot tell whether a feature uses a model, ask the vendor.
3. Can you write the rule down? If the input is structured (a form field, a fixed file layout, a status value) and you can state the correct output for every case you care about, use a deterministic rule. You can test it against a list of known inputs and expected results, and it behaves the same way tomorrow.
4. Is the rule getting out of hand? A rule that needs constant patching for new wording, layouts or exceptions is a warning sign. Google's Rules of Machine Learning is blunt about this: "A simple heuristic can get your product out the door. A complex heuristic is unmaintainable" (Google for Developers, Rules of Machine Learning). That is the point to consider AI for that one step.
5. Does the step need interpretation or generation? Reading free-form emails or documents, classifying text that does not follow a pattern, summarising, or drafting a reply are the steps where AI earns its place. Google's framing guidance answers a narrower question. Once machine learning is in scope, it points to generative AI rather than predictive ML when you need "to generate new content or produce output related to natural language understanding" (Google for Developers, Framing an ML problem). It does not compare AI with rules; steps 3 and 4 do that.
6. Who or what decides after the AI step? Default to a mixed design: AI prepares or drafts, then a rule checks what can be checked (required fields present, totals reconcile, values sit in an allowed list) and a named person approves anything that commits the business. AI output should not be the last step before an external commitment.

Comparison across the three routes

This table is Amulet's recommended way to compare routes, step by step. It is analysis, not a measured benchmark.

What an AI step needs before you build it

If a step passes the sequence above and lands on AI, write down five things before any build, purchase or switch-on. The same applies to a built-in AI feature in software you already have. Amulet's capability page describes a similar step: defining "the trigger, approved inputs, expected output, exception path, human roles, integration assumptions and acceptance criteria for one useful job" (Amulet AI, Capabilities).

For acceptance tests in more detail, see the AI pilot acceptance checklist. For who runs, watches and can stop the workflow after launch, see who owns an AI workflow after launch.

Google's framing guidance notes that for generative output you may need "a test dataset to evaluate a generative model's output against known values", for example checking summaries against human-written ones or having people rate them (Google for Developers, Framing an ML problem). For a business workflow, that means keeping a set of past items with outcomes your team agrees are correct.

Illustrative example: one intake workflow, three routes

This is a hypothetical workflow to show the method. It is not a client, a test or a measured result.

Suppose a trade business receives job requests by email. Some arrive through a web form with fixed fields; others are free-text emails with attachments. Today an office manager reads each one, enters it into the job system, checks whether the site address is in the service area, and replies.

If the job system had a built-in feature that reads emails and attachments into draft records, the third row would still be an AI step. It would need the same rule check, approver, exception queue and test set.

In this hypothetical, AI handles two steps out of six. The office manager remains the named approver, the exception queue is the failure path, and acceptance would rest on a set of past emails with agreed correct job records.

When not to use AI

• A setting or rule already does it. If you can write the correct answer down in advance, a rule is cheaper to test and easier to explain.
• Nobody can check the output. If there is no known right answer and no one with time to review drafts, you will not know when it is wrong.
• The volume is low and the work is stable. Amulet's demonstration notes that "for a small volume, a shared intake folder, a draft template and a named reviewer may be enough". Custom work is worth considering only when remaining handoffs, exceptions or review burden justify it (Amulet AI, document-to-draft demonstration).
• The decision has a legal or similarly significant effect on a person, and you are not taking particular care. The OAIC's guidance says AI use in decisions that "may have a legal or similarly significant effect on an individual’s rights is likely a high privacy risk activity" (OAIC guidance on commercially available AI products). That calls for particular care and specific advice, including on accuracy and whether the product suits the purpose.
• The only reason is that the product has it. Availability alone is a weak reason to route a step through AI. Where personal information is involved, the same OAIC guidance says organisations should consider whether using it with an AI system "is necessary and the best solution in the circumstances", and that "AI products should not be used simply because they are available."
• You would need to paste personal information into a public tool. The OAIC recommends, as best practice, that organisations do not enter personal information, particularly sensitive information, into publicly available generative AI tools.

The OAIC page is guidance from Australia's privacy regulator about commercially available AI products. It is not legal advice, and it does not cover every regime that may apply to your workflow. If personal information is involved, get advice specific to your situation.

Limitations of this guide

• It does not say whether any particular product, plan or feature can do a step. That changes by vendor, plan and release, so check the vendor's current documentation for your own account.
• The Google sources quoted here are general guidance for framing machine learning and generative AI problems. They are not studies of small-business automation, and they say nothing about any specific product.
• AI steps, including built-in AI features, can fail quietly. Google's Rules of Machine Learning warns about "silent failures" in trained-model pipelines, with the example of a model that keeps running while a table it reads is no longer updated, and says this "occurs more for machine learning systems than for other kinds of systems" (Google for Developers, Rules of Machine Learning). This guide applies that by analogy to AI steps in business workflows. Deterministic rules and settings can fail too, but in this guide's view they usually fail more visibly. The OAIC guidance also notes the tendency of generative AI tools to "confidently produce outputs which appear credible, regardless of their accuracy".
• Costs are not covered here; for a like-for-like costing method across manual, configuration, rules and AI options, see AI implementation costs in Australia.

If you are talking to a supplier

Ask any supplier proposing "AI automation" to show which steps actually need AI, what they tested against your existing software, and what happens to an item the model cannot handle. A supplier that recommends configuration or a simple rule for most of your workflow is not underselling; that is usually the honest answer. More questions are in how to choose an AI implementation partner in Australia.

If you have mapped a workflow and one or two steps still look like they need interpretation or drafting, bring that workflow to a problem-fit conversation. Amulet's AI Business BEEP is a paid diagnostic that can end in a no-go or a process change rather than a build. Discuss your first AI workflow.