Key users in Salesforce rollouts: what they do

Key users are business users who know the new Salesforce system before everyone else, take part in testing and are the first point of contact for questions in their team after go-live. They also carry feedback from daily work back into the project. Without them every question lands with the project team or support, and many questions are never asked but worked around with an Excel list. Good key users are chosen by standing in the team, not by spare time, and the time they need belongs in the business’s planning beforehand.

Key users cover knowledge and ability

In the ADKAR model key users mainly cover two stages: knowledge and ability. Training conveys knowledge, but only daily work shows whether someone can use the feature in a customer meeting or on the phone. In that moment no hotline helps, but the colleague at the next desk who has done it before.

Manufacturers have an extra layer: sales, inside sales and service work a little differently in every country and at every site. The project team does not know these differences. Key users do, and they can say early where the planned process will not work in their own team.

The tasks change with the project phase

The tasks change with the phase of the project:

1. 01

   Before the build

   workshops · key users with product owner

   Describe how their team works, name special cases, help write acceptance criteria for user stories.

2. 02

   Before go-live

   testing · key users

   Run through their own cases in the acceptance test and show colleagues in short sessions on real cases what changes.

3. 03

   First weeks

   daily work · key users on site

   First point of contact for questions, collect problems and report them to the project in bundles.

4. 04

   Operations

   ongoing · key users and admin

   Onboard new colleagues, learn before every release what is coming and pass it on to the team.

In the acceptance test key users are the best testers, because they know which cases occur in their team. How UAT should be set up is in Salesforce UAT: who tests before the release?.

How do you choose the right key users?

The most common choice is the worst: whoever has time becomes a key user. They are rarely the people the team turns to with questions anyway. I look at other criteria:

• Standing in the team. Colleagues already ask this person for advice today, whatever the system.
• Knowledge of the process. They know how a quote, an order or a service visit really works in their team, including the exceptions.
• Curiosity rather than enthusiasm. A key user does not have to love Salesforce. Critical key users find the weaknesses earlier, and once they are convinced, they convince others.
• Staying for a while. Whoever changes jobs in three months takes the knowledge with them.

In large organisations one key user per team, site or country pays off, two in critical areas. If the only key user of a country is out sick in the week after go-live, the support for the whole country is out.

What is a key user not?

A key user replaces neither support nor the admin. They answer questions about usage, but they do not change configuration and do not fix interface errors. Defects keep going through the ticket system so they get counted and prioritised. A key user is not a trainer who runs whole training programmes either. They show on a real case how it works. If you do not draw these lines, the role is overloaded within a few weeks and the key user stops answering questions.

How much time does the business need to free up?

A key user without freed-up time is a title. Before and shortly after go-live the role needs clearly more time than in operations, because workshops, testing and the first weeks with many questions fall together. How much exactly depends on the scope of the rollout. As an assumption for planning: four workshops of four hours each, one week of acceptance testing at half the time and two weeks after go-live at a third add up to almost eight working days. Preparation and short sessions with colleagues come on top. In operations the effort drops to a few hours a month, mostly around releases.

The manager has to commit this time before the project starts, and someone has to take over the key user’s work during that time. Otherwise the key user tests on the side, and the first questions after go-live stay unanswered because daily business comes first.

The network needs a fixed slot

A network of key users needs a fixed slot. I recommend a short exchange where key users bring in their most important feedback and learn in advance what the next release changes. That turns every key user into a channel in both directions: changes reach the team through them, and problems from the team reach the project through them. What this path looks like before a release is in communicating Salesforce releases to the business.

It also matters that the role is visibly recognised. Whoever takes on extra work for the project should find it in their annual review. That costs nothing and decides whether anyone volunteers for the next project.

Ask whom the team turns to today

Ask every affected team: whom do you ask today when you get stuck in the system? The names that come up several times are your candidates. Then agree the time with the managers and bring the key users into the first workshops, before anything is built. If no name comes up in a team, nobody there carries the topic yet, and that team needs more support during training. How we build the network in programmes is described under change management for Salesforce programmes.