Every automation demo works. That is the problem, because a demo only ever runs the happy path: the data is clean, the document is attached, and the investor is exactly who the form expects.
Real operations aren't like that. Most cases flow through, and a minority don't.
The exceptions are where the time goes
Exceptions are a minority of cases and a large share of the effort. They need judgement, context and the right person, which is exactly what a simple automation lacks.
What usually happens to them isn't designed. The automation reaches its limit and drops the case into an inbox, a spreadsheet or a message to whoever was last involved. The easy volume disappears, and what is left is a smaller, harder pile with less structure than before.
That is how teams automate most of their volume and still feel like nothing has changed.
What a stranded exception looks like in fund operations
- A reconciliation break that matches no rule. It is flagged, then sits until someone notices.
- A subscription document that arrives with one page missing. The workflow can't proceed, and nothing tells the investor.
- An investor with an unusual structure, such as a fund of funds or a trust with several controllers, that the standard onboarding flow wasn't built for.
- A late NAV input that lands after the cutoff, with the deadline already running.
Each one is routine for an experienced operations person. Each one is invisible to a process designed only for the happy path.
Design the exception first
Reverse the usual order. Before you automate the easy path, decide what happens when it fails. Four questions:
- Who owns it? A named role, not a shared mailbox.
- Where does it go? A defined route with a deadline, not a forward.
- What do they see? The case, what was tried and what is missing, in one place.
- How does it close? A resolution that feeds back into the process, so the next case like it is easier.
An exception that is routed, owned and resolved inside the process is just another step. One that falls out of the process is an open problem with nobody's name on it.
Judge automation by how it fails
Anyone can automate the case that works. The harder test is the edge: whether the exception reaches the right person, with the context, before the deadline.
When you evaluate automation, don't ask how much of the volume it handles. Ask what it does with everything it can't.