The first question we ask when we start a discovery engagement at a bank is: how many distinct repeating processes does your operations team run? The answer almost always falls between ten and twenty. The number we find when we actually observe how the team works is almost always higher. Our average across early-access clients is approximately 34.
That gap is not a failure of awareness. The people running those operations are experienced, capable, and accurate about the processes they think about most. The gap is a structural feature of how operational processes accumulate in a financial institution over time, and of how the human mind categorizes them.
How Process Proliferation Happens
A bank's back-office operations evolve in layers. The core processes were established when the institution was founded or when a major system was implemented. Those processes were documented, trained, and understood. Over time, regulatory requirements changed. New products were launched. System upgrades introduced new workflows. A major corporate client required a specific reporting format. A compliance ruling changed how a category of transactions needed to be handled.
Each of these changes added a layer. Some layers replaced older processes. Most accumulated on top of them. The result is an operations function that has processes dating from the original installation and processes added last quarter, coexisting in the same team, often handled by different people with different institutional memory about why each process exists in its current form.
The standard documentation tools, procedure manuals and process maps maintained in a SharePoint folder, cannot keep pace with this kind of organic accumulation. They capture the processes that someone thought to document. They do not capture the processes that evolved from informal decisions, the ones that were handed from one departing employee to the next, or the ones that emerged from a system workaround that turned into a permanent workflow.
The Categorization Problem
When we ask an operations director how many reconciliation processes they run, they typically say "one or two." What we find when we observe is that there are often four to seven variants: daily position reconciliation, weekly settlement reconciliation, end-of-month close reconciliation, ad-hoc regulatory reconciliation, and a special-case reconciliation for specific transaction types that is run when certain conditions occur. Each variant has different steps, different tolerance thresholds, and in some cases different system access requirements.
To the operations director, these are all "reconciliation." They share a common purpose and a common general procedure. The variation between them is understood as context-specific adjustment rather than as distinct processes. But from an automation standpoint, they are distinct: each requires its own process definition, its own exception handling, and its own output specification.
The same categorization pattern appears in policy renewal handling, claims intake routing, regulatory reporting, and most other back-office function areas. The high-level category contains multiple process variants that each require separate treatment.
The Tribal Knowledge Layer
The processes that are least likely to be in any documentation are the ones that were established informally. These processes exist because a particular problem needed to be solved, a particular client needed a particular output, or a particular regulatory requirement needed to be met, and the solution was implemented by whoever was available at the time. The implementation became the standard. The standard was never written down because the person who implemented it was still there.
These tribal processes are often among the most time-consuming because they are not optimized. They were designed for the original constraint they solved, not for efficiency. They are also the most fragile. When the person who knows how to run them leaves, the process either stops or someone reconstructs it from partial information, introducing variation from the original.
In one discovery phase at a regional savings bank, we found three separate informal processes that had been established to handle a specific category of interbank transactions that occurred at month end. Each process had been created by a different person at a different point in time to address the same underlying requirement. Two of them were still running in parallel. Nobody on the current team knew that both existed until we mapped them.
Why This Matters for Automation Planning
An automation roadmap built on an incomplete process inventory will miss opportunities and produce surprises. If you believe you have fifteen automatable processes and you actually have thirty-four, your automation roadmap covers less than half the available opportunity. The processes you have not discovered will continue to consume operator time after automation delivers its first results, and the case for further investment will be harder to make because the efficiency gains will seem lower than they should.
The surprises appear in production. An automation built for what the operations team described as "the reconciliation process" encounters variants it was not designed to handle. Those variants fall out to manual handling without a defined exception path. The automation's coverage, measured against the actual population of cases rather than the described population, is lower than expected.
A complete process inventory is not just an academic exercise. It is the foundation for a realistic automation roadmap, accurate ROI projections, and exception handling that covers the actual range of cases rather than the cases that came up in the workshop.
What a Complete Process Inventory Looks Like
A complete process inventory for a bank's back-office operations function includes, for each process: a unique identifier, the function it belongs to, the systems it touches, the approximate weekly or monthly frequency, the number of operators who can run it, the known exception types, and a structured description of the process steps. The last element is the most difficult and the most valuable.
Producing that inventory requires observation over a representative time window, not just workshops. The processes that run only at month-end will not appear in two days of observation. The processes that are normally handled by a specific operator who was out sick during the observation period will not appear either. The inventory is only as complete as the observation period and methodology allow.
We build the discovery phase at Pointee to run long enough to capture the full operating cycle of the team being observed. For most banking operations functions, a four-to-six-week observation window covers the processes that run daily, weekly, and monthly. The processes that run quarterly or ad-hoc are captured through interview and document review rather than direct observation, because waiting for them to occur naturally would extend the timeline impractically.
Not All Discovered Processes Are Automation Candidates
We want to be clear about what a complete process inventory is not: it is not a list of automation candidates. Finding 34 processes does not mean 34 processes should be automated. Some processes are low-frequency enough that the automation investment is not justified by the efficiency gain. Some involve enough human judgment that automation is not appropriate for the current state of the technology. Some are performed so infrequently by so few operators that the documentation value exceeds the automation value.
The process inventory is the input to the prioritization discussion, not the output. Once you know what exists, you can make an informed decision about which processes to automate, in what order, and what to do with the ones that are not automation candidates. Without the inventory, that decision is made based on incomplete information, which is how automation programs end up automating the obvious processes while the more valuable ones remain undiscovered.