Insights / Article / Generative AI, copilots and agentic automation
ArticleAutomation that works: intelligent process automation without the hype
How to choose processes for automation, decide between rules and AI, design for exceptions and keep the benefits as the business changes.
Automation promises to remove manual work, and it often does. It also produces disappointment when it is aimed at the wrong process, built without an owner or left to decay after launch. The difference between the two outcomes is rarely the technology. It is the discipline applied before and after the build.
Gartner has predicted that through 2026 around 30% of generative AI projects will be abandoned after proof of concept. It is a useful reminder that a good demonstration is not a good process. A demonstration shows what a tool can do on a clean example. A process has to cope with every example, every day, including the awkward ones.
Choose the right process
The best candidates for automation share four characteristics. They run at high volume, so small savings per transaction add up. Their rules are stable, so the automation does not need constant rework. Their inputs are digital, or can be made digital cheaply. And their results are easy to check, so errors are caught quickly.
- Supplier invoice entry and three-way matching against orders and receipts.
- Sales order confirmation and delivery notifications.
- Employee onboarding forms, system access requests and equipment orders.
- Preparation of recurring management and regulatory reports.
- Customer address changes, account updates and other routine service requests.
Avoid, at least at first, processes that change every month or depend on judgement that nobody can write down. If two experienced people would handle the same case differently, the process needs standardising before it can be automated. Automating an inconsistent process simply makes the inconsistency faster.
Fix the process before you automate it
Map the process as it really runs, including workarounds. Remove unnecessary steps and approvals first. Automating a wasteful process locks the waste in.
Rule-based or AI-based?
Not every automation needs AI. Where rules are clear and inputs are structured, such as a web form or a system export, plain workflow automation is cheaper, faster and more predictable. It does exactly what it is told, every time, and it is easy to audit.
AI earns its place where inputs are messy: scanned documents in different layouts, free-text emails, photographs of delivery notes or voice messages. Here, AI can read, classify and extract the information that a rule-based workflow then acts on.
Many good solutions combine both. Consider a typical accounts payable team receiving invoices by email from hundreds of suppliers. An AI component reads each invoice and extracts supplier, date, amounts and order number. A rule-based workflow then matches the invoice to the purchase order and goods receipt, approves it if everything agrees within tolerance, and routes it to a person if not. Each part does what it is good at.
When AI is involved, set a confidence threshold. If the extraction is confident and the rules agree, the case flows through. If confidence is low, or the extracted amount does not match the order, the case goes to a person. Start with a conservative threshold so that more cases are reviewed in the early weeks, then relax it as evidence builds. This is slower at first, but it protects trust while the team learns how the system behaves.
Design for exceptions
Every automated process meets cases it cannot handle: a missing order number, an unfamiliar supplier, a scanned page upside down, a request that fits no category. These exceptions are not a failure of automation. They are a normal part of it, and the design must treat them as such.
Decide, before you build, what happens when an exception occurs. Who is told? What do they see: the original document, the extracted data and the reason it was flagged? How fast can they resolve it, and does their correction help the automation handle similar cases next time?
Trust in automation is built by the quality of its exceptions, not by the percentage it handles.
An automation that fails silently loses trust quickly. If a customer’s request disappears into a queue that nobody watches, the damage outweighs months of efficient processing. Make exceptions visible, assign them to named people or teams, and set response targets just as you would for any other service.
Design the exception screen with the people who will use it. They know what information they need to resolve a case in one step rather than three, and a few hours of their input at design time can save minutes on every exception for years.
Measure and maintain
Automations decay. Suppliers change their invoice layouts, forms gain new fields, regulations shift and systems are upgraded. An automation that handled most cases cleanly at launch can quietly slide into routing most of them to people within a year.
- Track volumes, handling time, error rates and exception rates from the first day.
- Review the measures monthly with the process owner, not just the technical team.
- Investigate any rise in exceptions; it usually signals a change upstream.
- Name one owner who is responsible for the automation’s performance and has budget for changes.
- Keep documentation current, so a new team member can understand what the automation does and why.
The owner matters most. Automations built by a project team and handed to nobody tend to be abandoned when they first break. An owner with time and a small budget keeps the benefit alive.
It also helps to set expectations about savings honestly. Automation rarely removes a role entirely in its first months. More often it removes the repetitive part of several roles and shifts people towards exceptions, supplier queries and improvement work. Plan for that shift, and explain it early, so the people closest to the process see the automation as help rather than as a threat.
A short checklist before you start
Before committing to any automation, ask five questions. Is the process stable? Is the input digital? Is the benefit measurable? Is there an owner? Is there an exception route? If any answer is no, fix that first. It is cheaper to spend two weeks standardising a process or appointing an owner than to spend two months building an automation that nobody trusts.
Start with one process, measure it honestly for a quarter, and expand only when the numbers and the people who use it both say it works.
Source: Gartner, 2024 prediction on generative AI projects.
