Most people who have worked on a large technology program have seen a version of this. The platform goes live, the steering committee celebrates, and a few months later the usage reports show that the people it was built for still aren't really using it. Claims handlers still have their own trackers open, underwriters are still working submissions out of their inbox, and the old process is carrying on alongside the new one.
The usual response is to focus more on training and communication: refresher sessions, updated guides, a network of champions, and a note from a senior sponsor saying the new system is mandatory. Sometimes that's enough. Quite often it doesn't change much, because the problem was never that people didn't know how to use the system.
In a lot of cases, they know exactly how it works, and the issue is the design of the new system itself. Every field, control and approval made sense to the people who designed it, and on paper the process looks fine. What it often hasn't had is real input from the people who do the work every day, so a task that took three screens in the old system takes seventeen in the new one, most of them asking for information the business already holds somewhere else.
Financial services can be unforgiving when it comes to things like this because almost everyone is measured on throughput, whether that's claims closed, quotes turned around or customers served. A claims handler working through a queue of motor claims, or an underwriter trying to get a quote back to a broker before a competitor does, isn't going to accept extra steps for the sake of cleaner executive dashboards. If a new system adds a few minutes to a task someone does dozens of times a day, many of them will keep their spreadsheets and workarounds, and it's hard to blame them.
Those workarounds are worth paying attention to, though. Picture a bank where a pilot uncovers loan officers in several branches who have stopped using the official lending data and built their own spreadsheets to track local conditions the system never captures, like which employers are expanding and which neighborhoods are appreciating. It's a risk and it's invisible to IT, so the standard response would be to shut it down. The better response is to work out what value the spreadsheets are adding to the user and move it into the platform. Those loan officers have found a better way to do their jobs where the official tools fall short, and in doing so they've already done the requirements gathering for you, you just need to listen.
Many of the programs that get adoption right start the same way. Someone watches the work before anyone designs a screen. That means sitting with an underwriter while they work through a submission, or with a claims team while they triage the morning's notifications, rather than asking them to describe the process in a workshop, where people tend to describe how it's supposed to work rather than how it actually does. From there, every field, approval and handoff in the new design has to justify the time it costs the person doing it.
AI can help here, but only if it's pointed at the right problem. Imagine a loan officer who spends twenty minutes pulling documents from three systems before every client meeting, or a branch manager who loses her lunch break to a scheduling spreadsheet because the HR system can't handle shift patterns. What both of them want is the time back. Insurance operations are full of the same work, like pulling details out of broker submissions, reading through claim files or checking documents against policy wording. When agents take that on inside the workflow, the system starts saving people time instead of costing it, and that is often when behavior changes.
The industry isn't there yet. ServiceNow and NVIDIA's Enterprise AI Maturity Index for Insurance found that 61% of insurers are using agentic AI, but only 8% have made significant progress building autonomous, multi-step workflows with it. Part of that gap is likely the same design problem, because putting an AI assistant on top of a poorly designed process often just gives people one more thing to ignore.
For leaders, the shift is to treat adoption as something you design for before go-live rather than chase afterwards. Has anyone timed the task for the people doing it, in the old process and the new one? Which steps exist for the user, and which exist because someone downstream wants the data? Where are people keeping their own trackers today? Those answers are far easier to act on during design than in a steering committee meeting six months later. After go-live, look past logins and license usage to cycle times and net promoter score amongst the actual users.
Training and change management still matters, because people need to understand what's changing and why, and sometimes a gap in skills or communication really is what's holding adoption back. It works best when it's introducing people to a better way of working, and much less well when it's making up for a design that costs them time. When people aren't using what has been built, it's worth asking why rather than just assuming they don't understand.
.svg){kind=icon}
