How do I start using AI in my business?

Why most first attempts stall

The common first move is to buy a licence for a well-known AI tool, give it to the whole team, and wait. A few people use it enthusiastically, most try it twice, and three months later nobody can say whether it saved anything. Nothing has gone wrong technically. The problem is that no measurable claim was ever made, so there is nothing to confirm or disprove.

The second common move is more ambitious and fails harder: picking the most painful process in the business — usually something involving compliance, money or customer safety — and trying to automate it end to end. These processes are painful precisely because they contain judgement, exceptions and legal consequence. They are the last thing to automate, not the first.

The three tests for a good first task

A task worth starting with passes all three of these. Most candidate tasks fail at least one, and knowing which one it failed tells you what to do instead.

• It repeats. Weekly at minimum, daily is better. A quarterly task gives you one data point a quarter, which is not enough to learn anything before the budget conversation arrives.
• It has a baseline you already know, or can measure in an afternoon — minutes per file, files per day, days to respond, error rate. If you cannot state the current number, you will not be able to state the improvement, and the project will be judged on vibes.
• A wrong answer is recoverable. Drafting a first-pass response that a human edits is recoverable. Sending it unreviewed to a customer is not. Start where the cost of being wrong is an edit.

What usually qualifies

Across most small and medium Australian businesses the same handful of tasks clear all three tests: drafting quotes from a standard scope, summarising long inbound documents before a human reads them, turning meeting notes into structured actions, first-draft responses to repeated enquiries, extracting fields from supplier invoices or forms, and preparing the reporting pack somebody assembles by hand each month.

What these share is that the AI produces a draft and a person remains the one who decides. That is not a limitation to be engineered away later; for a first project it is the entire reason the project is safe enough to run.

Run it manually before you build anything

For two weeks, have the person who already does the task do it with an AI tool open beside them — no integration, no automation, no project. Keep two numbers: the baseline figure, and the same figure during the trial. Also keep a note of every instance where the output was wrong and why.

That list of failures is worth more than the time saving. It tells you what the task actually requires that was never written down — the context the experienced person carries in their head. Automating before you have that list is how projects get built on an incomplete specification and quietly produce confident nonsense.

When to stop doing it manually

Automate when three things are true: the measured figure moved enough to be worth engineering, the failure list has stopped growing with new categories, and you can describe in one sentence what the system should do when it is unsure. That last one is the real gate. A system with no defined behaviour for uncertainty does not fail loudly — it guesses, and nobody notices for months.

This is also the point where the question changes from "which tool" to how several tools, your existing systems and your people fit together as one process. That coordination problem is what orchestration means, and it is a different piece of work from choosing software.

Two things to settle before you start, not after

• What data is allowed in. Decide before the trial which information can be put into a third-party tool and which cannot. Under the Australian Privacy Principles you remain accountable for personal information you hand to a provider, including where it is stored and whether it trains a model. This is a decision for the business, not for whoever opens the tool first.
• Who checks the output. Name a person, not a team. Unreviewed AI output entering a customer-facing or financial process is the single most common way a sensible pilot becomes an incident.