Last updated: August 31, 2026
ERP user adoption is won in the ninety days after go-live, by putting a named owner on every process, training people on the transactions their job actually needs, and measuring how much work gets fixed after it is entered. The software is finished on day one. The habits are not.
On a regulated project, a quality auditor will eventually ask a question that sounds boring and is not. Show me who was trained, on what, and when.
There is an answer. It is a record with names and dates on it, retained, and available to that auditor on request. Somebody signed it. Our own change control procedure says personnel are trained on a process before doing work under it, and the training is recorded with date and trainee. Not a vibe. A row in a table.
Now ask the same question at a mid-market company six weeks after an ERP go-live. You get a calendar invite from March, a recording with four views, and a very confident statement that everybody was trained. Same question. Completely different quality of answer.
That gap is the whole subject of this post, and it has almost nothing to do with software.
Read the next part knowing who wrote it. I run an ERP and business systems consulting group, which means companies who conclude their rollout needs adult supervision tend to end up on my calendar. You are also reading this on a staffing firm’s site, and KORE1 places the administrators, analysts, and superuser leads who own these systems after people like me hand over the keys. Two angles, both obvious, discount accordingly. The offset is that most of what follows costs you attention rather than money, and I will point out the parts where hiring is the wrong answer.
If you want the version of this argument that happens before cutover, the NetSuite optimization playbook is the parent piece and this is what comes after it.
Trained, and Still Not Using It
ERP user adoption is the point at which the people who do the work enter it in the system, in the moment it happens, without a parallel spreadsheet running alongside. Training is a prerequisite for that. It is not the same thing, and most implementation plans stop at the prerequisite and call it done.
Trained is past tense. It describes an event that happened to somebody. Using is present tense and it happens roughly four hundred times a week, in circumstances nobody rehearsed, usually while the person is also on the phone.
The distance between those two is where ERP projects quietly go to die, and the failure is polite. Nothing crashes. Nobody files a complaint. The month-end close just takes eleven days instead of five, and a controller starts spending her Fridays reconciling two versions of the same number, and eighteen months later somebody in a board meeting asks why the system nobody likes cost what it cost.
I have watched a company go live cleanly, on schedule, on budget, with a genuinely well-built configuration, and still get almost nothing out of it for a year. Nothing malfunctioned. The people just kept working the way they worked before, because nobody had made that harder than the new way.
Read Your Own Statement of Work. Training Is Probably Not in It.
Here is the uncomfortable part. Adoption is usually excluded from the contract that was supposed to deliver it.
I write these documents. I wrote one this year. Six figures, a regulated manufacturer, priced across discovery, build, validation, and release. Page seventeen, exclusions, item eleven: end-user training delivery and periodic review, outside the ongoing retainer. Excluded, in writing, by me. It is not a trick. It is honest scoping, and every competent partner does the same thing, because training your staff on their own business process is work only your staff can do.
Read the exclusions before you read the price. Most people do the reverse.
| Usually excluded from the implementation quote | Who actually has to do it | What it looks like when nobody does |
|---|---|---|
| End-user training delivery, and the refresh six months later | You, or a retained service you pay for separately | One recorded session, watched by the people who already knew |
| Authorship of your own SOPs and work instructions | You. A good partner hands you templates and helps, but the records are yours | Process knowledge lives in one person’s head and takes vacations |
| Business subject matter experts for workshops and user acceptance testing | You, on top of their day jobs | The system gets tested by the people who built it, which tests nothing |
| Cleaning up data problems discovery found but did not cause | You, scoped and priced separately | Users stop trusting a report in week three and never start again |
| Keeping the thing current through vendor release cycles | You, internally, or a retainer | A configuration that was right in February and nobody has looked at since |
None of that is a partner behaving badly. It is a boundary, written down, and boundaries are the most useful thing in any consulting document. The mistake is reading the exclusions as a list of things that do not need to happen, when it is actually a list of things that are now your problem, with no line item and no budget attached.
The cheapest bid on your desk is usually the one that excluded the most. That work does not evaporate because nobody priced it. It shows up in October, with no owner and no budget line, and by then it is an operating problem rather than a project one.
Every Process Needs a Name Next to It
Ask four questions about any process that runs in your ERP. Not the software. The process.
- Who approves a change to how this works?
- Who answers a user’s question about it at four o’clock on a Tuesday?
- Who is accountable for the number the report produces, by name, out loud, in a meeting?
- Who decides when a workaround has become a requirement?
If any of those answers is a department, a committee, or the word “IT”, you do not have an owner. You have a distribution list. Different thing.
The support side of this is worth writing down with the same seriousness a vendor writes it down. When I put a support commitment in front of a client it looks like the table below, and the thing that makes it real is that severity is assigned by the client at the point of raising, not by us.
| Severity | What it means | Response commitment |
|---|---|---|
| 1 | Data flow stopped, or an obligation the business cannot meet | 2 business hours, then continuous until it is resolved or worked around |
| 2 | Degraded, a workaround exists, nothing is immediately at risk | 1 business day, scheduled and communicated |
| 3 | Minor defect, a question, or a change request | 3 business days, scheduled by agreement |
Copy that internally. Seriously, copy it. Your users do not need a service desk product. They need to know that a question asked on Tuesday gets an answer before Friday, and that a stopped process gets somebody inside two hours. Certainty about the response matters more than the speed of it.
One rule I will not bend on. Escalation goes to a person, not to a shared inbox. An escalation path that terminates in a queue is not an escalation path. It is a place where urgency goes to cool off, and every user learns that within about two weeks.
Six Numbers That Tell You Before Your Users Do
Users are unreliable narrators about adoption. They will tell you the system is fine while quietly rebuilding half of it in Excel, partly out of politeness and partly because the workaround feels like their own competence rather than a defect. So measure instead.
These are the ones I actually pull. None of them requires a new tool.
| Signal | Where to get it | What should worry you |
|---|---|---|
| Days to close | Your controller already tracks it | Month four is not better than month two |
| Manual journal entries per close | General ledger, counted by source | Flat or rising after the first two closes |
| Correction rate | Transactions edited or reversed within 48 hours of entry | Anything above roughly one in ten, sustained |
| Lag from event to record | Compare a physical timestamp to the posting date | Anything measured in days for a same-day activity |
| Active licensed users | Login and usage logs, weekly | Paying for seats that open the system once a month |
| Question concentration | Where support requests originate, by team | One department generating most of them, four months in |
Direction beats absolute value on every one of these. A correction rate of twelve percent that fell from thirty is a system being learned. A correction rate of six percent that has not moved since June is a process people have decided to work around, permanently, and it will still be six percent in two years.
Question concentration is the one people misread. When most of your tickets come from one team, the instinct is to conclude that team is struggling. Sometimes. More often that team is the only one still bothering to ask, and the quiet departments have given up and gone back to the spreadsheet. Silence is not adoption.
Your ERP Changes Twice a Year Whether You Are Ready or Not
This is the part that surprises people who thought go-live was the end of something.
Oracle ships two scheduled NetSuite version upgrades a year, with additional enhancements arriving in monthly minor releases in between. SAP, Dynamics 365, and Sage Intacct all run their own version of the same cadence. Your training material was accurate the week it was recorded. By the second upgrade, some of it is describing a screen that no longer exists, and the person watching it concludes the whole library is out of date, which is a very reasonable conclusion for them to draw.
So adoption is not a project with an end date. It is a maintenance obligation, and somebody has to do it twice a year: read the release preview, work out what changed in the twelve processes you actually care about, retest them, and update the two pages of documentation that describe them. That is not a heroic amount of work. It is about a week, twice a year, and it is almost never assigned to anyone.
Skip it and nothing breaks on the day. The system stays up. It just drifts away from the documentation and the training until the two have no relationship, and at that point the only real process documentation you own is whatever your longest-serving user remembers.
A Ninety-Day Plan That Fits on One Page
Hypercare, in the projects I price, is about three weeks sitting inside a four-week release phase. Three weeks. That is the window where your partner is still standing next to the system, and it is nowhere near ninety days, which is roughly how long adoption takes to set.
What I would do with those ninety days, in order.
Days 1 to 14. Name the owners. One page, two columns: process, and a human being. Order to cash, procure to pay, inventory adjustments, month-end close, master data. If two names appear next to the same process, you have a fight to resolve now rather than in December.
Days 10 to 30. Rebuild training around the job, not the software. The go-live training covered the system. This covers the seven things a warehouse lead does every day, in order, with the exceptions that actually happen. Fifteen minutes per role, filmed on somebody’s laptop, beats a forty-page manual nobody opens. Make it ugly and make it current.
Days 14 to 30. Publish the escalation path. Names, response commitments, and what counts as a severity one. Put it on the wall. Yes, physically, in the warehouse.
Days 30 to 60. Pull the six numbers and find the load-bearing workaround. Every implementation grows one, usually a spreadsheet that has quietly become the source of truth for something. Find it. Then decide whether to kill it or to build what it does properly, because the third option, pretending it does not exist, is the one most companies pick.
Days 60 to 90. Turn requests into change control. Every change gets recorded before work starts, with the reason it was classified the way it was, and gets reviewed by somebody other than the person who made it. That is lifted almost verbatim from our own procedure and it works for a fifteen-person finance team exactly as well as it works in a validated environment. No direct changes in production outside that process. None.
Ninety days after go-live you either have a system with owners, a current training set, a published escalation path, and a change process, or you have software.
Adoption gets harder when the feature list keeps moving underneath it. Knowing what the AI in your ERP can actually do today keeps your training set honest, because you cannot train people on a roadmap entry.
Nobody Owns It Because Nobody Was Hired to Own It
Here is where I stop being able to pretend this is free.
The regulated world settled this decades ago and the language is blunt about it. Under the FDA’s electronic records rule, 21 CFR 11.10(i) requires a “determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.” The FDA’s own Part 11 guidance repeats it. Read that as a hiring specification rather than a compliance sentence and it says something obvious that mid-market companies keep discovering the expensive way. Competence to run the system is something you are responsible for establishing. Not assuming.
In practice that is one to three seats, and which ones depends on what broke.
- An administrator who owns configuration, permissions, and the release cycle. This is the seat most companies skip and then backfill in month nine at a premium.
- A business analyst who translates “the report is wrong” into a testable statement, which is most of the job.
- A superuser program lead, usually part time and usually already on your payroll, whose real job is making sure every department has somebody to ask.
- An instructional designer for a defined stretch, if your training material genuinely is the problem. That one is a contract, not a hire.
Two of those are permanent and two are not, which is the entire reason to think about contract staffing for the adoption phase specifically. You need a lot of help for a hundred days and much less after that. KORE1 fills IT roles in about 17 days on average and holds 92% twelve-month retention on placements, which matters more here than it sounds like it should, because an adoption owner who leaves at month seven resets the clock on everything above. They staff this across 30-plus U.S. metros, and the bench is not just a coastal thing. Salt Lake City, Dallas, and Phoenix all run deeper NetSuite and Dynamics talent pools than people expect.
If you want the roles and rates rather than the argument, KORE1’s ERP user adoption and training staffing page covers who to hire and what they cost, and the go-live and hypercare staffing page covers the four weeks before this post starts. If you are earlier than that and still moving records, clean data migration is the piece that decides whether anybody trusts a report in month two.
When hiring is the wrong answer. If you have not named owners yet, do not hire anyone. A new administrator dropped into an organization with no process owners becomes the person everybody asks, permanently, and you have converted a governance problem into a retention problem. Name owners first. It is free and it takes an afternoon.
Push Back on Me Here
We are six weeks in and it feels bad. Is that normal?
Six weeks in feeling bad is normal. Six weeks in with a close that takes longer than it did on the old system is not, and that is the specific signal worth escalating. Complaints are noise at this stage. Reconciliation time is signal, and so is anybody quietly rebuilding a report in Excel.
Do we need a change management consultant, or can I cut that line?
You can cut it. What you cannot cut is the work, which is naming owners, rewriting training around real jobs, and publishing an escalation path. If you have an operations leader with credibility on the floor and eight hours a week, they will do it better than an outsider, because adoption runs on relationships the outsider does not have.
Our users say the system is slow. Is that adoption or is that the system?
Usually neither, in my experience. “Slow” is what people say when a task takes eleven clicks and used to take three, which is a configuration and role-permission problem rather than a performance one. Sit behind one user for an hour and count the clicks. You will know inside twenty minutes.
Can we just hire a trainer for a month?
A trainer for a month fixes a training problem, and maybe a third of the time that genuinely is the problem. The rest of the time the training was fine and the process has no owner, in which case you will run the sessions, get a nice completion report, and watch the same behavior resume in three weeks.
The CFO wants adoption on a dashboard. What goes on it?
Four things: days to close, manual journal entries per close, correction rate, and active licensed users. Trend lines, not point values, and never a training completion percentage. Completion percentages measure attendance. Attendance is not what you are buying.
We went live badly. Do we start over?
Almost never. Re-implementation is the most expensive way to solve a problem that is usually about ownership, and I have seen exactly one case where the configuration was genuinely unrecoverable. Spend ninety days on owners, training, and measurement first. If the numbers still have not moved, then have the harder conversation.
Who should own the ERP once the project team disbands?
Operations owns the processes, finance owns the chart of accounts and the close, and one named administrator owns configuration and the release cycle. IT owns access and infrastructure and should not own how the business runs. That split fails only when nobody is told about it, which is most of the time.
The System Was Never the Complicated Part
I have said a version of this on LinkedIn enough times that people send it back to me. ERP is not complicated. Your people are. Harsher than I mean it. The software behaves exactly as configured, every time. The humans around it are carrying twenty years of habits, a well-earned suspicion that this is the third system somebody promised would fix everything, and a job that still has to get done today regardless of what got installed last month.
The tech is the easy half. It sucks that this is true, because the easy half is the half everybody budgets for.
Go do one thing this week. Print your process list, put a human name next to each line, and see how many blanks you have. The blanks are your adoption plan. That exercise costs nothing and it has never once come back empty.
If it comes back mostly blank and the person who should own this does not work here yet, talk to a KORE1 recruiter about the seat, or hit me up on LinkedIn and I will tell you honestly whether you need to hire anybody at all. Either way, put the names on the page first. The hiring conversation gets a lot shorter once you know which line is blank.
