There is a pattern that shows up in almost every RPA consulting engagement at financial institutions. The consultant arrives, meets the operations team, documents a handful of processes, builds the automation scripts, and delivers a working system. Twelve months later, a different consultant arrives at a different client, documents what are essentially the same processes, and builds the same scripts from scratch. Nobody seems to find this strange.
We spent years on the consulting side of this before building Pointee. The experience of rebuilding the same account reconciliation logic, the same claims intake routing, the same end-of-day reporting process at institution after institution is the direct reason this company exists.
But diagnosing why it happens requires more precision than "consultants are inefficient" or "clients need better documentation." The structural reasons are more interesting, and understanding them clarifies what a different approach actually requires.
Why Reuse Does Not Happen Naturally
The obvious answer is that every client has a different core system, a different data model, and different internal procedures. An account reconciliation script built for a client on one core banking platform cannot be transplanted to a client on a different platform. The scripting has to start from scratch because the underlying system interface is different.
That explanation is true but incomplete. The more important reason is that what gets documented at each engagement is not the process. It is the implementation. The deliverable from a typical RPA engagement is a working script and a technical runbook, not a structured description of the business logic that the script encodes. When the next engagement starts, nobody has a reusable artefact. They have the previous client's code, which is not reusable.
Process logic, in contrast, is largely reusable across institutions. The steps involved in daily position reconciliation are similar enough across banks that a well-documented process model for that workflow at Client A would serve as a starting point at Client B. The difference is in the system-specific implementation steps, not in the underlying business logic. But because RPA projects document the implementation rather than the logic, nothing carries over.
The Pre-Automation Phase That Gets Skipped
Every RPA engagement has an implicit pre-automation phase: figuring out which processes to automate and how they actually work. In practice, this phase is usually compressed into a few hours of workshops and some screen-recording sessions. The output is enough for the developer to build something that passes a demonstration. It is rarely enough to produce automation that handles the full range of real operating conditions.
When we ask operations teams how they first describe a process to an incoming consultant, the answer is almost always "we show them what we do." A senior operator walks through the process once, answers questions, and the developer takes notes. The documented version of the process is the senior operator's clean-path version on a normal day.
What does not get captured: the cases that happen a few times a month but require different handling. The workarounds that three of the seven operators use because they found a faster path. The step that everyone knows to do differently when the system is in end-of-month mode. The exceptions that go to a specific person's inbox rather than the standard queue.
Automation built on the clean-path version will fail silently on edge cases. The failures will not necessarily surface immediately. They will show up as unexplained queue backlog, unmatched records that someone manually resolves without logging, or exceptions that never make it to the exception routing path because they were never accounted for.
What Happens When Scripts Are Maintained Under Pressure
RPA scripts in production at financial institutions degrade. The systems they interact with change. Vendors push UI updates that break selectors. An internal project modifies a report format. A regulatory change adds a new required field to a data entry screen. The automation stops working.
In the typical engagement model, fixing a broken automation means finding the person who built it, which is often a contractor who has since moved on, or digging through code that has no accompanying process documentation. The fix is patched into the existing script without a full understanding of what the script is supposed to be doing at a process level.
Over several iterations of this, the script becomes fragile and opaque. Nobody wants to touch it because nobody fully understands it. The operations team works around its limitations. Eventually the decision is made to rebuild it, and the cycle starts again.
We are not saying this is unique to RPA or to financial services automation. Any technical system with insufficient documentation and high staff turnover will degrade in a similar way. But RPA in financial operations is particularly exposed because the processes it automates are often compliance-adjacent, making silent failures expensive, and the environments it runs in are particularly prone to incremental change.
The Reframe: Process First, Script Second
The alternative is not better scripting methodology. It is a different ordering of the work. If the first deliverable of an automation engagement is a structured, reviewed process model rather than a working script, then the implementation that follows has something to build from that is independent of the specific system interface.
A structured process model for daily position reconciliation describes the business logic: what data is being compared, what tolerance thresholds apply, what constitutes a match, what triggers an exception, and who is responsible for each exception type. That model is useful regardless of which system the automation will interact with. It is also the artefact that makes future maintenance possible, because anyone picking up the automation can understand what it is supposed to do before they start reading code.
When Pointee runs a discovery phase, the output is that structured process model. It takes longer than a two-hour workshop. It requires multiple observation sessions across different operators and different operating conditions. But the automation built on top of it is more durable, the exception handling is more complete, and when something breaks, the fix is faster because the intent of each step is documented.
The Measurement Problem
Part of what sustains the consultant trap is that the cost of rebuilding scripts from scratch is never directly visible in an engagement budget. Each project is scoped independently. The discovery work at the start of the engagement looks like project overhead; nobody counts the hours spent relearning a process that was documented three years ago at a different client.
From a client's perspective, the cost shows up differently: in script maintenance hours, in automation downtime, in the exception cases that fall through to manual handling, and in the eventual decision to "replatform" the automation after a few years of accumulating fragility.
The argument for investing more time in process documentation before writing a single line of automation code is not that it is philosophically cleaner. It is that it reduces the total cost of the automation over its operational lifetime, including the rebuilds that everyone knows will eventually be necessary but nobody wants to count in the initial budget.