Go-live is done. The implementation partner has handed over the keys. External consultants have returned to their own offices. And somewhere in your organisation, around twenty employees were designated as key users throughout the project — they participated in UAT, they were the first to be trained. These people are now supposed to be the ERP relay within their departments.
Supposed to be. Because in the vast majority of deployments, this key user network has never been the subject of a structured programme. No formalised mission, no allocated time, no governance, no recognition. Six months after go-live, key users are still answering their colleagues’ questions — but out of implicit obligation, without a framework, and often with the feeling that they are carrying an extra role on top of their normal job.
This guide explains how to turn that informal network into an operational ERP super-user programme, from initial selection through to sustained long-term engagement.
Why the Post-Go-Live Key User Network Is the Cornerstone of Your ROI
The Classic ERP Support Model Does Not Hold Up Over Time
During the hypercare phase (the four to eight weeks following go-live), the project team and implementation partner are still mobilised. Questions flood in, corrections are made, and users adapt. The level of support is high.
Then the hypercare budget runs out. The project team moves on to other things. And the support model shrinks back to what existed before: IT for technical incidents, and nothing else for business questions.
That is where the gap opens. Business questions about the ERP — how do I enter a credit note? why is my purchase order on hold? how do I generate this report? — are not technical support issues. They require cross-functional expertise, both domain knowledge and ERP functional knowledge, that only well-trained super-users can provide.
Without that relay, users do one of two things: they find workarounds, or they abandon advanced features and fall back on their old habits. Both scenarios erode the ROI of the project.
A Super-User Is Not an IT Expert — They Are a Business Expert Who Knows the ERP
The most common mistake is treating the super-user as a mini-systems administrator. That is not their role. A super-user is above all a domain expert within their department, respected by their peers, who has developed advanced functional knowledge of the ERP modules covering their scope.
This distinction is fundamental for selection, training, and network governance. A super-user in finance knows how to configure reconciliation rules in their ERP — not how to deploy server updates. A super-user in logistics masters the stock management rules in the WMS module — not database access rights.
How Many Super-Users Do You Need?
There is no universal ratio, but a practical sizing rule is: one super-user for every ten to fifteen regular users within the same functional scope. An organisation with 150 ERP users spread across five distinct modules will need a minimum network of ten to fifteen super-users.
The figure of twenty-five key users is typical of mid-sized deployments — between two hundred and four hundred users — with multi-module coverage (finance, procurement, logistics, sales, HR). This is a common order of magnitude for organisations of three hundred to six hundred employees migrating to an integrated ERP.
Two sizing mistakes to avoid:
- A network that is too small: three or four key users for two hundred users — these individuals will quickly burn out under the volume of incoming requests.
- A network that is too large: beyond thirty super-users, coordination becomes a project in itself, response standards diverge, and governance becomes complicated. A network of fifteen well-equipped and well-supported super-users is more effective than forty left to fend for themselves.
Selection: The 5 Criteria That Make a Good Super-User
Selecting super-users is the most critical moment of the programme. A mistake at this stage compromises everything that follows.
Criterion 1: Business Legitimacy, Not Technology Curiosity
The “curious about technology” profile is tempting. This user is enthusiastic, asks questions, explores menus. But if they are not recognised by their peers as a domain expert, their opinion does not carry enough weight within their department to change working practices.
The super-user must be someone that colleagues naturally turn to when they have a process question — not just a tool question. Business legitimacy comes before ERP competence, not the other way round.
Criterion 2: Informal Influence, Measurable Without the Org Chart
In every department, there are people whose opinion carries authority regardless of their seniority. Identify them during design workshops: they are the ones who rephrase the implementation partner’s proposals, who challenge mockups, who say “that won’t work in our department because…”. These profiles are your natural candidates.
Avoid overly enthusiastic volunteers who applied out of personal curiosity without that natural influence — they will be overwhelmed and poorly followed.
Criterion 3: The Ability to Explain, Not Just to Do
A super-user who does things on behalf of users creates dependency. A super-user who explains and guides creates autonomy. The distinction is visible from the initial training phase: observe who restates concepts in their own words, who asks “why” the configuration was done this way rather than just “how”.
This criterion is hard to test in advance, but a twenty-minute interview with each candidate — asking them to explain one of their department’s processes to someone unfamiliar with it — is revealing.
Criterion 4: Part-Time Availability Negotiated With Management
The super-user is not full-time in this role, except during the go-live phase and major upgrades. But they need explicit part-time availability negotiated with their manager — in the range of ten to twenty per cent of their time during active phases.
If the manager does not commit to freeing up that time, the person will be physically present in the network but constantly under pressure between their normal job and network demands. They will burn out.
Formalise this commitment at recruitment: a short mission letter, signed by the manager and HR, that acknowledges the role and confirms the part-time allocation. This document protects the super-user and makes the contribution visible to senior management.
Criterion 5: Explicit Acceptance of the Role, Not a Designation
A super-user designated without their agreement quickly becomes a bottleneck. They do the minimum, answer questions perfunctorily, and resign from the network at the first opportunity.
Present the role transparently: the benefits (skills development, organisational visibility, priority access to vendor training), the constraints (part-time availability, support responsibility), and the duration (initial eighteen-month commitment, renewable). Allow candidates to decline.
Training: The Differentiated Training Programme
Super-user training is not an enriched end-user training programme. It is a distinct programme with distinct objectives.
Phase 1: In-Depth Functional Training (Before Go-Live)
During the UAT and deployment phase, super-users receive functional training that goes beyond simple screen navigation. They need to understand:
- The business rules configured in the ERP for their scope
- The reasons why certain options were configured as they were (and not otherwise)
- Edge cases: what happens if an order is placed against a blocked account? if a user enters an item outside the master data?
- Cross-module flows: how does a purchase order affect accounting? how is a partial delivery handled?
This training typically lasts three to five days per module, delivered by the implementation partner or directly by the vendor depending on the contract.
Phase 2: Train-the-Trainer
This is the phase most often neglected, and the most decisive. A super-user who knows how to do something is not automatically able to teach it. The pedagogical training for super-users covers:
- How to structure a fifteen-minute demonstration on a key process
- How to respond to a question without doing it for the user (open questions, progressive guidance)
- How to identify whether a user has a training problem or a configuration problem (two very different responses)
- How to escalate a functional issue to the IT team or implementation partner (with the information needed for resolution)
This training can be delivered internally if you have an existing L&D function, or via a specialist external provider. The duration is one to two days, but the impact on network quality is considerable.
Phase 3: Continuous Skills Development
After go-live, super-users continue to develop their knowledge. Two sources to integrate into your programme:
- Vendor training: most ERP vendors offer certification programmes or online learning paths for advanced users. SAP Learning Hub, Sage University, Odoo Learn, Microsoft Learn for Dynamics 365, Access Learning for Access Group products — these resources are often included in the maintenance contract or available at reduced rates for partners. Negotiate these access rights during the initial contract.
- Internal sessions: for every major update or configuration change, organise a network upskilling session before rolling the change out to end users.
Sustaining: Network Governance Over Time
Training super-users is a necessary condition, not a sufficient one. What distinguishes an active network from one that withers is governance and sustained animation.
The Monthly Meeting: Structure and Typical Agenda
A monthly super-user network meeting is the cornerstone of network management. It is not an operational working meeting — it is a coordination and collective upskilling session.
Typical agenda for ninety minutes:
- Round-table of recurring incidents (20 min): each super-user flags the two or three most frequent questions from their department that month. Common patterns are identified.
- Collective analysis of a complex case (25 min): one of the flagged cases is worked through as a group to build a standard response and documentation.
- Update on upcoming changes (20 min): version upgrades, planned configuration changes, new features to be rolled out.
- Best practice sharing (15 min): one super-user presents a tip or procedure they documented that month.
- Miscellaneous and escalations (10 min): matters requiring a decision the network cannot make on its own.
The Collaborative Knowledge Base
A super-user answers the same question thirty times a year. A documented knowledge base transforms those individual answers into collective capital.
The knowledge base does not need to be sophisticated: a shared space (SharePoint, Confluence, Notion, or even a well-structured Teams folder) with standardised process sheets. Each sheet covers a concrete use case, describes the procedure step by step with screenshots, and notes known edge cases.
Feeding this knowledge base must be part of the formalised super-user mission. One documented sheet per month per super-user is a reasonable target.
Internal Communication Channels
The super-user should not be the sole entry point for questions. A dedicated communication channel — a Teams channel “ERP Help”, a Slack workspace, or a request form if you have a service desk — allows requests to be handled more equitably, volumes to be measured, and the knowledge base to be fed.
This channel is not an IT support channel. It is managed by the super-user network, with a next-business-day response commitment for non-urgent questions.
The On-Call Arrangement
For organisations with strong operational constraints (continuous manufacturing, logistics with critical time windows), an on-call arrangement may be necessary: one super-user “on duty” each week, reachable as a priority for blocking incidents.
This arrangement is not for routine questions — it is for situations where a user is blocked on a critical process and cannot wait until the next day. It must be explicitly compensated (time off in lieu, a one-time benefit) to avoid resentment.
Measuring Programme Effectiveness
A super-user programme without metrics is a statement of intent. Here are the key indicators to track.
Network Activity Indicators
- Volume of requests handled by the network: number of questions received via the dedicated channel, by month, by super-user. An upward trend in the first three months is normal. A persistent rise after six months signals an end-user autonomy problem.
- First-contact resolution rate: what percentage of requests is resolved by the super-user without escalation to the implementation partner or IT? A rate below seventy per cent after six months indicates that initial training was insufficient on certain topics.
- Number of sheets documented: an indicator of contribution to the collective knowledge base. A network that does not document is a network at risk — if a super-user leaves the organisation, their knowledge goes with them.
Business Impact Indicators
- Adoption rate trend by department: measured monthly via login logs and module usage KPIs. A department with an active super-user should show higher adoption than an uncovered department.
- Average resolution time for business questions: before the programme, how long did it take to resolve a functional question? After six months of the programme, this time should have decreased significantly.
Network Health Indicators
- Attendance rate at monthly meetings: a rate below seventy-five per cent over three consecutive months is a warning signal. The network is disengaging.
- Super-user satisfaction level: an anonymous quarterly survey, five questions maximum. Measure their perceived workload, training level, and sense of recognition. This is the most predictive indicator of departure or disengagement risk.
Avoiding the 4 Mistakes That Derail Super-User Programmes
Mistake 1: Failing to Formalise the Mission and Time Allocation
A super-user without an official mission letter and time allocation negotiated with their manager burns out within six months. Line management eventually tells them to “stop wasting time on the ERP” as soon as operational pressure increases.
Mistake 2: Stopping Training After Go-Live
The ERP evolves. Parameters change. New users join. A super-user trained only during the initial deployment will be out of date within eighteen months. The continuous training programme is non-negotiable.
Mistake 3: Neglecting Recognition
The super-user role carries real constraints without automatic compensation in most organisations. Recognition levers available without salary increases: visibility within the organisation (presenting programme progress to leadership), priority access to vendor training, a mention in the skills assessment or annual review. These levers cost little and matter a great deal.
Mistake 4: Confusing Super-User With Functional Administrator
Some super-users, by virtue of their level of mastery, may be tempted — or pushed — to take on functional administration tasks: creating users, modifying access rights, adjusting parameters. This role drift is dangerous. Functional administration requires process rigour and traceability that falls outside the super-user network and belongs to structured IT governance.
Separate the two roles clearly from the outset, and document what the super-user can and cannot do in your ERP environment.
Embedding the Programme Into the ERP Lifecycle
A super-user programme is not a project with an end date. It is a permanent arrangement that must evolve with the organisation and with the tool.
Three events require a programme review:
- A major version upgrade: bring the entire network up to speed before deployment, review knowledge base sheets.
- Significant turnover: if you lose more than thirty per cent of the network within twelve months (departures, internal transfers), rebuilding collective competence takes six to eight months. Anticipate with a succession plan: each super-user identifies their “training partner” in their department.
- A scope extension: deployment of a new module or a new subsidiary. Existing super-users cannot absorb an enlarged scope without additional training and resources.
The annual programme review, led by the IT manager or CIO with the participation of department managers, is the opportunity to validate these changes and make the necessary reinforcement decisions.
To go deeper on methodology and tools, our practical ERP change management guide covers ADKAR and Prosci models, resistance management, and the communication matrix. For adoption tracking in the twelve months following go-live, see our article on the 8 ERP adoption KPIs to measure post-go-live to identify silent rejection before it takes hold.
