Types of WalkMe Implementations

Sometimes the way we demo and explain WalkMe can be contradictory and cause problems.  This is because there are a couple of different paradigms for how WalkMe can be implemented...

Has This Happened To You?

When we show the help menu and searching inside of it, people get the impression that is where a user would go to enter a question and find the answer.  Seems plausible, right?

Cool, I get it..  This will be the help library..

Yet when we get to demoing Insights we talk about Tracked Events, Funnels, ROI.  Then we emphasize Data - Action - Experience and the importance of knowing the metric you're influencing ahead of time.

This can confuse people and seem like a bit of a bait and switch.

Wait, why am I measuring stuff?  I had just connected the dots on what we would do. 

Which one is right?

Surgical WalkMe vs. Kitchen Sink WalkMe

The confusion here is that there are two different modes for how WalkMe can be implemented...

Surgical WalkMe
 

Typically in an employee facing implementation you have an existing incumbent application and known user pain points. 

They don't like X, they're not completing Y, field Z is filled out incorrectly, etc.

Here we can say where is the friction, where are people struggling?

We may have it tickets to go on and errors that we can reduce

Here you can definitely be Data - Action - Experience, use the "Adoption Projects" and the WalkMe we implement can be focused, almost like a science project.

One downside of this approach is, what's in the help menu?  Do we even have a help menu?  If we don't have a help menu, how do we know what they're searching for?  Users may still be getting app documentation from here, there and everywhere.  And we're only implementing a few SmartTips and a Launcher, let's say.

Kitchen Sink WalkMe

More common to all-new app implementations and customer facing implementations is the idea of WalkMe as the all-in-one help system.  Here, your customers may say:

We don't want to have support articles on another site.
 

We don't want just a smattering of answers, we want users to be able to find any answer to any question they have inside of the widget.

We want WalkMe to be the single source of truth on the app.

With this mode of implementing WalkMe, is Data - Action - Experience out the window?

Well..  We know what we're trying to do, we're trying to deprecate the other help system, right?

We're trying to put ALL the content into WalkMe.

The major downside here is how do you know what all you need to build?

What if you don't know yet where users are struggling?

You still need to gather some data from initial QA / Pilots / User feedback.

Try to build Walk-Thrus for all the basic and onboarding type items.

You don't have to build one for every single app function.  That is going to result in a lot of unused content that needs to be maintained.

Conclusion

The bottom line is, WalkMe can be used in a number of different ways.

How you use it depends on the situation.  

It's not that one of his modes is better it's just that they're different

And you need to identify which strategy you're using before you deploy

Hope this helps!