Where should your business start with AI?

Start with a task your team repeats, can explain and can check. A useful first project has accessible information, a named owner and a clear stopping point. It should be small enough to compare with the way the work happens today.

For a Sydney business, that might mean preparing invoice follow-up drafts, answering a narrow set of internal questions or assembling an operations report. The best choice depends on the work around the output: who checks it, what happens when information is missing and whether anyone can act on the result.

Start with the handover that causes trouble

Ask the person doing the work to walk through a recent example. Follow it from the trigger to the next person's decision. Record where information is copied, checked, corrected or chased.

“Improve finance” is too broad. “Prepare a review queue from an approved invoice export” gives you an input, an output and an owner. It also makes exclusions visible: the pilot does not change balances, decide disputes or send customer messages.

List three candidate tasks this way. Keep the description to one sentence each. If the team cannot agree on what a task finishes with, clarify the process before choosing software.

Check four things before picking a candidate

Use four questions as a practical filter. Mark each answer ready, needs preparation or unsuitable for this pilot. These are discussion prompts, not an industry scoring standard.

1. Does the work repeat? Look for recognisable inputs and recurring decisions. Separate genuinely repetitive work from unusual cases that happen to arrive in the same inbox.
2. Can you use the information? Identify the source, its owner, its format and permission to access it. An export with stable identifiers may be a better starting point than several conflicting spreadsheets.
3. What happens if it is wrong? Trace the consequence beyond the screen. An incorrect internal draft and an incorrect message already sent to a customer require different controls.
4. Can you judge the result? Choose an output someone can compare with a known answer, approved source or agreed business rule. Name that reviewer before building.

A frequent task with inaccessible data is not ready. A tidy dataset does not make a consequential decision safe. Treat missing permissions or an unavailable reviewer as reasons to prepare or choose another task, rather than hiding them inside an average score.

An invoice example with useful boundaries

Our billing example is an Illustrative demo / Synthetic data walkthrough. It uses invented records, a fixed snapshot and deterministic rules. It is not a live AI model, accounting connection or customer project.

The sample records include an unpaid invoice, a paid invoice, a disputed item, a missing contact, a recent follow-up and an invoice not yet due. They should not all produce the same action. The demo separates items that can have a draft reviewed from items that need attention, should wait or should be excluded.

That suggests a focused pilot question: can the team receive a useful review queue without having to recheck every excluded item manually? The answer requires testing the exclusions as well as the drafts. The demo's follow-up interval is an invented business rule, not a recommended collection policy.

In a real implementation, decide how current payment information is checked before any approved message is sent. A draft based on yesterday's export may be inappropriate after today's payment. The first pilot can stop at reviewed drafts while that dependency is worked out.

Measure the work people still have to do

Observe a representative sample of the current process. Record preparation time, review time, corrections, exceptions and unfinished items. Note the types of cases included so that an easier test batch does not look like a process improvement.

Use the same categories in the pilot. Include time spent finding missing information and resolving failed runs. Report accepted outputs separately from outputs needing correction; distinguish a correct exclusion from a case the system failed to handle.

Time released is not automatically cash saved. Explain what the team would do with that capacity, and keep software and maintenance costs visible. Avoid converting a short demonstration into an annual savings claim without an agreed basis.

Make the first decision reversible

Write down the input, output, owner, exclusions and acceptance conditions on one page. Agree when to pause, how to return to the existing process and who can approve a wider scope. A useful pilot may show that cleaning the source data or using a simple rule is the next step.

The Australian Government's business.gov.au AI guidance recommends identifying the business problem, involving staff and starting with a limited trial. Our four-question filter is one way to make that starting conversation concrete; it is not a government assessment or certification.

Try the decision before choosing the tool

Open the invoice follow-up demo and inspect why different sample records receive different treatment. Then identify one handover in your own business where a reviewable draft or queue could help.

Let's talk about that workflow. A general description of the task, its owner and the systems involved is enough for an initial enquiry; leave customer records and confidential files out of the form.