Ask what AI does for an operations team and the answer that gets pitched is usually too big to be useful: a transformed function, a reimagined way of working, that sort of thing. What actually happens on the ground is smaller and considerably more useful: AI takes on a specific, recognisable set of tasks, and hands the team back the hours those tasks used to cost.
A role is a list of tasks, and the tasks on that list have never had equal standing. Some are why the person was hired: judgement calls, exceptions, the conversation with a customer that needs tact rather than a script. Others are simply the tax paid for systems that don't talk to each other properly: re-keying the same figure into a second system because the first one won't export it cleanly, chasing a colleague for a purchase order number that should have arrived with the invoice, assembling a report by copying cells out of four spreadsheets nobody quite trusts. Nobody designed those tasks into the job description. They accumulated, the way work always accumulates for the people caught between systems that were never built to talk to each other.
That second list is where AI earns its keep. It has a clear input, a clear output, and no judgement required in between, which makes it exactly the kind of work a model can take on reliably, and exactly the kind of work nobody chose to do in the first place.
What a good week looks like afterwards
Take a typical operations function that processes supplier invoices against purchase orders. Before automation, someone spends a chunk of every day matching invoice lines to POs by eye, keying the results into the finance system, and flagging the ones that don't match for a second look, which, if the queue is long, they get to eventually. Once automation lands well, the software clears the matches that are genuinely straightforward and leaves the person the part that was always theirs: the invoice that's forty pounds over the PO because of a currency conversion, the supplier who's clearly using an old price list, the pattern of mismatches that keeps recurring against one particular account.
The queue gets shorter, but what's left in it is denser: a higher proportion of exceptions, a higher proportion of calls that need a person to make. The customer conversations don't go away; there's arguably more time for them, because the team can now phone the supplier and sort out why the price list is wrong, rather than just flagging the invoice and moving on. And someone finally has the time to ask why the same three suppliers cause most of the mismatches, a process question, not a data-entry question, and the kind of question that rarely gets asked when everyone is underwater.
That's a fuller job, not a smaller one. The mix shifts towards the parts that were always the more interesting half of the work.
Visibility for managers, not just less admin for the team
The benefit isn't confined to the people doing the task. A manager who used to find out about a stuck invoice queue or a backlog of unresolved exceptions once a week, via a report someone compiled by hand, can instead see it as it happens: which supplier is causing trouble this month, which exception type is piling up, where the queue is actually building rather than where last Friday's snapshot said it was.
That's a genuinely different way of managing the function. Decisions about where to put attention stop being based on whoever shouted loudest or whichever report happened to get finished, and start being based on what's actually going on. It also means less time spent by managers chasing their own people for status updates, which is its own small tax removed from everyone's week.
The skills that become more valuable
Process knowledge appreciates in this shift rather than depreciating. Knowing that a step exists is easy to write down; knowing why it exists, which exceptions it was added to catch, which ones it was never meant to catch, usually lives in one or two people's heads, and it matters more, not less, once routine steps are handled automatically around it.
The other skill that matters more than it used to is knowing when a system's output is wrong. Automated tools produce a confident-looking answer whether the input was clean or a mess, and they don't hesitate the way a person would over an odd invoice. The person who has spent years matching invoices by eye is precisely the person who notices an output that's technically well-formed and still off: a figure that's plausible but not right, a match that's correct on the fields checked and wrong on one nobody thought to check. That instinct doesn't get automated away. It becomes the thing standing between the system and a mistake nobody would otherwise catch until it was expensive.
The team's pain list is the automation roadmap
The single biggest factor in whether an automation project earns its keep isn't the model or the vendor. It's whether the team doing the work was involved in deciding what got automated first. Ask the people running the process which three tasks they'd remove from their own week if they could, and the answer is usually more accurate, more specific and more immediately useful than anything drawn up from the outside, because they're the only ones who know where the process on paper and the process in practice quietly diverge.
It matters who does the asking, and when. Automation designed around a process map, without the people who actually run it in the room, tends to encode the version of the process that's written down rather than the one that's really used, and the gap between the two only shows up once the system is live and the edge cases start arriving. Bring the team in from the start and that gap gets closed before it costs anything.
A few things follow from that in practice:
- Ask the team directly what they'd automate first, rather than inferring it from a process map drawn up elsewhere
- Start with tasks that have a small, well-defined set of correct answers, not the most complex process in the building
- Route the exceptions the system can't resolve back to the team, not just a summary dashboard for management
- Explain what's changing and why before go-live, so the version people hear is the real one
Where to start
Not with a shortlist of vendors, and not with a slide about the future of the function. Start by sitting with the team and mapping what actually happens in a typical week: which tasks are mechanical, which need judgement, and which everyone quietly wishes someone would sort out. That's a discovery conversation before it's a technology one, and it's how we begin every automation engagement, because the pain list only tells the truth if the people who wrote it were in the room.
