Increase NetSuite user adoption with expert strategies for engagement, training, and support—empower your team and maximize your NetSuite investment.
User adoption is the part of an ERP project that is universally acknowledged as important and almost never resourced accordingly. It gets a line in the plan, a communications email and a block of training in the final fortnight, and then people are surprised when six months later half the business is working around the system.
The uncomfortable truth is that adoption is not a phase. It is the accumulated result of decisions made throughout the project, most of which are made without anybody thinking about adoption at all.
This article covers what actually drives adoption, what to do before, during and after implementation, and how to tell whether it is working.
Resistance gets treated as an attitude problem to be managed. It is more usefully treated as information.
Somebody who avoids the new system is usually making a rational trade off. The old way is faster for them, or the new way loses something they needed, or nobody explained why the change was worth their discomfort.
Occasionally the resistance is about status or control, and even then it is worth understanding rather than overriding, because the person concerned usually has influence over others.
The practical move is to ask rather than to push. What is harder now than it was. What did you used to be able to do that you cannot. About half the time the answer reveals a genuine gap, and the other half it reveals something the system does that nobody showed them.
The single largest determinant of adoption is whether the system fits how the work actually happens, and that is settled long before training.
A design produced by asking managers what the process is will describe the process as it is supposed to work. The people doing it daily know the exceptions, the workarounds and the reasons behind them.
Where those people are involved in design, the system accommodates reality and adoption follows almost automatically. Where they are not, the system encodes an idealised process and everybody works around it from week one.
Involving them is not a consultation exercise. It means having them in design sessions, having them react to working configuration, and changing things when they say something will not work.
Change communication usually stays general, and general reasons do not motivate anybody.
Better visibility for the business does not answer the only question the person in front of you is actually asking, which is what this means for me.
The honest answer varies by role and it is worth working out per role. For some people the new system genuinely makes their job easier and you should say exactly how. For others it makes their job slightly harder while making somebody else's considerably easier, and pretending otherwise destroys credibility.
People accept a change that costs them something when the reason is explained and the trade off is acknowledged. They do not accept being told that something is better when their direct experience says it is not.
Every team has people whose opinion carries disproportionate weight, and they are frequently not the managers.
They are usually the long tenured, competent people that everybody asks when they are unsure. If they are sceptical, the team is sceptical. If they are on board, resistance largely evaporates.
Find them early and engage them properly. Not by telling them the project is happening, but by involving them in design and taking their objections seriously enough to change something.
Where an influential person stays opposed after genuine engagement, that is worth understanding rather than ignoring, because they are usually opposed for a reason that will affect everybody else too.
Training organised by module is a description of software. Training organised by process is a description of somebody's job.
A supplier invoice arriving in the inbox has a path through the system, crossing several parts of it, and that path is one job. Training built that way is immediately usable because it maps onto something the person already recognises.
Cover the exceptions, since standard training covers the happy path and real work is mostly exceptions. The moment somebody meets an exception they were not shown, they revert to the old method.
And time it against first use. Month end training delivered three weeks before the first month end is forgotten by the time it matters. Our training service is built around this.
The period immediately after go live sets the attitude that persists, and it is routinely under supported.
People need help within minutes rather than within days. A question that goes unanswered for two days is a question that gets solved with a workaround, and that workaround becomes permanent.
Floor walking, meaning experienced people physically or virtually available in the working area, is disproportionately effective in the first fortnight. It catches the questions people would not raise formally.
Expect a productivity dip and say so in advance. Where people are told to expect it, the dip is normal. Where they are not, it reads as evidence the system does not work.
Where the old way remains available, a meaningful proportion of people will keep using it, and the two systems will diverge.
Switch off legacy systems on a defined date rather than leaving them accessible indefinitely. Read only access for historical reference is fine. Continued transacting is not.
Retire the spreadsheets that the system was supposed to replace, which requires knowing they exist, which requires asking.
Do this deliberately and with notice rather than abruptly, since abrupt removal of a tool somebody depends on creates the resistance you were trying to avoid.
And be honest where the system genuinely does not yet do something. Removing the alternative before the replacement works produces justified anger.
Nothing builds adoption faster than a demonstrated willingness to change the system when somebody raises a genuine problem.
The first few weeks generate a stream of issues, and how they are handled determines whether people keep raising them or stop bothering.
Triage quickly, distinguish configuration problems from training gaps, and communicate what is being done even where the answer is that it will not be changed and here is why.
Where something is fixed, say so publicly and credit the person who raised it. That single behaviour converts more sceptics than any amount of communication.
Satisfaction surveys measure how people felt about a session. Adoption is about what they do afterwards.
Manual journal volume is a useful proxy, since each recurring one usually indicates a process people cannot complete as designed.
Spreadsheet exports indicate reporting that either does not exist or is not trusted, and both are actionable.
Approval bypass or rubber stamping indicates a design that does not match how decisions actually get made.
Support question topics, clustered, tell you exactly which process needs attention, which is far more useful than an average score.
Visible resistance is easy to see and comparatively easy to address. The bigger risk is the person who says nothing and quietly does not change.
They usually surface through data rather than through conversation. Transactions still arriving by email. A team whose usage is materially lower than comparable teams. Reports still being produced from the old extract.
The reason is frequently not opposition. It is that they never got the training, or they missed the session, or they asked once and did not get a useful answer.
Looking for them actively, rather than waiting for them to raise a hand, is worth doing at the three month mark and again at six.
People who touch the system rarely are a distinct problem and they are usually treated as a smaller version of daily users.
Somebody submitting an expense claim monthly has forgotten how by the time they do it again, and their experience of the system is entirely defined by that one interaction.
They need the simplest possible path, a short reference guide available at the point of need, and no exposure to anything irrelevant to their task.
Where this is done badly, the occasional user population becomes the largest source of frustration and of bad word of mouth about the system, disproportionate to how little they use it.
Treating the organisation as one audience misses that different functions experience the same implementation very differently.
Finance usually adopts fastest, because the system was largely designed around their processes and because the benefit to them is direct and immediate.
Operations frequently adopts slowest, because they are asked to enter more data than they previously did, and the benefit of that data accrues to somebody else. That is a genuine imbalance and pretending otherwise does not help.
Sales adopts unevenly, since the value depends on whether the system makes their job easier or simply records what they did.
The practical response is to look for the functions where effort and benefit are mismatched, and to either reduce the effort through better configuration or make the benefit visible to them specifically.
Adoption is not won once. It degrades through turnover, process change and the twice yearly release cycle.
New starters need structured onboarding rather than sitting next to somebody, because informal transfer propagates workarounds faster than correct method.
Process changes need their own training, delivered to the people affected, rather than an email.
Releases need somebody to read the notes and tell people what changed in the areas they use.
And a periodic check against the behavioural measures above catches drift while it is still cheap to correct. Our piece on post implementation strategy covers the wider rhythm.
Executive sponsorship is invoked constantly and rarely defined, which makes it easy to claim and hard to deliver.
In practice it means three specific things. Using the system themselves where their role involves it, because leaders who exempt themselves communicate that it is optional. Protecting the time their people need for design and training, rather than leaving them to find it. And being visible when something goes wrong, rather than only when it goes well.
It also means resolving the process decisions that only leadership can resolve. A great deal of apparent resistance is actually people improvising because nobody decided how the process should work.
Plenty of businesses arrive at this question after the fact, with a system that works and a workforce that does not trust it.
Start by finding out what people actually do, which usually differs from the documented process. The workarounds are the map.
Then classify honestly. What is a configuration gap, what is a training gap, what is a process decision nobody made, and what is a data quality problem. Each needs a different response and conflating them wastes effort in every direction.
Fix the configuration gaps first, because credibility depends on it. Retraining people on a system that genuinely does not do what they need makes things worse.
Then retrain around the real processes, being explicit about what is changing and why. Our implementation rescue service exists for the more serious cases.
Adoption is mostly the accumulated result of small decisions about who was involved, what was explained, how training was built and how quickly problems were fixed.
If you are planning an implementation, the highest value adoption investment is involving the people who do the work in design, which costs nothing beyond their time and changes the outcome more than any communication plan.
If you are already live and struggling, start by cataloguing the workarounds, because each one is a specific, fixable problem rather than a general attitude.
Our pieces on improving ERP user adoption and the adoption communication plan cover specific tactics.
If you would like help with adoption in your own business, get in touch.
