How to automate business processes with AI

What AI automation actually changes

Traditional automation handles work that can be written as rules: if the invoice total is under £500 and the supplier is approved, post it. That has been possible for decades, and where a process genuinely is rules-based it remains the cheaper and more reliable answer.

What changed is that AI models can handle the steps that resisted rules — reading a document that arrives in a different format each time, classifying an email by what it is actually asking for, drafting a reply, summarising a call, extracting figures from a scanned form. AI automation is the practice of putting those capabilities into a process so that a person no longer has to do that reading, deciding or writing.

The distinction that matters commercially: you are not buying intelligence, you are removing a queue. The question is never "where could we use AI" but "which queue of work is costing us most, and can a model do the part that makes it slow".

Choosing the first process

Four attributes predict success more reliably than anything about the technology. Score a candidate process against them before committing to anything.

• Volume. It happens many times a week. A monthly task, however annoying, will not repay a build.
• Rules- or language-based. The work is reading, classifying, extracting, drafting or routing — not physical, and not requiring judgement nobody can articulate.
• A tolerable failure mode. If a mistake is embarrassing rather than catastrophic, or if a person reviews the output anyway, you can deploy far sooner.
• Available inputs. The information needed exists in a system you can reach. If the answer lives in someone's head or an inbox nobody can query, fix that first.

Strong candidates we see repeatedly: support triage and first-draft replies, invoice and document processing, lead qualification and follow-up, data entry between two systems, onboarding paperwork, and summarising long threads or calls into a record.

Weak candidates, usually: anything low-volume, anything where being wrong is unrecoverable and unreviewable, and anything whose input data you do not trust. That last one is worth dwelling on — automating a process on top of poor data multiplies the error rate rather than the throughput.

The four levels of autonomy

Autonomy is a dial. Most failed deployments we see turned it up too far on day one, and most disappointing ones never turned it up at all.

• Suggest. Surfaces an answer or a recommendation, and a person does the work. Best for early deployments, high-stakes decisions and building trust.
• Draft. Produces the reply, document or record, and a person edits and sends it. Best for anything customer-facing, where tone and accuracy matter.
• Act with approval. Completes the task but holds it for a yes or no before it takes effect. Best for financial, contractual or otherwise irreversible steps.
• Act. Completes and commits the task unattended, with an audit trail. Best for high-volume, low-risk, well-understood steps.

The sensible pattern is to start one notch lower than feels necessary and move up on evidence. Run at draft for a few weeks, measure how often a human materially changed the output, and promote it when that number is genuinely low. That gives you a defensible reason to grant autonomy rather than a hopeful one, and it produces the accuracy data you will want if anyone ever asks how the decision was made.

Working out the payback

Do not accept a vendor's benchmark as your business case, including ours. The arithmetic is simple enough to do with your own numbers, and only your numbers mean anything.

For the current cost of the process, multiply the hours spent per week by a loaded hourly cost — salary plus employer's National Insurance, pension, software and management overhead, not the headline salary — and annualise it. Then add the costs that are not labour: errors and rework, the deals lost to slow response, the overtime at peak, the cost of the queue itself.

Against that, put the full cost of automating: the build, the integration work, the model usage per transaction, hosting, and the review time that remains, because at draft or act with approval a person is still involved and that time is real.

Two adjustments people miss. First, most automations do not remove 100% of a process; they remove the straightforward majority and escalate the rest, so model the realistic proportion rather than the total. Second, if the time saved is not actually reallocated to something valuable, the saving is theoretical — decide in advance what those hours are for.

Integration is the real work

The value of AI is rarely the model; it is the integration. An automation that cannot see your live data can only guess, and one that cannot write back to your systems just moves the typing to someone else.

In practice that means connecting to your CRM, ERP, databases, email and third-party APIs — increasingly through MCP connectors — so the automation acts on current information and fits the workflow you already run. This is why so many AI projects turn out to be system integration projects: the model was the easy part.

It is also where the difference between a demo and a deployment lives. The internet is full of automations that look brilliant for five minutes and then quietly break, because nobody handled the case where a system was unavailable, a field was empty, or a format changed. Building for day 300 rather than day one is unglamorous and it is most of the engineering.

Governance: giving an automation real responsibility

You can only delegate work to something you can hold to account. On our projects that means treating an automation like a member of staff, with five things in place:

• Scoped permissions, so it can only do what it is explicitly allowed to do.
• A guardrail model checking outputs before they go anywhere.
• Draft-then-approve steps for anything sensitive, with a human in the loop where the stakes are high.
• A full audit trail you can roll back, so any action can be explained and undone.
• Monitoring of uptime, errors, cost and behaviour, with someone stepping in when it drifts.

That last one is the most neglected. An automation's accuracy is not fixed: the data changes, your process changes, and the model provider updates the model underneath you. Without monitoring, degradation is invisible until a customer finds it.

If personal data is involved, the ICO's guidance on AI and data protection sets out your obligations, and they do not transfer to your supplier. For a structured way to think about the risks, NIST's AI Risk Management Framework is free and vendor-neutral. Where a model handles untrusted text, the OWASP Top 10 for LLM Applications covers prompt injection and the failure modes specific to these systems.

What it costs and how long it takes

Start with planning rather than a build. On our AI Opportunity Planning engagements a focused scoping engagement starts around £1,500 and a fuller, multi-process discovery is typically £3,000 to £6,000, with most running in one to two weeks. The output is a prioritised list of opportunities with feasibility and value against each, which is what stops the first project being chosen by whoever asked loudest.

Delivery then happens in fixed two-week Velocity Sprints with a predictable number of Output Units, so you see working automation early and commit one sprint at a time rather than to an open-ended programme. For the overall floor on bespoke work, our quote page is explicit: a bespoke project under £7.5k is unlikely and most of our projects are more than that.

Free of charge, the AI Opportunity Score assessment takes 4 to 6 minutes and will tell you where AI is most likely to help and which opportunities are quick wins — a reasonable place to start before spending anything.

Where these projects go wrong

Five failure modes account for most of the disappointment we are asked to fix:

• Starting with the technology. A project that begins "we should use AI" rather than "this queue is costing us" produces a demo nobody adopts.
• Automating a broken process. Automation makes a bad process faster, not better. Fix the process on paper first; sometimes that is the whole project.
• No owner after launch. Someone has to watch accuracy, cost and drift. Without that, quality decays silently.
• Skipping the review stage. Going straight to full autonomy removes the evidence you need to justify full autonomy.
• Counting savings that were never banked. Hours freed but not reallocated are not a return.

The first two are worth guarding against explicitly, because they are the ones that come from good intentions rather than carelessness. A board that has asked for an AI strategy creates pressure to start with the technology, and the most visibly irritating process in a business is often irritating precisely because it is badly designed rather than because it is manual.

Your first three steps

If you take nothing else from this: pick one process, not a strategy. Count what it costs you today in hours and errors, using your own figures. Then deploy at draft level, measure how often a person changes the output, and let that number decide whether it earns more autonomy.

That sequence is deliberately unambitious, and it is the one that works. The businesses getting real value from AI automation are not running the most sophisticated models; they picked a process that mattered, wired it properly into their systems, and turned the dial up slowly.

One practical note on sequencing: do the counting before you talk to any supplier, including us. A process you have already measured is one you can brief accurately and price honestly, and it makes you a much harder customer to oversell to.

To find the highest-value place to start, take the free AI Opportunity Score assessment, then book a free consultation to work through what it surfaces.