The software is picked, the start date is set, and one line in the project plan stays empty: who carries the rollout inside the team. Not the owner, not the IT provider. The person who gets asked at ten on a Tuesday when an invoice is not where it should be.
That role has a name. In software projects it is called the key user, in some businesses the multiplier. The name matters less than two things: that the role is written down, and that it comes with hours in the calendar.
What is a key user in a software rollout?
A key user is a person from inside the business who specialises in one piece of software and is the first point of contact for it in their own area. The role comes from ERP projects and works wherever several people have to use a new tool.
The specialist portal t2informatik describes the key user as a trainer, coach, multiplier and ambassador for a product. The line to IT administration is clear: administration grants rights and keeps the system running, the key user answers how the local workflow looks inside it.
What does a key user actually do?
Four things across three phases: gathering requirements, testing, training colleagues, then answering questions after the start. The role begins before the selection and does not end on day one.
- Before the selection: describe the local workflow, with volumes per week and known error sources.
- During setup: check that the requirements are built the way the department needs them.
- During testing: run your own cases, including the rare ones nobody else knows.
- Before the start: train colleagues with examples from your own business.
- After go live: answer questions and write down what does not work.
- In operation: bundle the feedback and settle it with the vendor or project lead.
The last one is missing most often. With no place where feedback comes together, it goes to the vendor one message at a time, or nowhere. A quarter later nobody knows which points are still open.
How many key users does a small business need?
As a guide one per area with a workflow of its own, and at least two in the business. At ten employees that is usually two people, at fifty four to six.
t2informatik points out that a company may have exactly one key user for a product, but equally one in department A and another in department B. The number that matters in a small business is two. With a single person the role stops at the first holiday.
Who do you pick as a key user?
The person who runs the workflow every day and whom the others listen to. The consultancy anaptis names an overview of the relevant workflows rather than single tasks, a view across the department boundary, plus empathy and standing in the team.
- Knows the workflow beyond their own task, including the handovers to the next area.
- Likes explaining and has patience with questions that come twice.
- Carries weight in the team, with or without a title.
- Brings a basic technical understanding, without being an IT specialist.
Two selection patterns go wrong regularly. The first picks the person with the emptiest calendar, who rarely has the best view of the workflow. The second picks the most technically minded person, who then explains settings nobody asked about.
A role without hours set aside is not a role, it is a promise. Put the hours in the calendar before the first test run. Otherwise daily business wins every week.
How much time does the role take?
As a guide half a day per week while the system is being set up and tested, closer to a full day in the two weeks around the start date, then two to four hours per week. The range depends on how many workflows the software touches.
This is where the role usually breaks. t2informatik writes that overload follows when key users carry out these tasks regularly and on top of full-time work. ERP Management calls it a field of tension between the department, which still needs the work done, and the project.
- 1.Enter the hours as a recurring appointment, not as an intention.
- 2.Decide which ongoing task waits, or who takes it over.
- 3.Name the role in the team, so questions land there instead of with the owner.
- 4.Check after four weeks whether the hours are enough.
What has to be settled in Austria beforehand?
First, who can take it. According to Statistics Austria, 20 percent of companies in Austria employed ICT specialists in 2024, a figure published on 27 January 2025. In the other four fifths there is nobody whose job the new system already is. The role does not appear by itself there, it gets assigned.
Then the form. Section 101 of the Austrian Labour Constitution Act provides that the permanent assignment of an employee to a different workplace has to be reported to the works council without delay, and that the council's consent is needed where it worsens pay or other working conditions. An assignment planned for less than thirteen weeks does not count as permanent. Whether a key user role falls under it is a legal question.
Where does the role fail in daily work?
At three places, and none is the software. The role has no description, so every party attaches its own expectations to the same person. It has no hours, so daily business wins. It has no stand-in, so it ends with the first holiday.
The first place is documented. The industry service ERP Management traces frustration in projects back to key user role descriptions being unclear in most companies, after which varied parties place demands on the same person. Half a page is enough: tasks, hours per week, stand-in, and who decides when opinions differ.
How we support an introduction is on our page about change management and adoption. The selection before it is on the page about tool selection and rollout, and why a tool can still lie idle after three months is in the post on software adoption after the rollout.
The key user concept costs no licence. It costs hours in the calendar of two to six people and half a page of paper. Write that half page and you have someone to ask after the start. Skip it and you have a manual.