The question I hear most about AI isn't which model is best or what it costs. It's "where do we start?" Push a little further and it becomes something more specific: where can we actually apply this, and how would it help?

The numbers suggest that uncertainty is common. In the National AI Centre’s latest SME AI Pulse, 19% of Australian SMEs said they simply don’t know how to use AI in their business, and 54% of non-adopters said AI isn’t relevant to them. Larger organisations aren’t immune either. MIT’s “GenAI Divide” research, as reported by Computing, found 95% of generative AI pilots stall before scaled adoption, with the lead author pointing to how organisations use the technology rather than the quality of the models. And Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls, according to SD Times.

Unclear business value is the one that matters here. Most stalled AI efforts didn’t fail because the technology couldn’t do the job. They failed because nobody was clear on what the job was.

Describe the hole, not the drill

There’s an old line in sales that nobody wants a drill, they want a hole in the wall. AI conversations tend to start at the drill: a product demo, a licence offer, a competitor’s announcement. The better starting point is the hole. What is slow, error-prone, repetitive or frustrating, and what would fixing it free up?

So I’ll leave specific tools out of this entirely. What follows is a problem-first framework in five steps that works whether you end up with an AI agent, a simple automation, or no technology at all.

Step 1: Find the friction

Problems worth fixing rarely announce themselves in a strategy session. They show up in the day-to-day. A few reliable places to look:

• The same question asked over and over. “What’s my leave balance?” “Which cost centre does this go to?” “Has the vendor been paid?”

• Swivel-chair work. Someone copying data from one system or spreadsheet into another, checking it, then doing it again next week.

• Queues that wait on one person. Approvals, exceptions or reconciliations that stall because only one person knows how to handle them.

• Exceptions handled by email. The process works for 90% of cases, and the other 10% live in someone’s inbox.

• Deadline crunches. Payroll cut-off, month-end close, term enrolment, end of financial year.

These patterns turn up everywhere: a hospital network chasing roster changes before pay runs, a university processing casual academic contracts each semester, a council answering the same rates questions, a mining services firm reconciling timesheets across sites. Ask the people doing the work what they’d happily never do again. They usually know.

Step 2: Size it honestly

Not every annoyance justifies a project. A quick way to size one is to multiply three things: how often it happens, how long it takes each time, and what an error costs. A task that takes ten minutes but happens 400 times a month is a bigger opportunity than a painful quarterly job that takes a day. A task where a mistake means someone is underpaid deserves more weight than one where a mistake means a report is late.

Be honest about the cost of the fix as well. Every solution has a build cost and a running cost, and the second one is the one people forget. I’ve written before about how every integration has two costs, and AI is no different.

Step 3: Name the type of work

Once you have a problem that stacks up, work out what kind of help it needs. Gartner’s Anushree Verma offered a useful split: “start by using AI agents when decisions are needed, automation for routine workflows and assistants for simple retrieval.” Put in everyday terms:

• Finding and explaining information is a librarian’s job. An AI assistant that answers questions from your policies and data fits well here.

• Following the same steps every time is a production line. Traditional automation or an integration is often cheaper and more reliable than AI.

• Making a judgement within clear rules is a delegate’s job. This is where an AI agent earns its keep, as long as the rules are written down and the boundaries are tight.

• Sometimes the honest answer is none of the above. If the process is broken or the data is a mess, fixing that comes first.

This step alone filters out a lot of poor fits. If the work is purely rules-based and never varies, you probably don’t need AI. If it relies on knowledge nobody has documented, AI won’t magic it into existence.

Step 4: Check the inputs

AI is only as good as what it’s given. Before committing, ask three questions. Is the knowledge written down somewhere, or does it live in two people’s heads? Is the data structured and reasonably consistent? Are the rules clear enough that a new starter could follow them?

If the answer to any of those is no, that’s your first piece of work, and it isn’t the client’s job alone or the implementer’s job alone. The client owns the business rules. The implementer owns how those rules were built into the system. Documentation only gets good when both sides treat it as shared. I covered the data side of this in more depth in what “agent-ready” actually means.

Step 5: Define done before you start

Gartner’s advice, as SD Times reports it, is to pursue agentic AI only where it delivers clear value or ROI. That means deciding up front what success looks like: hours saved per month, fewer errors, faster turnaround, fewer tickets. Pick one measure and record today’s baseline.

Then start small. A read-only use case, where AI answers or drafts but a person still acts, is a safe first step. It builds trust, exposes gaps in your documentation, and gives you real numbers before anything touches live data.

A quick worked example

Take a payroll team that fields hundreds of “why is my pay different this fortnight?” queries after every pay run. The friction is obvious and frequent (step 1). Each query takes a few minutes, and a wrong answer erodes trust (step 2). The work is mostly finding and explaining information, so it’s a librarian’s job rather than a delegate’s (step 3). The inputs are partly there: payslip data is structured, but the explanations for common variances live in one senior officer’s head (step 4). Success is fewer queries reaching the team, measured against last quarter (step 5).

Notice what the first real task turned out to be: writing down how common variances are explained. That’s useful whether or not AI is ever switched on.

The takeaway

“Where do we start with AI?” has a less exciting answer than most people hope. You start with a problem: one that happens often, costs something real, and can be described clearly enough that a new starter could solve it. Find that, and the question of which technology to use mostly answers itself.