What Happens When Half Your Staff Can't Use the Tools You Just Rolled Out

Picture a fund administrator six months after rolling out automation for NAV close. The launch went well. There was training, a few champions on the team picked it up fast, and the numbers on adoption looked healthy in the first month.

Then you look closer. Half the team is flying, using the tool properly, trusting its output, working faster than before. The other half, often the people who've been doing this job the longest, are quietly running the old process alongside it "just to check", or have stopped flagging exceptions the system doesn't recognise because raising them feels like more hassle than it's worth. Nobody decided this was going to happen. It just did, gradually, while everyone was looking at the adoption dashboard instead of at who was actually using the thing and how.

This is the two-tier ops team, and it's one of the quieter risks of any automation rollout. Nobody sets out to create a hierarchy of who can and can't use the new system. It happens by default, unless someone actively designs against it.

What the data actually says

PwC's research into the AI workforce gap in financial services found that only 42% of firms have done any enterprise-wide modelling of how AI actually changes labour and capacity before rolling tools out. In other words, most firms are deploying first and figuring out the people side afterwards, if at all.

The same research found that 43% of firms report staff using AI only when required, not reaching for it proactively, and 40% report staff feeling overwhelmed by the pace of AI-driven change. Firms identified entry-level roles as most exposed to disruption, at 30%, ahead of middle management at 26%. That's exactly the kind of signal that makes a longer-tenured member of staff quietly conclude the smart move is to hang back rather than lean in. Nobody has to say it out loud for that anxiety to shape behaviour.

Why this bites hard in financial services operations

In fund administration and asset management operations, an enormous amount of practical knowledge lives in people, not documents. The person who remembers why one investor's side letter has a bespoke clause. The person who knows the NAV process has a manual override that exists for a reason nobody's written down anywhere. That knowledge is exactly what a new system needs captured and fed in if it's going to handle exceptions properly.

And that's usually the same person least likely to be an early, confident adopter of the new tool. Not because they're resistant to change in some vague cultural sense, but because nobody designed the rollout with their working style, their pace, or their existing expertise in mind. So the firm ends up in an odd position: automating the process while simultaneously losing access to the very knowledge that made the old process work.

Closing the gap

None of this is inevitable. It just needs treating as a design problem rather than a training afterthought.

Training needs to be role specific, not one webinar for everyone. A fund accountant with fifteen years of institutional knowledge and an analyst two years into their career need genuinely different onboarding into the same system, even if the tool itself is identical.

Pair tech-fluent and process-fluent staff together during design and testing, not just at go-live. The person who knows every exception the process has ever thrown up should be in the room while the system is being built, not handed a finished product afterwards and asked to trust it.

Make exception handling something non-technical staff can actually review and correct. If only the most technically confident people on the team can fix what the system gets wrong, you've built the divide into the architecture itself.

And track adoption properly, by tenure and by role, not just as one aggregate number. An overall adoption rate of 80% can easily hide a split where one group is at 98% and another is at 45%. You won't see that split unless you're looking for it specifically.

Getting this fixed

There's a pattern worth naming here. The "embed" stage of a build engagement, documentation, training, handover, tends to get treated as a formality once the interesting technical work is done. It's actually the opposite. It's where a two-tier team gets prevented, or quietly created, depending on how much care goes into it.

And it doesn't stop at go-live. A maintenance contract, ongoing support and tuning after the initial build, is what keeps that gap from creeping back open over the months that follow, as the system evolves and new edge cases turn up that only the experienced staff would recognise in the first place.

The real measure of success

The success metric for an automation rollout shouldn't just be "did we automate the process". It should be "can everyone who needs to use this, actually use it, confidently, six months from now". Those are two very different questions, and only one of them shows up on the adoption dashboard by default.