Start with something worth knowing before you read another word. Researching this piece, we read eleven guides on choosing an automation partner. Every one of them was published by a company that sells automation services, including the company writing this page.
That is not a scandal, it’s the shape of the market, and it has one practical consequence. Nearly every question those guides tell you to ask has an obvious right answer that any agency will simply give you. Do you have experience in our sector? Yes. Is your pricing transparent? Yes. What’s your handover process? We document everything. Not one of those questions can be failed in a meeting, which makes them decoration rather than diligence.
There is one other thing worth checking before you trust the genre. A single statistic does most of the persuading: that thirty to fifty per cent of automation projects fail on the first attempt. We went and found the original. It is an EY paper from 2016 called Get ready for robots, and what it actually says is that EY has “seen as many as 30 to 50% of initial RPA projects fail”, on the basis of having delivered robotic process automation across twenty countries and being called in when a first attempt went wrong. So it is an upper bound, from one firm’s own delivery experience, about one technology, and it is almost ten years old. It now gets quoted as a flat failure rate for automation in general. The number may still be about right. The point is that almost nobody repeating it has read it.
So this piece does something different. It asks only questions whose answer is a document, a log, a name, a number or a date, because those either exist or they do not. And it gets to them the long way round, by writing the failure report first.
What You’re Actually Handing Over
When you hire a workflow automation agency, you are handing over three things at once: a decision your team used to make, a set of credentials that reach into your systems, and a new failure mode nobody in your company has seen before. The software is the easy part. Those three are what you will live with.
The decision matters most. A rule that routes a form to a queue is not a decision, and if that’s all you need, a low-cost tool and an afternoon will do it. The moment the work involves judgement, which invoice belongs to which account, which customer gets the refund, which application goes through, you have moved a decision out of a person’s head and into a system, and that system now needs the things a person came with for free: an explanation, a memory, and somebody to ask when it looks wrong.
The credentials matter second. Automations run as somebody. They hold API keys, mailbox access, accounting permissions, sometimes payment rights. Whoever holds those credentials at the end of the project holds a large part of your operation, and in a surprising number of engagements it is not you.
The failure mode matters most of all, because it is new. A person who stops doing a task tells you, or is visibly absent. An automation that stops doing a task does so quietly, at four in the morning, and the first sign is a customer asking where something is. That is the whole reason for writing this article the way it is written.
Write the Failure Report Before You Sign
A pre-mortem is a planning technique in which a team assumes the project has already failed and works backwards to explain why. Gary Klein set it out in Harvard Business Review in September 2007, citing a 1989 study by Mitchell, Russo and Pennington which found that prospective hindsight, imagining that an event has already happened, increased the number of reasons people generated for it by about thirty per cent. The study counted reasons rather than judging them, so treat it as a way of getting more on the table rather than a guarantee of better thinking. In our experience it takes about an hour, and it’s the most useful hour you will spend on an automation project.
So do it before you sign, not after. Put the date eighteen months from now at the top of a page and write the sentence you are dreading: the automation we bought in 2026 has been switched off, and here is what went wrong. Then fill in the report.
What follows is that report, written six ways. They are the six failures we see most often rather than an exhaustive taxonomy, and each one ends in the same place: the specific artefact you should have asked for while the agency still wanted your signature.
Failure One: It Stopped Working and Nobody Noticed
The most common automation failure is silence. The workflow does not error, it simply stops running, and because nothing appears in an inbox and nothing turns red, nobody finds out for days. Ask what fires an alert when the automation does nothing at all, who receives it, and what the last ninety days of that alert look like.
Most monitoring watches for things going wrong. Automations need the opposite: an alarm on absence. If a workflow normally processes between forty and a hundred items a day and today it processed none, that’s the alert, and it has to reach a person rather than a dashboard nobody opens. Google’s site reliability engineering book makes the general version of the point, that alerting should page a human on symptoms rather than causes, and it names traffic, the demand placed on a system, as one of its four golden signals. For an automation the symptom is the mirror image of that: work arriving while nothing comes out the other end. Which is also why the alert has to compare items waiting against items completed rather than simply watching for silence, because a quiet Sunday is not a fault.
There’s a second half to this, and it is the one agencies skip. An alert with no owner is theatre. Ask for the name of the person who receives it on a Saturday, what happens if that person is on holiday, and how the alert is tested. The test question is the one that separates real answers from confident ones, because a monitor nobody has ever deliberately tripped is a monitor nobody knows works.
Ask for: the alert that fires on absence, the name it reaches, and the history of that alert firing over the last ninety days. A screenshot of the alert configuration takes ten seconds to produce if it exists.
Failure Two: The Process Changed and the Automation Didn’t
Automations are built against the world as it is on the day they are built. Then your accounting software adds a field, a supplier changes an invoice layout, a team renames a status, and the automation keeps running confidently against assumptions that are no longer true. Ask who is supposed to tell the automation that the process changed, and how.
Most agency-selection guides treat process change as a pricing question, retainer against fixed scope, rather than as a named procedure with an owner. The better ones do ask what breaks when a supplier moves a button or changes an API. Very few ask who inside your company is responsible for telling the automation that the process moved. The automation doesn’t break loudly in this scenario. It carries on producing output that’s wrong in a way that takes a quarter to spot.
Two things prevent it, and neither is software. The first is a named person inside your company, not the agency, whose job description includes telling somebody when a process changes. The second is a written procedure that says what happens next: who is told, what gets tested, and who signs it off. On the technical side, ask whether the integrations are covered by tests that fail when an upstream system changes shape, rather than discovering it in production. If your automation reaches into several systems, that question extends to AI integration for the systems the workflow touches, because each connection is a place the ground can move under you.
Ask for: the written change-notification procedure and the name of the person inside your company who owns it. If the answer is that the agency will notice, ask how, and listen for a mechanism.
Failure Three: The Exception Queue Ate the Saving
Every automation leaves a residue of cases it can’t handle, and those cases land in a queue that a human works through. If nobody estimated the size of that queue before the build, the saving you were promised can disappear into it entirely. Ask for the expected exception rate as a number, and what it actually was in week one and week twelve on their last build.
The exceptions are not a rounding error. They’re the hard cases by definition, so each one takes longer than an ordinary item did, and the person handling it now has to reconstruct what the automation was trying to do before they can finish the job. Agencies talk about human-in-the-loop as a safety feature, which it is. They rarely price it as labour, which it also is.
The Arithmetic to Ask For Before You Sign
Here’s the shape of it, with round numbers you can replace with your own. Say the loop is 500 supplier invoices a month and each takes three and a half minutes by hand. That is a little over 29 hours a month of work.
Automate it with a ten per cent exception rate and 50 invoices come back to a person. Give each of those six minutes, because exceptions are the awkward ones, and the queue costs five hours. You’ve saved roughly 24 hours a month, and the project looks excellent.
Now let the exception rate come in at 25 per cent. Treat that as a stress test rather than a norm, since our own published invoice build settled under three per cent, but a first build against genuinely messy inputs can land there. That’s 125 invoices and 12 and a half hours, so the saving drops to about 17 hours. Now let each exception take twelve minutes instead of six, because the person has to open the log, work out what the automation did, and undo half of it. That’s 25 hours in the queue, and your 29-hour loop now saves about four hours a month. The automation still works. The saving has gone.
That’s an hours model rather than a full business case, since it leaves out the build price and the monthly run cost on both sides. Run it with your own figures. It still does the job it needs to do, which is to turn the exception rate from a footnote into the number the deal hangs on. Then ask who staffs the queue, what response time they’re held to, and what happens when it backs up during a holiday week.
Ask for: the expected exception rate, the measured rate from their last two builds at week one and week twelve, and the name of the person who will work the queue.
If you are weighing a proposal right now and the exception rate is not in it, send it to us with the cover sheet removed and we’ll tell you what we’d want added before anyone signs.
Failure Four: Nobody Could Prove What It Did
Eighteen months in, somebody asks why a particular invoice was coded to a particular account, or why a customer was refused. If the automation can’t answer, you own the consequences without the evidence. Ask to see one real line from the audit log, with the fields it records, before you sign anything.
A usable audit line carries six things, and a seventh where a model was involved:
- Who or what acted, and on whose behalf.
- The record it acted on.
- The action it took.
- The inputs it acted on, and where they came from.
- The result, and whether it succeeded.
- The timestamp, to the second.
- Where a model made the judgement: the reasoning and the confidence score behind it.
That last one matters because “the system decided” is not an answer you can give a finance director, an auditor or a customer. The test is simple and slightly unfair, which is why it works: ask them to pull one line from a live client system, redacted, and walk you through it. Teams that log properly enjoy this question.
Logs also have to survive. Ask how long they are kept, where they live, and whether you still have them if you stop paying the agency. An audit trail held in the agency’s account is an audit trail you’re renting.
When the Workflow Decides Something About a Person
If the automation makes decisions about people rather than invoices, there’s a legal dimension that none of the eleven agency guides we read mentioned. The UK rules changed here in 2026. The Data (Use and Access) Act 2025 rewrote the old Article 22 rules, and the ICO now says all the provisions affecting data protection law are in force. On the ICO’s own summary, the change “opens up the full range of reasons, or ‘lawful bases’, that you can rely on when you use people’s personal information to make significant automated decisions about them. So long as you continue to apply appropriate safeguards”, with the exception of the new recognised legitimate interests basis, and it does not apply to special category data, which stays more protected.
The safeguards are the part that shapes your build. Where a decision is made with no meaningful human involvement and has a significant effect on somebody, that person has to be told about it and be able to make representations, contest the decision and obtain human intervention. In practice the route to a human exists before go-live rather than after the first complaint, and somebody can explain the logic in ordinary language. It bites on things like an automated credit refusal or a recruitment sift run without human review, and far less on coding a supplier invoice, where the ordinary data protection duties apply instead. This is general information rather than legal advice, the guidance in this area is still settling, and your own counsel should decide which of your workflows fall inside it. Ask the agency which ones they think do. An agency that has never considered the question is telling you something.
This is also the line where routing stops and judgement starts. Automation that follows a fixed rule is one kind of build. It’s a different piece of engineering when the workflow needs to make decisions, and it needs the escalation gate, the evaluation set and the audit trail to go with it.
Ask for: one redacted line from a live audit log, the retention period, and, for decisions about people, the written route to a human.
Failure Five: The Person Who Built It Left the Agency
Small agencies run on individuals. The engineer who built your workflow understood your business, your exceptions and the reason for that strange rule in step four. When they leave, that understanding leaves with them unless somebody wrote it down. Before you sign, ask for the name of a second engineer who has been inside a comparable build and the date they last worked on it. Then put a line in the contract saying a second named engineer will have run yours within the first month.
Notice what that question does. It can’t be answered with a process description. Either a second engineer has been inside a build and there’s a date, or there hasn’t and there isn’t. The same applies to your own side: if one person in your company is the only one who knows how to pause the automation, you have the same problem in miniature.
The written form of this is a runbook: how to pause it, how to restart it, how to run the loop manually if everything is down, and what the automation must never do. Ask to see the runbook from a previous project, redacted. A team that writes runbooks has one lying around. A team that doesn’t will offer to write yours.
Ask for: the name and the date, a redacted runbook from an earlier build, and the contract line that puts a second named engineer inside yours.
Failure Six: You Wanted to Leave and Couldn’t
The most expensive automation failure isn’t technical. It’s discovering that the workflows live in the agency’s account, on the agency’s platform plan, running on API keys the agency created, and that leaving means rebuilding. Ask whose account it runs in and whose card pays for it, in the first meeting, before anybody talks about scope.
There are four things to establish, and all four are checkable in writing.
- The account: whose subscription the workflows live in, and whose card pays for it.
- The credentials: whose API keys and permissions the automation runs under.
- The ownership: who owns what was built, stated in the contract rather than in an email.
- The exit list: what physically arrives on your last day, from exported workflow definitions and code to the runbook, the logs and the transfer of any account opened on your behalf.
The honest version of this arrangement is common and fine, as long as it is deliberate. Plenty of agencies run client automations in their own tenancy because it’s easier to support, and plenty of clients are happy with that. The failure is finding out by accident in month twenty, when the relationship has soured and your operations are inside somebody else’s subscription. Put the answer in the contract while everyone is still being pleasant.
Ask for: a named account owner, a written ownership clause, and an exit clause with a notice period and a list of what you receive on the last day.
The Nine Artefacts, and What Each One Proves
Here is the pre-mortem collapsed into nine things to ask for. None of them can be satisfied with an adjective. Each one either exists, in which case it can be produced in minutes, or it doesn’t, which is the answer you came for.
- The alert that fires when the automation does nothing, and the name it reaches.
- Ninety days of history showing that alert firing and being acted on.
- The written procedure for telling the automation that a process has changed, and the owner’s name.
- The expected exception rate, with measured figures from their last two builds.
- The name of the person who will work the exception queue, and the response time they’re held to.
- One redacted line from a live audit log, every field it records, and how long the logs are kept.
- For decisions about people, the written route to a human before go-live.
- The name of a second engineer who has been inside a comparable build, a redacted runbook from it, and the contract line putting a second named engineer inside yours.
- The account it runs in, whose credentials it uses, the ownership clause, and an exit clause with a notice period and a list of what arrives on your last day.
Nine is a lot to bring to a first meeting, and you won’t need all of them for a workflow that moves files between two folders. Bring three to any conversation: the alert on absence, the exception rate, and the account it runs in. Between them they cover whether you will find out when it breaks, whether the saving is real, and whether you can leave.
What to Do With a Confident Answer and No Artefact
You’ll sometimes get a good, fluent answer and no document. That isn’t automatically disqualifying, especially with a young agency doing careful work. The right response is to stop asking and start writing: put the artefact into the statement of work as a deliverable with a date, priced like everything else.
An agency that meant it will agree without flinching, because you have just asked them to be paid for something they were planning to do. An agency that didn’t will explain why it isn’t necessary for a project of this size. That explanation is the most informative thing you will hear all week.
When Not to Automate This Yet
Don’t automate a process that is still changing shape, one that nobody can describe the same way twice, or one where the exceptions are the majority of the work. Automation makes a process faster and more literal. It doesn’t make it better, and a broken process automated is a broken process at scale.
The test we use is whether two people who do the job describe it the same way. If they do not, the disagreement is the project. Spend a week writing down what actually happens, including the parts people do out of habit and the parts they do because a customer complained once in 2023, and you’ll often find the loop shrinks before anyone writes code.
Talk to the people whose work is being automated, and do it before the agency arrives rather than after. They know why the exceptions exist. They’re also the ones who will work the queue afterwards, and an exception queue handed to someone who wasn’t consulted is a queue that gets worked slowly.
We’ve sent people away over this more than once, and it costs us the project. It’s still cheaper for both sides than automating a process that is about to change.
How Empyreal Infotech Answers Its Own Pre-Mortem
It would be poor form to publish nine questions and duck them, so here are our answers, including the ones we can’t currently satisfy. We’ve shipped 18 AI automations into UK ops, sales and finance teams since 2023. The median saving is £28K a year per automation after run cost, and the published payback is about eleven weeks from signed scope to break-even.
Every build starts with a five-day audit that baselines the time and error rate of the manual loop, so the saving is measured rather than asserted, and we write the report to your finance director ourselves rather than asking you to. Every automation has a confidence threshold you control, and anything below it goes to a human with the reasoning attached. On our published invoice-coding build the error rate fell from four per cent to 0.4 per cent after launch, and the automation routes under three per cent of invoices to a person. On automation builds, every AI decision logs the input, the reasoning and the output, and exports for finance, audit or regulators. On agent builds the log goes further, recording actor, tenant, tool, arguments, result and timestamp on every tool call.
A single automation is from £18K on a fixed scope over four to six weeks, and it includes the exceptions queue interface, the audit log, the workflow registry and a thirty-day walk-away clause that runs both ways. Billing is in four equal milestones. Two senior engineers are on every AI automation project rather than one, with every decision written into a record the same day.
Now the gaps, measured against our own list. We can produce the alert configuration and its recent history as a screenshot from a live system on request, rather than publishing a standing dashboard for prospects. Exception rates vary so much by input quality that we won’t quote yours before the audit week, so our answer there is a method until we have seen your data. We don’t today publish a written change-notification procedure, a named queue owner with a response time, a redacted audit line, a log retention period, or a second named engineer with a date. Two senior engineers on every project is a process description, and by our own test that is not an answer. Nor do we publish the name the absence alert reaches, a measured exception rate from a second build, a redacted runbook, an ownership clause, a list of whose credentials the automation runs under, or an exit list of what arrives on your last day. And on decisions about people we publish no written route to a human before go-live. The confidence threshold sends low-confidence work to a person, which is a useful thing and a different artefact. On the accounts question the default is that everything runs in yours, and if you would rather we hosted it we’ll write the transfer terms into the contract before we start rather than after you ask.
FAQ: Choosing a Workflow Automation Agency
What questions should I ask an automation agency before hiring them?
Ask only questions answered by an artefact: the alert that fires when the workflow does nothing, the expected exception rate with measured figures from past builds, one redacted line from a live audit log, the name of a second engineer who has run the system, and whose account the automation runs in. Adjectives can be asserted. Documents cannot.
Who owns the automations an agency builds?
Whoever the contract says, and in the absence of a clause, often not you. Ownership splits three ways: the workflow definitions and code, the account and platform subscription they run in, and the credentials they use. Settle all three in writing before the build, and include an exit list of what you receive on the last day.
How much does it cost to hire a workflow automation agency?
Build prices vary widely and most published bands are the publisher’s own price presented as market data. Empyreal Infotech publishes from £18K on a fixed scope for a single automation over four to six weeks. Whatever the build costs, ask separately for the monthly run cost and the hours the exception queue will consume.
What happens when an automation breaks after the agency leaves?
Usually nothing visible, which is the problem. Workflows tend to fail silently rather than loudly, so the first signal is a customer or a month-end. Before signing, establish what alerts on the absence of activity, who receives it, what the response time is, and whether that support continues after the build ends.
What is automation debt?
Automation debt is the accumulated cost of workflows nobody maintains, documents or fully understands: the half-forgotten integrations that still run, still touch live systems, and still break. It grows the same way technical debt does, and the usual cure is a registry of every automation, an owner for each and a scheduled review.
Eighteen Months From Now
The pre-mortem works because it changes what you’re listening for. Walk into a pitch wanting to be convinced and you’ll hear capability. Walk in having already written the failure report and you’ll hear whether the agency has lived through one.
None of the six failures in this piece is exotic. They’re the ordinary ways ordinary automation projects end, and every one of them is cheap to prevent in the week before signing and expensive to fix in month twenty. The nine artefacts are the whole prevention budget.
If you want a second opinion on a proposal that’s already on your desk, send us five lines about the loop: what it is, what it touches, and what it costs when it goes wrong. Mohit reads every first email and replies inside 24 hours on weekdays, 72 over a weekend, with a clear yes, a clear no, or the one question that decides it.
Ask for the artefact. An agency that has them will be glad you asked, and one that doesn’t has just told you what its next eighteen months look like.