In 20+ years of ERP work, I have seen budgets survive bad code, missed deadlines and angry steering committees. What no rollout survives is a weak super-user network. Get those people wrong and your go-live becomes a help-desk on fire.
Everyone talks about the system. Almost nobody plans the humans who make the system usable on Monday morning. That is backwards. So let me be blunt about what actually works.
What a super-user really is
A super-user is not "the person from Finance who is good with computers." A super-user is a respected operator who does the real job, understands the end-to-end process, and is trusted by peers to give an answer people will accept.
The last part matters most. Adoption is social. When a warehouse team hesitates, they do not open the manual. They turn to the colleague they already trust. If that colleague endorses the new process, you win. If not, no amount of training material saves you.
The ratios I use
Numbers force discipline, so here are mine, refined across multiple SAP and ERP programs:
- 1 super-user per 15–20 end-users. Below that you overload them; above that they lose reach.
- At least 2 per critical process (order-to-cash, procure-to-pay, record-to-report). One is a single point of failure. People take holidays and quit.
- 20% protected time during the project, ramping to 50% in the go-live window. If their day job stays at 100%, the role is fiction.
On one deployment we ran 900 users with 48 super-users. It held because the ratio was real and defended by management. On a smaller site we tried to save money with a 1:40 ratio. Ticket volume in week one was roughly triple the covered site. We paid the difference back in overtime and frustration.
Select for trust, not for tenure
The instinct is to nominate whoever is available, or the most senior person. Both are traps. The best super-users are often mid-career people with strong informal influence.
My selection filter is short:
- Do peers already ask them for help today?
- Do they know the process, not just the transactions?
- Can they explain something without making the listener feel stupid?
- Do they actually want it? A drafted super-user is a passenger.
Pick the person the team already trusts, then give them the tool. Never pick the person who knows the tool and hope the team learns to trust them.
Train them to teach, not to click
Standard training teaches steps. Super-user training must go one level deeper: the why behind the process, the common mistakes, and how to explain a fix in plain language.
What has consistently worked for me:
- Bring them in during design and testing, not two weeks before go-live. If they help build it, they defend it.
- Make them run UAT and the end-user training themselves. Teaching is the real exam.
- Give them the escalation map: what they solve, what goes to IT, what goes to the process owner. Ambiguity here kills response time.
Day one: put them on the floor, not in a room
The single highest-leverage decision at go-live is where your super-users physically are. Not in a war room. On the floor, at the desks, beside the people doing live transactions.
This is the "hypercare" period, and it is won or lost in the first two weeks. My rule: a user should reach a human in under two minutes, without logging a ticket, for the whole first week. Most go-live pain is not bugs. It is small hesitations that snowball into workarounds. A super-user at the next desk kills that in thirty seconds.
Track it. We log super-user interventions daily. When floor questions drop below a threshold two weeks running, hypercare ends. Data decides, not the calendar.
Empower them, or lose them
Empowerment is concrete, not a slogan. Super-users need a direct line to the project team, the authority to say "this process is broken," and visible air cover when they escalate. If their feedback disappears into a backlog, they stop giving it, and you go blind.
Retention is the part almost everyone forgets. You just built your most valuable change asset. Then the project ends and they quietly go back to their old jobs, unrecognized. Next upgrade, you start from zero.
What keeps them:
- Formal recognition in their objectives and appraisal, in writing.
- A standing super-user community that meets after go-live, not just during it.
- First access to new features and a real voice in the roadmap.
- A visible path. Super-users become process owners, product owners, transformation leads. I have watched it happen more than once.
The bottom line
ERP programs are sold as technology projects. They succeed or fail as human networks. The super-user layer is the cheapest, highest-return investment in the entire budget, and the first one that gets cut when money is tight.
Do not cut it. Select for trust. Fund the time. Put them on the floor on day one. Keep them long after go-live. Do that, and the system everyone worried about becomes the thing nobody talks about, because it simply works.
Cédric Bignet is an AI & ERP Change Management expert at Novartis and founder of AInspire. He writes about change management, AI adoption and enterprise transformation.