Every ERP implementation has a few of them, and yet almost everyone who gets the role first looks up what it actually is: the key user. The short answer: the employee who represents their department during the implementation - they know the process, co-decide on the configuration, test the system and later train their colleagues. The long answer is more interesting, because this role makes or breaks your project. This is what a key user does, how much time it takes, how the role differs from project lead and application management, and how to pick the right people.
The definition, and why the role exists
A key user is an ordinary employee with a temporary extra role: during an ERP or software implementation, they are the voice of their department or process. Sales, purchasing, warehouse, accounting - each core process ideally has one.
Why does the role exist? Because an implementation partner can configure your system, but does not know your company. The consultant knows what Odoo can do; the key user knows how things really work at your company - including the exceptions that appear in no process description. Without that knowledge, a system gets configured for how the work should run, and that is rarely how it runs. The key user is the bridge: they translate daily practice into configuration choices, and later the new system back to their colleagues.
The four tasks, and the fifth that comes with them
In practice the role comes down to four things, in the order of the project.
Explaining the process. At the start - in our case in the fit-gap analysis - the key user explains how their process works. Not the paper version, but the real one: where the exceptions sit, which steps quietly happen in Excel, what goes wrong when someone is ill. The more honest this story, the better the scoping table that follows from it.
Co-deciding on the configuration. Which fields are mandatory, which statuses does an order have, is that one exception worth configuring or do we abolish it? These are not IT questions but process questions, and the key user is the one who can answer them.
Testing with real cases. Not clicking through the happy flow, but rebuilding last month’s difficult order. The best key users test with a list of real practical cases - every mistake they catch does not go live.
Training colleagues. Around go-live, the key user trains their own team, in the language of their own work. That works better than a generic external training: the explanation is about your orders, your customers, your exceptions. In our TARGET method this is a step of its own - training end users on their own work, not on the system in general.
And then the fifth, which often goes unagreed: after go-live, the key user is the first point of contact. Small questions they resolve themselves; real problems they escalate. Agreeing this up front prevents the partner’s helpdesk from filling up in the first weeks with questions that could have been answered internally in thirty seconds.
How much time does it really take?
More than most companies budget. In the busy phases, count on half a day to a full day per week per key user, with peaks around testing and go-live. And here is the point we bring back in every timeline estimate: that time is not a cost item but the biggest accelerator of the project. Decisions that sit for days because nobody has time are the quietest delayer of every implementation.
The pitfall is predictable: the company appoints its best people as key users - logical, they know the process best - but frees up no hours. Then the key user does it “on the side”, on Friday afternoons, and every test round slips a week. Whoever takes the role seriously plans it in: formally, in the agenda, with work that temporarily lands elsewhere.
Key user, project lead, application management: who does what
Three roles that get mixed up, with a simple dividing line.
The project lead (in our projects the SPOC) oversees the whole: planning, scope, budget, decisions that cross departments, and the daily contact with the implementation partner. One person, with mandate. In our go-live planner, the availability of this role weighs heavily in the timeline - not for nothing.
The key users each cover one process. They do not decide on the planning, but they do decide how their process lands in the system. Rule of thumb: the project lead decides what and when; the key users determine how.
Application management is not a project role but a structural one: maintaining the system after go-live - users, permissions, settings, small changes. In SMBs the most involved key user often grows into this, and that is a fine route, as long as it is a conscious choice with the time to match rather than something that silently gets added.
Together these roles form your project team: one project lead, a key user per core process, and a plan for management after go-live. There really are no more flavours - and no more are needed.
How do you pick the right key users?
Not by hierarchy. The department manager is by no means always the best choice; the person who does the work daily usually is. Three criteria that matter in practice:
Process knowledge including the exceptions. The best key user is the person colleagues already turn to when something gets stuck. That person knows not just the rule, but the ten exceptions to it.
Daring to have an opinion. The role demands choices: this we configure, that we abolish. Someone who finds everything “fine either way” delivers a system that stands for nothing. Being allowed to be critical - including towards their own manager and towards us - is a job requirement.
Standing in the team. The key user will become trainer and point of contact. Someone the team trusts brings colleagues along; someone seen as a controller does not.
And one anti-criterion: do not pick only the biggest enthusiast. A healthy sceptic who did not trust the system at first and does after testing is worth more at go-live than ten cheering early adopters.
In short
A key user is the process representative during an ERP implementation: they explain the real work, co-decide on the configuration, test with real cases, train their colleagues and remain the first point of contact after go-live. The role takes half a day to a full day per week and is, together with an available project lead, the biggest accelerator of any project. Pick on process knowledge, backbone and standing - not on job title - and formally free up time for it. Get that right, and the most important part of your project team is in place.
Building your project team for an Odoo implementation? Book a free Odoo scan and we will discuss which roles your project needs - or first run your timeline and go-live date.
Read more: How long does an Odoo implementation take? · The go-live planner · The TARGET method · What does an Odoo implementation cost?