You decide what the tools are for, job by job, and write it down once. Consistency is a specification problem first.
Most of the businesses I talk to have tried AI for individual use cases, but it’s not really orchestrated. One person got good at it on their own time. Everyone else is either not using it or using it differently, and nobody chose either outcome.
The usual fixes are training, a policy or one standard tool. All three help a little. None of them is the thing that works.
Why does AI work for one person and not the rest?
What they know is tacit. Nobody has asked them to write it down.
The person who’s good at it built a method by trial and error: which tool for which job, what to feed it, what it reliably gets wrong, when not to bother. None of that is written anywhere. Ask them to explain it and they’ll probably say “I just use ChatGPT”, because the useful part is invisible even to them.
Everyone else starts from scratch with a tool that will confidently produce something plausible whatever you give it. A keyword search that misses gives you a page of results you can see are wrong. A model that misses gives you something that reads well, and you can’t always tell.
So the work drifts apart. A car dealership I worked with used AI for its social posts and for staff training. No two people used it the same way, so its marketing never sounded like it came from one dealership. Two quotes written in the same week can have the same problem. It’s the first cost people notice.
The second cost is quieter. If nobody knows how the good version gets made, nobody can improve it, and it walks out the door when that person does.
Is the answer more training?
Partly. Training helps, and I’ve written separately about what AI training should cover. But the standard curriculum teaches people about the technology, and when it does get practical it tends to reach for prompt technique, the least durable part of all this. Models change, and the wording that worked in March needs rewriting.
Two people given identical training still produce different work if nobody told them what the job is. Train ten people on prompt technique and you get ten more skilled people making ten different decisions.
The part worth teaching is narrower and duller: what this tool is for in this business, what goes into it and what gets checked before it leaves. That survives a model upgrade.
Do you have too many tools?
Probably. The bigger question is whether each one has a job.
The usual picture is a set nobody chose. Each tool arrived with a different person, two of them overlap and one was a trial that quietly renewed.
Some businesses need a writing tool, a meeting tool and something inside their own system, and that’s fine. Give each one a stated job and someone who owns it. A tool with no assigned job produces inconsistency by default, because everyone gives it a different one.
There’s a quick test. Ask three people which tool they’d use to draft a client proposal. Three answers means the tools have no jobs, not that you have too many.
What should everyone agree on?
Less than you’d think. For most firms I work with, it’s a handful of lines, written down:
What client information can go into which tool. This matters most and is the one most often left unsaid, and the answer depends heavily on which plan people are signed into. Some of your legal obligations sit here, and others sit in what the tool then does with the output, which I’ve covered in whether Australian businesses still need AI governance.
Which tool is for which job. Named, so the question stops being asked.
What gets checked before it goes out. Not everything needs checking. Decide which things do.
Who to tell when it gets something wrong. Without this you never find out, because whoever caught it fixed it quietly and moved on.
That’s the whole document for most firms of 5 to 100 people. If yours runs longer, it was written for a different company.
When does AI stop being an experiment?
When something specific is expected to work the same way twice and somebody owns it.
What moves it across is unglamorous. The job is named. The inputs are consistent. Someone is accountable for the output. It sits inside the workflow people already use, so using it is easier than not. That last one does more than any policy: if the agreed way is slower than the workaround, people take the workaround, and they’re right to.
There’s a standard for managing AI across an organisation, ISO/IEC 42001, adopted here as AS ISO/IEC 42001:2023. It’s written for organisations of any size, though certifying to it is rarely proportionate for a firm of under 100 people. Know it exists anyway. You’re most likely to meet it in a larger client’s supplier questionnaire.
How do you know if any of it is working?
Measure four things a small business can see. Some of what you’d like to know is out of reach.
Whether it’s being used. Licence counts won’t tell you. Check whether the job it was bought for is now done that way.
How long the job takes now. You need a rough before figure, which means writing one down before you start. Almost nobody does, and it’s the cheapest thing on this list.
How often it’s wrong. You’ll only have this if you set up the “who to tell” line above. It’s the most useful number you’ll have and the one most businesses never collect.
Whether people trust it. Ask them. The answer tells you what they believe, and belief and quality can come apart in either direction. A team quietly working around a tool has told you something too.
Attributing revenue to AI is harder. In a business with a handful of deals a month, there’s no clean way to separate the tool from the market, the season or the person. I’d take four things measured properly over a dashboard that implies a precision you don’t have.
What does this look like in a business of ten people?
One conversation, one page and one person who owns it.
At that size there’s usually no governance function, and you don’t need one unless your work is caught by the obligations in the governance piece linked above. The whole thing is: agree what goes in, which tool does what and what gets checked, write it on one page and revisit it when something changes.
The bigger the business, the more work this becomes: several teams, systems that talk to each other, people who never meet. The principle holds. The effort grows faster than the page does.
Where do you start?
With the person who’s already good at it.
Sit with them for half an hour and get the method out of their head: which tool, what they feed it, what they check, where it fails. Write it down as they talk. That half hour is usually worth more than a training day, because it’s specific to your work and it’s already survived contact with your clients.
Then pick one job: quotes, client updates or meeting notes. Just one. Make it consistent, with a named owner and a check step, and see what it takes. What you learn on the first job tells you whether the second is worth doing.
One job made repeatable teaches you more than a plan for ten. You can see what that looks like as an engagement in AI training, or start from our free AI use policy. If you’d like help choosing the job, tell us about it on a discovery call and we’ll come back to you with a first step.
FAQ
How do I stop everyone in my team using AI differently?
Give each tool a stated job and write down what goes into it and what gets checked. Most inconsistency comes from people filling gaps in the specification themselves. A single page covering which tool for which job, what client information is allowed and what gets reviewed will do more than a training session.
Should we standardise on one AI tool?
Not necessarily. Two tools with clear jobs cause less inconsistency than one tool everybody uses differently. Consolidate when you find two tools doing the same job.
Is prompt engineering worth training my team on?
Some. It’s the least durable part: models change, and the wording that worked last quarter stops mattering. Your time is better spent on what the tool is for, what information goes into it and what gets checked before the work leaves the business.
How do we measure whether AI is working?
Track whether the job is now done that way, how long it takes against a before figure, how often the output is wrong and whether the team trusts it. Write the before figure down first. It’s the cheapest measurement you’ll ever take, and it’s gone once you start.
Our AI pilot worked but never spread. Why?
A pilot usually gets easier conditions than daily work: the keenest person runs it, on work that suits the tool, and those conditions don’t repeat. To spread, it needs a named job, consistent inputs, an accountable owner and a place inside the workflow people already use. If the agreed way is slower than the workaround, people use the workaround.
Do we need an AI policy for this?
For most small firms, one page covering what information goes into which tool, which tool does what, what gets checked and who to tell when it’s wrong. That’s enough for consistency. Whether you have separate legal obligations is another question. It depends on whether you’re covered by the Privacy Act and what your AI touches.
How do I capture what our best AI user knows?
Sit with them for half an hour and write it down as they talk: which tool for which job, what they feed it, what they check and where it fails. Most of it is tacit and they won’t volunteer it, so ask them to walk you through one recent piece of work. It also stops the knowledge leaving when they do.
General information only, not legal advice. Current as at October 2026.
