Three processes, before and after
Written as mechanics rather than as a use-case list. No client names, and no figures presented as results, because what matters here is which parts moved.
Invoice processing in finance
Before. The invoice arrives by email. Somebody opens it, keys the header into the finance system, finds the purchase order, checks the amount, and posts it, and if the amount is outside tolerance it goes to a queue for a manager. Once a week, somebody reconciles what was posted against the supplier statement.
Four handovers, two queues, and a reconciliation that exists because the postings and the statements disagree often enough to need checking.
After automation alone. The bot reads the file, matches the purchase order, posts inside tolerance, and routes the rest. The keying is gone, the approval queue is exactly as deep, and the reconciliation still runs, because the sources of disagreement have not changed.
After redesign plus automation. The tolerance rule is widened for suppliers with a clean history, so fewer items go to the queue at all. A second approval step that nobody could justify is removed. The bot validates the supplier reference at the point of arrival, so mismatched invoices bounce back the same day rather than surfacing at month-end. The reconciliation shrinks because there is less to disagree about.
The automation removed the typing and the redesign removed the waiting. Both were needed, and only one of them was a project.
Employee onboarding in HR
Before. An offer is accepted. HR creates the record, emails IT for accounts, emails facilities for a pass, emails payroll, and sends a welcome pack, and each of those is a separate request with its own queue. The starter arrives on a Monday and something is always missing.
Here the touch time is small — a few forms — and the elapsed time is two weeks. This is a wait-time process wearing a data-entry costume, and it is the one most often automated badly.
After automation alone. The bot creates the record and raises all four requests at once instead of in sequence. That genuinely helps, because the requests no longer queue behind each other, which is where employee onboarding automation earns its keep.
After redesign plus automation. Account creation is triggered by the signed offer rather than by an HR email, so it starts a week earlier. The facilities pass is ordered from the same trigger. What used to be five sequential handovers becomes one event with four parallel consequences, and the starter arrives to a desk that works.
Notice that the useful change was a trigger rather than a bot, and the bot only made it reliable.
Order handling in operations
Before. Orders arrive by three routes: a portal, email, and a spreadsheet from one large customer. Somebody normalises them into the order system. Anything unusual goes to a supervisor, then stock is checked, the warehouse is notified, and the customer is confirmed.
The variation in the input is the whole problem. The portal orders are clean, the emailed ones are not, and the spreadsheet changes format whenever the customer's analyst updates it.
After automation alone. A bot handles the portal orders straight through. Email and spreadsheet orders still need a person, because the bot breaks whenever the format shifts, so roughly two-thirds of the volume is automated and the remaining third consumes the same attention as before.
After redesign plus automation. The large customer is moved onto the portal, which took one conversation and had never been asked, and a standard template is agreed for email orders. Now the bot handles most of the volume, the exception queue is small enough for one person, and order-to-cash time drops because nothing waits for normalisation.
The pattern in all three: automation handled the tidy part, and the transformation came from changing what arrived at the front.