Not the ones in the headlines. The real order is set by volume and reversibility, and it is remarkably consistent across every industry we walk into.
Forget the think-pieces. Here is the order automation actually arrives in, derived from counting the work rather than speculating about it. It is set by two variables and nothing else: how many times a day does this happen, and how bad is it if it goes wrong.
Invoices, certificates, applications, claims, packing slips, loss runs. Someone opens a PDF on one half of the screen and types into the other half. It is high volume, low variance, instantly checkable, and almost always reversible.
This is first everywhere, and it is also the best possible first project for a company that has never done this before, because everyone can see immediately whether it worked. Nobody's judgement is being replaced; a very expensive optical character reader is.
Tracking numbers, order status, appointment times, account balances, document retrieval. Roughly a fifth to a third of all inbound support volume in every organisation we have counted.
Read-only, so it can go live almost immediately with no approval gate at all. The trap is doing only this and calling it an AI programme — it is the easy third, and the value is in the other two.
Not replacing your receptionist. Covering the 6pm-to-7am window, the storm surge, and the twenty seconds of ringing before somebody hangs up and calls a competitor. In most service businesses this is the largest single revenue leak in the company and the only one with no instrumentation.
It moves early not because it is easy — voice is the hardest of these technically — but because the money is so obvious that it survives any budget conversation.
Refunds under a threshold. Address corrections before picking. Quantity changes on open orders. RMAs. Rescheduling.
This is where it gets interesting, because it is the first time the AI does something rather than saying something — and it is where every AI programme either becomes valuable or quietly dies. It is also where the approval queue earns its keep: these actions go behind a human gate on day one and graduate to automatic once they have proven themselves over a few hundred decisions.
In engineering organisations, the loop around the code moves before the code does. A review agent tuned on the team's own past incidents, and characterisation tests generated against a legacy module nobody dares touch. Both are cheap, both are reviewable, neither can merge anything by itself.
Note what is not on this list: writing new features unsupervised. Generation is the cheapest part of software and almost never the constraint.
Not because a model cannot produce a plausible answer — it can, and often a reasonable one. Because discretion is the exercise of authority, and authority requires someone who can be held accountable for it. A system cannot be accountable. When a person waives a fee they are spending the company's money against their judgement and their name, and that trade is the entire point.
In every deployment we run there is a permanent list of action types that never leave human hands, regardless of how accurate the system becomes. That list is written into the contract before we start. It is not a limitation of the technology. It is the design.
Take your list of tasks. Score each on volume per week and on whether a mistake is reversible in one click. Sort by volume descending, filter to reversible, and you have the roadmap. Anything involving discretion goes to a separate list marked "never", and you show that list to your staff on day one.
That last part matters more than the ordering. The fastest way to lose a support team's cooperation is to leave them guessing where the line is.
Support automation, AI phone agents, n8n back-office work, and the engineering loop itself — always behind a gate you control.