AI automation: what should you do first?

Most companies pick their first automation badly, and they pick it badly in a predictable direction: they choose the thing that annoys the loudest person, or the thing that sounded most impressive in a demo.

Neither is the right criterion. Here is a method that survives contact with a real business.

Score candidates on three axes

Frequency. How many times a week does this happen? Not how important it feels. A quote approval that occurs twice a month cannot pay back a build, however irritating it is. Something happening two hundred times a week is worth automating even if each instance is trivial, and it is usually the boring one nobody complains about.

Pain per instance. Minutes consumed, and by whom. Ten minutes of a senior person's time is not the same as ten minutes of an intern's, and the same task can be worth automating in one company and not another purely because of who currently does it.

Blast radius when it goes wrong. The axis people skip, and the one that should veto candidates. If a mistake costs a customer relationship, triggers a compliance problem, or sends money to the wrong place, that is a bad first project regardless of how well it scores on the other two.

Multiply the first two, then let the third one rule things out. What survives is your shortlist, and it will not look like the list you started with.

Prefer things at the edges of your process

There is a structural reason for this beyond scoring.

Work at the boundary of your operation, where information arrives or leaves, tends to be self-contained: an inbound inquiry, a confirmation going out, a document being filed. You can automate it without rewiring everything downstream.

Work in the middle usually touches three systems and a person's judgment, so the same apparent effort produces a much longer project. Start at the edges, get something running, learn how your organization reacts, then move inward.

The four candidates that are almost always worth looking at

Not a prescription, but these appear in nearly every business we look at.

The thing nobody responds to quickly enough because it arrives outside working hours. Inbound inquiries, most obviously, where the value of a reply decays by the hour. Customer service is the most oversold version of this and still a genuine win in a narrow band.

The thing typed into two systems. Somebody is currently the integration between two pieces of software, and they know it, and they hate it.

The follow-up nobody has time for. Quotes and proposals that go out and are never mentioned again, renewals that lapse silently, customers who went quiet. This is usually the largest recoverable amount in a company and it is invisible because nothing appears to be broken.

The question answered forty times a week with the same sentence. Costs one person their morning and requires no judgment whatsoever.

Deliberately choose something small first

The strongest argument for a modest first project is not risk, it is learning.

Your first automation teaches you things no analysis will: how your team reacts to a machine doing part of their job, whether your data is as clean as you believed, how long your own approval processes take, whether anybody actually looks at the reporting. That knowledge changes the second project substantially, and it is cheaper to buy with a small build than a large one.

Companies that start with the ambitious project usually spend the budget discovering the same lessons, with more people watching.

What not to automate first

Anything requiring a judgment your best people find hard. If a human expert has to think carefully, that is not a candidate, it is a decision support problem, and it is a much later project.

Anything where the process is genuinely broken. Automating a bad process makes it produce bad output faster. Fix the process on paper first, and if it turns out the fix is enough, you have saved the build entirely.

Anything nobody has agreed on. If two departments disagree about how the process should work, a project will not resolve that; it will surface it, expensively, in month three.

Anything where the human contact is the value. Some conversations are the relationship. Removing a person from those is a cost dressed as a saving.

Sequence it in a fixed order

Diagnose the whole picture, then do the smallest high-frequency thing at an edge, then the follow-up nobody works, then move inward toward the processes that span systems.

Resist doing several at once. Parallel first projects mean nobody is accountable for any of them, and when one of them slips it takes the credibility of the others with it.

Where the method usually lands

For most businesses the first project ends up being something inbound and time-sensitive, because frequency is high, the pain is real, the blast radius is small, and it sits cleanly at the boundary. That is why an agent that handles inbound conversations is where so much of our own build work concentrates, and it is not because it is the most sophisticated thing available.

The roadmap we produce is this exercise done properly across your whole operation, with the scores attached and a ninety-day order: how that works. Doing it yourself with the three axes above will still get you most of the way, and if that is what you do with this page, good.