When Success Is the Disaster

There is a particular kind of organisational crisis that deserves its own name. It is the crisis that arrives not because something went wrong, but because something went right — more right than anyone planned for — and the operation behind it was built for the old, modest level of demand.

You see this in restaurants that get a good review and then cannot seat anyone for eleven weeks. You see it in government services that launch an online portal and are immediately overwhelmed by the fact that people actually used it. And you see it in a mid-sized Canadian financial institution that sent a polite email to its customers asking them to confirm their phone number, and received approximately fifty times the expected response.

The campaign was a success. The operation behind it was not designed for success at that scale. Which is how a straightforward data hygiene exercise became, briefly, an emergency.

The Problem: A Marketing Triumph Meets an Operational Bottleneck

The institution was preparing to roll out multi-factor authentication (MFA) as part of a broader cybersecurity program. MFA requires accurate contact details — if the phone number on file is wrong, the second factor has nowhere to go. So the marketing team asked customers to confirm or update their information via a form inside online banking.

Perfectly sensible. Except for one detail.

The form did not update any core system. Each submission generated an email. That email arrived in a shared inbox. A human being opened it, read it, manually transposed the data into the core system, resolved any errors, and — because this is financial services — checked for regulatory implications. Certain address changes, for instance, can trigger tax residency reviews under FATCA and CRS obligations.

Under normal circumstances, this worked well enough. The team processed twenty to thirty-five requests per business day. Three to five minutes each. Manageable.

Then the campaign went live, and more than 1,800 submissions arrived in a single week.

At three to five minutes per request, that is somewhere between ninety and one hundred and fifty staff hours of manual data transposition — in a team that was already busy doing everything else it was supposed to be doing. The SLA, roughly two business days, was immediately at risk. Staff were borrowed from other departments to help process the backlog. The campaign itself was paused, which rather defeats the purpose of running a campaign.

The problem was not that the process was bad. Under normal conditions, it was perfectly adequate. The problem was that it could not scale, because every single submission — whether it was a straightforward phone number update or a complex address change with regulatory implications — passed through the same manual bottleneck.

And there were no APIs available to the core system of record. The only way in was through the user interface. Which meant the only way to speed things up was either to hire more people to click the same buttons faster, or to find something else to click the buttons instead.

The Approach: A Queue, a Robot, and a Very Clear Set of Rules

We designed and deployed a queue-based RPA solution using the organisation's existing Microsoft stack. Built, tested, documented, and in production in two very busy weeks.

The architecture had three parts, and if you will forgive the analogy, it works exactly like the system at any well-run deli counter: take a number, wait your turn, and if your order is unusual, a human deals with it.

Part 1: Intake and Queueing

When an email arrived in the shared inbox from the online form, the automation opened it, parsed the contents into structured fields — account number, new email, new phone, new address — captured metadata for traceability (including the Outlook email ID), and placed it into a work queue.

This is the "take a number" step. It decouples arrival from processing, which means a spike in demand does not cause a spike in chaos. The queue absorbs the shock. Items wait in an orderly fashion until they can be processed, rather than piling up in someone's inbox like post behind the door of an empty house.

Part 2: Automated Processing With Tightly Scoped Access

An unattended bot pulled items from the queue and executed the update in the core banking UI — the same screens a human would use, but considerably faster and with no possibility of transposing a 7 as a 1 because it was 4pm on a Friday.

The controls were strict:

• Least-privilege credentials — the bot could search and modify contact information, and nothing else; it had no more access than a new starter on their first day, and arguably less

• Secure credential handling — aligned to Microsoft guidance, with vault-backed credentials; no passwords in scripts, because passwords in scripts are not a shortcut, they are a future audit finding

• Clear exception rules — if the banking system raised a warning that required human judgement (a regulatory flag, a data conflict, an ambiguous address), the bot did not guess; it cancelled the update, marked the item as an exception, and forwarded the original email with a reason note to the contact centre

This last point is important. The goal was never one hundred percent automation. In financial services, that is not a goal — it is a liability. The goal was to automate the straightforward cases — the eighty percent that are identical and boring — and route the remaining twenty percent to humans with full context, so they could apply judgement to the cases that actually required it, instead of spending their time copy-pasting phone numbers.

Part 3: Routing, Escalation, and Monitoring

Every item moved through a clear lifecycle: queued, processing, then one of four terminal states — processed (archive and close), on hold (no action), exception (forward to contact centre with context), or error (escalate to IT operations).

Each state transition triggered the appropriate next step automatically. Nothing fell through the cracks. Nothing vanished into the void. Everything was logged, traceable, and auditable — because in a regulated environment, the question is never "did it work?" The question is "can you prove it worked, to someone who was not in the room?"

The Results

Built and deployed in two weeks. Not two weeks of design followed by six weeks of build. Two weeks, start to finish, from problem to production.

Average handling time: from three to five minutes to forty-seven seconds. Not because people were slow. Because the bot does not read the email, open three applications, look at the screen, type data in, check for errors, and wonder if it is time for lunch. It just processes.

Immediate SLA recovery. The backlog cleared. The campaign resumed. The data cleanup program stayed on track.

Months of cumulative time savings as ongoing cleanup and MFA readiness work continued at the new pace.

Improved data quality — transposition errors eliminated, update steps standardised, every action logged.

Better use of human attention — contact centre staff stopped spending their days copy-pasting phone numbers and started spending them on the cases that actually needed a human being: the edge cases, the regulatory flags, the situations where judgement matters.

To put a number on it: that first-week surge of 1,800 submissions would have consumed roughly ninety to one hundred and fifty staff hours to process manually. The automation handled it in approximately twenty-three and a half hours of unattended processing — returning somewhere between sixty-five and one hundred and twenty-five hours of human time in a single week. And that is before you count the errors that did not happen.

The Lesson That Nobody Finds Exciting

There is a strong temptation, in automation and AI, to reach for the most sophisticated tool available. It feels more modern. It photographs better. It makes for a more impressive conference talk.

But the right tool is the one that fits the problem, not the one that fits the narrative. This project did not need machine learning. It did not need natural language processing. It did not need a large language model or a neural network or anything that would require the word "intelligence" in its description.

It needed a robot that could read an email, type data into a screen, and know when to stop and ask a human. That is not glamorous. It is also not the point. The point is that a team that was drowning in manual work is no longer drowning, the data is cleaner than it was when humans were doing it, and the whole thing was delivered in a fortnight using tools the organisation already owned.

Sometimes the boring answer is the right answer. And the ability to recognise when that is the case — rather than reaching for something more exciting because it feels more like progress — is, in its own quiet way, the most valuable kind of expertise there is.

5× faster processing · Months of FTE capacity returned · Two-week delivery

Facing a similar bottleneck?

If a process is swallowing your team's time and you are not sure whether the answer is AI, RPA, integration, or simply a better design — start with a conversation.

Book a discovery call | Learn more: process audit | Learn more: process automation