First-generation RPA tools made one assumption that was never stated explicitly: you already know which processes to automate. You know what the process does, you know all the steps, and you know all the variants. The tool's job is to execute that known process without human involvement. The discovery work was supposed to have happened already.
That assumption was wrong in 2015 when the first enterprise RPA deployments started, and it is still wrong today. The most consistent finding from every process automation engagement we have been involved in, across banking and insurance back-offices, is that operations teams do not have a complete map of the processes they run. They have partial documentation, tribal knowledge distributed across senior staff, and a working understanding of the clean-path cases. The edge cases, the variants, and the processes that have accumulated quietly over years of incremental change are not documented anywhere.
The practical consequence of this assumption failure is visible in the maintenance cost and failure rate of first-generation RPA implementations. Scripts that were built against an incomplete process definition break on cases they were not designed to handle. When they break, there is no process documentation to refer back to, so the fix is another round of observation and guesswork rather than a principled update.
The Discovery Phase as a First-Class Problem
The insight that Pointee is built on is simple enough to state: process discovery is itself a problem that can be systematized and partially automated. Not just in the sense of "run some workshops and take notes" but in the sense of observing actual system interactions across a real operating population over a real time window, identifying patterns, flagging recurring action sequences, and producing structured outputs that capture what the process actually does.
This is different from what process mining does. Process mining analyzes event logs from existing systems to reconstruct process flows. That works well when the systems in question generate rich, reliable event logs. In the legacy banking and insurance environments we work in, the event logs are often incomplete, poorly structured, or nonexistent for key process steps. A reconciliation operator who makes a judgment call and sends an email to a colleague is performing a process step that leaves no trace in the system log.
What we observe is the operator's interaction with the system interface: the navigation sequence, the data entry pattern, the screens visited and in what order. Across a population of operators and a window of sessions, these patterns resolve into a recognizable process structure that can be documented and reviewed. The process is discovered from its execution rather than reconstructed from system logs.
Why This Changes What Automation Can Deliver
When the discovery phase produces a complete process definition rather than a partial one, the automation built from it behaves differently from the start. It handles the cases that the partial definition would have missed. It has defined behavior for exceptions rather than undefined behavior that causes silent failures. The exception routing logic is built from documented exception types rather than discovered incrementally through production failures.
The more significant difference shows up over time. A process that was fully discovered and documented is maintainable. When a system update or a regulatory change requires modifying the automation, the person doing the modification has a reference document that describes what the automation is supposed to do. They can understand the intent of each step and make a targeted change rather than a trial-and-error patch.
The automation that is built on a complete process definition also tends to produce better audit trails, because the process definition was complete enough to specify what needed to be logged. Compliance-sensitive processes like regulatory reporting or claims payment verification have specific logging requirements that need to be known at design time, not discovered in a compliance audit.
The Process Count Problem
One of the most consistently surprising findings from discovery phases is the actual number of distinct processes an operations team runs. When we ask teams to estimate before we run a discovery phase, the number they give is typically between ten and twenty. The actual count, after observation, is almost always higher. Our average across the early-access clients we have worked with is around 34 distinct recurring processes per institution.
That gap is not because operations teams are unaware of what they do. It is because the unit of measurement in people's heads is different from the unit of measurement in a structured process inventory. An operator thinks of "the reconciliation" as one thing. In practice, there are four variants of the reconciliation: the daily interbank reconciliation, the end-of-week position reconciliation, the month-end close reconciliation, and the on-demand reconciliation triggered by a compliance request. Each variant has different steps, different tolerance thresholds, and different exception handling. They are four processes, not one.
A complete process inventory is also the foundation for prioritization. You cannot decide which processes to automate first if you do not know all the processes that exist. The standard approach of "pick the most obvious thing and automate it" frequently results in automating a medium-value process while leaving a higher-value one undiscovered.
The Skill Transfer Question
One dimension of the discovery-first approach that is underappreciated is what it does for institutional knowledge management. The structured process definitions that come out of a thorough discovery phase are the most complete documentation of how the operations function works that most institutions have ever had. They capture not just the formal procedure but the actual operating behavior, including the adaptations and workarounds that experienced operators have developed over years.
When a senior operator who has run a critical reconciliation process for six years leaves, the usual outcome is several months of degraded process performance while someone new learns by doing. With a complete process definition in place, onboarding to a documented process is fundamentally different from onboarding to tribal knowledge. The new operator has a structured reference. The automation handles the parts that can be automated. The knowledge does not walk out the door with the person who held it.
What the Next Wave of Automation Actually Requires
The constraint on automation progress in financial institutions is not primarily the automation technology. The tooling is capable enough for the processes in question. The constraint is process clarity: knowing what the process actually does well enough to build reliable automation on top of it.
The approach that addresses this constraint is to treat discovery as a systematic, technology-assisted phase that happens before automation development, not as informal preparation that happens in a few workshops. The output of that discovery phase is the asset that everything else is built on: the process definitions, the exception specifications, the audit trail requirements, and the maintenance documentation.
We are not saying manual observation and interview are outdated or should be abandoned. They are still essential for the steps that do not produce system logs. What has changed is the ability to augment that observation with systematic analysis of interaction patterns across a real operating population, and to turn that analysis into a structured output that is directly useful for automation development rather than a set of notes that someone has to interpret.