Which processes to automate with AI first

Ask what to automate with AI at a software company and you get the same list every time. Tier-one support tickets. Customer onboarding. Invoice and expense handling. Internal search over your own documents. IT service requests. Recurring reporting.

The list is right. It is also not the problem.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and separately expects 60% of AI projects to be abandoned through 2026 for want of AI-ready data. An MIT study of more than 300 public AI initiatives found a small minority extracting measurable value from integrated pilots.

Those projects were not cancelled because somebody chose the wrong item off the list. They were cancelled because the item they chose failed a test nobody applied first.

Four tests, in the order that matters#

Run every candidate through these before ranking any of them. They cost an afternoon each and they predict survival better than any scoring matrix.

1. Is the input already written down somewhere?#

A model can only work on what reaches it. The question is not whether the data exists, it is whether it exists in one place, in a consistent shape, without a person assembling it first.

Tier-one support passes this easily: the tickets are in your helpdesk, in text, with a resolution attached. Expense handling passes. Recurring reporting usually fails, because the numbers live in four systems that disagree, and reconciling them is the actual job.

This is the test that Gartner's data-readiness finding is about, and it is the cheapest one to run. Open the system. If you cannot see the inputs and the accepted outputs in one query, you have found the first piece of work, and it is not an AI piece.

2. Could you tell tomorrow whether it worked?#

Pick the number now. Tickets resolved without a human. Time from signup to first successful action. Days to close the month.

Then read it. Today, before anything is built.

If nobody can produce that number this week, the project cannot succeed visibly even if it works, which is a large part of why so many pilots quietly end. A process nobody measured is a process nobody can defend when the budget is reviewed.

3. What happens on the day it is wrong?#

Every one of these systems is wrong sometimes. The candidates that survive are the ones where being wrong is cheap.

An internal search that returns the wrong document costs somebody thirty seconds. A support agent that gives a customer a confidently incorrect answer about their billing costs a ticket, a refund, and some trust. An agent that issues the refund itself costs money.

Rank by blast radius, not by enthusiasm. The first thing you automate should be the thing where a mistake is survivable, because you will make several while learning how your own system fails.

4. Is it actually a model problem?#

The uncomfortable one, and the most valuable.

A surprising share of what gets scoped as AI is a rules problem, a search problem, or a form with too many fields. On the DHL programme, which contributed roughly $100M in annual operational value at the scale it ran, the largest single win involved no model at all. Two systems disagreed about the same records, and deduplicating the traffic between them was worth more than anything a model did.

The test: could a competent person write the rule down in an afternoon? If yes, write the rule. It is cheaper, faster, and right every time, and you are not paying per token to approximate something you could have specified.

The same list, re-ranked#

Applying those four tests to the usual candidates, at a typical software company:

Start here. Internal search and retrieval over your own documents. Inputs are written down, being wrong is cheap, and you learn how your own failure modes look on a low-stakes surface. It is also the least exciting item on the list, which is why it is rarely first.

Then tier-one support deflection. Inputs are excellent, the number is easy to read, and the blast radius is real but bounded. The trap is scope: deflecting billing questions is a different system from deflecting technical ones, and teams that attempt both at once ship neither.

Then onboarding. The number is clean and the value is high. The reason it is third rather than first is that most onboarding problems turn out to fail test four. A guided setup, a removed field and a better empty state frequently beat anything a model does, and finding that out is a win rather than a disappointment.

Approach with care. Anything that takes an action rather than producing text. These are the highest-value candidates and they carry the approval flows, reversal paths and audit trails that make the failure path the majority of the build. Do one of the three above first so you have learned something.

Usually not yet. Recurring reporting and anything spanning systems that disagree. Not because it lacks value, but because test one fails and the honest first project is fixing that, which is unglamorous, cheap and the thing that makes everything after it possible.

What to do this week#

Take the candidate at the top of your list. Do not build it.

Run test two, which takes an afternoon: name the number, and read it. If you cannot read it, you have learned something more useful than anything the build would have told you, and there is a way to construct that baseline after the fact without a data programme first.

Then run test four on the same candidate, out loud, with an engineer in the room. Ask whether a person could write the rule down. About a third of the time somebody will say yes and look slightly disappointed, and you will have saved a quarter.

If you would rather have that done properly across every candidate at once, that is what the Identify step is.