The savings sit in the handling, not the headcount

Most organisations do not lose money on the skilled part of the work. They lose it on everything wrapped around it: rekeying the same information, chasing status, formatting documents, summarising threads, and moving data between systems that were never designed to talk to each other.

That is where automation and AI pay for themselves quickly, because the tasks are repetitive, well-defined and low-risk to get slightly wrong. Start by mapping a week of real work and marking anything a person does more than five times. The list is usually longer and duller than expected, which is exactly what makes it worth automating.

Keep a human at the decision

The projects that fail are the ones that hand over judgement too early. Automate the preparation and the admin, keep the decision with the person accountable for it, and make every step reviewable. Savings that cannot be audited tend to become problems later.

Start with a week of real work

Before choosing any tool, spend a week writing down what people actually do. Not the process diagram from two years ago, the real thing, including the spreadsheet somebody maintains privately because the system cannot do it. Mark anything that happens more than five times a week and anything that involves copying information from one place to another.

That list is where the money is. It is also usually duller than anyone expects, which is exactly why it is worth automating and exactly why nobody has got round to it.

The four patterns that pay back quickly

1. Triage. Classify and summarise what arrives, then route it with the right context attached.

2. Retrieval. Bring policy, product and operational knowledge into one place so answers come with a source.

3. First drafts. Produce a structured starting point for routine communications, with a person signing off.

4. Plumbing. Connect the systems that already run the business so data is captured once.

Automate the preparation and the admin. Keep the decision with the person accountable for it.

Set the boundaries before the build

In a regulated business this is the part that decides whether anything reaches production. Which data can be used, where it is processed, who approves an output, what gets logged, and what happens when the answer is wrong. Agreeing that early is faster than retrofitting it after a pilot has impressed everybody.

Callum led this work at Oxbury Bank, including the unglamorous parts: making the case internally, agreeing controls with risk colleagues and helping teams understand where judgement had to stay with a person. The technology was rarely the hard bit.

Measure the boring numbers

• Minutes per case before and after, taken from the same team rather than an estimate.

• How often an output is corrected, and what the correction usually is.

• How much rekeying disappeared, which is the saving nobody thinks to claim.

Then build the smallest version that a real team can use on real work. Most of the projects we see fail did the opposite: a large programme, a long build, and a demo that never touched an actual queue of cases. Savings that cannot be audited tend to become problems later.