This is the fifth post in my series about Caveman User Adoption. The first was an overview of 4 Caveman Tenets of user adoption that together create an environment where SharePoint and Office 365 will grow organically. This article is a deeper dive on the fourth and final tenet – Help that is actually helpful. The core idea here is to make changes to your support and training models to increase your users’ comfortable level. Doing this requires a strategic shift, but it is probably the most powerful of all 4 of the caveman tenets. All by itself, it can make or break your adoption efforts.
If we treat our users like they’re at the proverbial DMV every time they want help, guess what? They’re going to avoid our platform whenever they can.
Ideally, as we discussed in earlier posts, your governance rules and the solutions you build for people are simple enough that they don’t typically need a lot of support or training. However, Office 365 and SharePoint are platforms that empower users to solve their own business problems. For users to begin to adopt it on their own, they need to be confident it’s not going to be a long and painful process whenever they try to do something new. Otherwise, they will rarely (or never) do that.
When we hear the word ‘help’, most of us that come from an IT background think of something specific and formal. We think of ‘support’, with all of the lifecycles and processes we’ve been trained to use, or we think of scheduled training classes and online courses. Those things definitely have a place. However, they are not at all what an average user thinks of when they use the word ‘help’. They think of an answer to their question, a demo of a new tool that might help, or a fix for their problem.
Modern IT teams have to find a way to adapt our services for support and training, so that we help users be successful with our tools. If you don’t – they simply won’t adopt them. Some users will just fail, and others will go around you and find other public tools to get their work done. Let’s look at them one at a time.
Most of our traditional IT support processes (like tickets, SLAs, offshore helpdesk lines…) have evolved over the years because we can’t keep up with a completely unstructured and informal free-for-all email and phone-a-rama. However, many times we can take this too far and eventually prioritize our own convenience over the productivity of our users.
It is possible to structure our internal support and training services less formally, without completely abandoning our beloved ticket systems and support hierarchies. If we incorporate a couple of more user-friendly support methods, the result is that users are drawn to our platforms.
This is not an all or nothing proposition. It is a gradual, strategic shift in both mind-set and man-hours that is important if your goal is to increase user adoption and provide higher ROI.
The key here is the mindset – we have to be willing to make it easier for users to get actual help when and where they need it. We have to decide that we’re not going to hide behind the processes and queues we’ve built. Here are a couple of specific support methods that can help you translate that mindset into practical changes that actually help your users.
This is a very simple concept that I’ve seen have dramatic results. Because users almost universally hate tickets, they frequently try to reach out directly to anyone they know that might be able to make their current pain stop. That constant flow of emails and phone calls prevents the admins from getting any other work done. This is why we techies so frequently hide behind the ticket queues. It’s self-defense. However, a little bit of pro-active outreach on your part can make a huge difference.
Put one or two user-friendly members of your support team in a conference room and / or on a Skype or Webex bridge once a week (or whatever other interval makes sense). ‘Ask me anything, and we’ll either answer it, fix it, or get you to the right person.’ Schedule it at a predictable time and place, publish the schedule, and evangelize it like crazy.
At first this might just feel like one more meeting on your calendar – yay… However, once your users get used to this, you should find that it makes all the rest of your time more productive. You’ll be amazed how many will stop (or at least limit) calling / emailing you. Generally, users would rather spend 10 minutes with you live then 2-3 days over email or buried in a support queue somewhere. If you suggest that, they’ll feel like you did them a favor.
To steer people gently that direction, I once created an Outlook signature that said:
‘You know, that’s a really great question. Would you mind stopping by Office Hours Thursday at 11:00 and we can talk it through? I think that would be faster than typing back and forth.’
Then I started just replying with that signature when people reached out directly with a question. Of course, in the vein of actually being helpful – sometimes you need to be responsive to someone's need outside of Office Hours. Good judgement should help figure out what you can push to Office Hours and what you can’t.
Office Hours are even more powerful if you’re launching or migrating something. Change is hard. Give your users a security blanket. Let them talk to a human at regular intervals. Things will go more smoothly, I promise.
Start a Help group / site
Create a searchable source of content internally that is valid and helpful. Put up a simple post whenever you’re getting the same question over and over, whenever you’ve changed governance or implemented something new that makes life simpler, whenever the team identifies a new best practice or adoption goal, whenever you discover something new that really helps you.
This one makes a bigger difference than you think it will. It will ultimately save you time as you are able to point users to a published answer instead of manually typing out a response. If you truly are posting useful things here, some users will even start to search for answers here on their own. Ideally it will also be possible for your users to post and answer each other’s questions here, too.
Where do you do it? Well that varies – but in general I recommend something informal. If you try to implement some kind of formal ‘publishing’ scheme, it frequently becomes an obstacle to getting things out.
Yammer groups can work well, or a ‘public’ O365 Group Files site and Mailbox (or even MS Teams, if you’re a relatively small organization). The advantage of tools like this is that they are low overhead, they create a sense of community, and they give users a reason to try the new tool in a way that doesn’t slow down their everyday work. However – beware. If you create a social or similar discussion-driven destination, you really need to tend to it. If users post questions here, and don’t get an answer - it will be counter-productive.
A more caveman option is a blog site. This is a time-honored way to publish things on the fly, but it is more one-way than a social tool. Users will likely only be able to post comments rather than start conversations of their own. Some organizations use both a blog a site and a Yammer group (or something similar). One for publishing, the other for Q&A.
First, let me say that I really enjoy training. I like to go to classes, and I like to teach classes. I like the focused time and the ability to soak things in more quickly and deeply than I can on my own. That being said...
In my experience, traditional SharePoint / Office 365 training classes don’t work for end users.
They throw so much information at the user that they frequently can’t remember any of it, and they are expensive (especially if you have to use outside resources to deliver them).
They work for a lot of power users, but that’s a significantly smaller audience. The difference has nothing to do with intelligence or aptitude. It has everything to do with relevance and focus. Most end users are simply not ‘SharePoint people’, and don’t have the time or interest to become one. They are HR people, or Sales people, or managers, or whatever other discipline they are paid to be. As a result, SharePoint and / or Office 365 will never be more than a general, secondary skill for them – like driving, or cooking, or doing their own taxes.
Studies suggest that adults learn 60%-90% of their skills through ‘informal’ means. For most users, the 10%-40% left for more ‘formal’ means will be used for their professional focus – not to learn your platform.
This is not really a new concept, but it’s been slow to penetrate corporate technology training programs. Commonly, if users want help growing their skills on our platforms, they have to either go to a training class or try to use a self-paced online course. There is some debate about whether online courses are formal, but they frequently require a significant time investment and don’t focus on use cases tailored for your users. That narrows the audience that will benefit.
‘Help’ doesn’t have to mean ‘training’. ‘Informal’ doesn’t have to mean forcing users to Google on their own. There is a lot you can do as an internal expert by making some strategic shifts to help people be more efficient in that informal time. The idea is to give your end users small bites of information that are targeted on something simple they can use immediately. Here are some ideas that I have found very effective in various organizations:
A. Tip campaigns
When you are launching a new application / version / service… identify some quick, easy tips that will help the average user, and then push them to your users over a few days. This works great as daily mailings or social posts in something like Yammer. Microsoft offers some great templates for these. You can find some of them by using the ‘Train your people’ tile in the O365 Admin Center. Other great templates for mailings and similar user-facing stuff can be found on the Microsoft FastTrack site.
This is even more powerful if you coordinate your tips with adoption goals you might have identified when setting up your metrics. For instance, if you’re trying to help people break out of their inbox – maybe some tips about Skype for Business or Teams would lower the barrier to entry and help them see benefits to these other tools. Other organizations target roles like project managers and show how SharePoint, OneNote, or Planner can simplify daily interactions and work for them.
On a regular cadence, do brief sessions on something useful to the average end user. Publish the schedule and evangelize them like crazy. Record them and post them somewhere later (these make great blog posts…).
To be useful, there are a few core requirements.
- Brief means 45-minutes or less, preferably near the lunch break so people are more likely to have free time to watch.
- Mostly demo, very few slides. (#deathbypowerpoint)
- Focus on a use case, not a feature. (Users don’t care about the nuances of web parts and the publishing feature, but they might want to see a specific example that helps them build a better home page for their team site.)
- Don’t get too detailed. (You’re helping the average user discover something helpful they might not notice or demystify something that is frequently frustrating.)
- Close with a Q&A session – ask me anything, whether it’s about what we just demoed or not.
C. Contextual Help Systems
Contextual help systems, like VisualSP, serve how-to content to users when and where they need it – while they are working. For instance, a user is working in a document library and the system shows help items about checking files in / out and using metadata. The real advantage of any of these systems is that the end user doesn’t even have to go find the ‘help site’. They have direct access to the most relevant help items within the context where they are already working. If you communicate your governance here along with the how-to items, then your users have everything at their fingertips to grow and be successful.
Wrapping it up
Admittedly, it can be difficult for an over-worked admin team to find time and do many of these things. However, when you set priorities to implement a holistic program of adoption-related help activities – they quickly begin to reap benefits. Overall support time will drop. User satisfaction will rise. User adoption will rise. Any changes you make in these areas discussed will help, even if you can’t currently do them all.
Some organizations assign internal team members to these adoption-related activities. Other organizations find it more practical to bring in external contract resources to focus on them, so that they don’t get bogged down in other workloads. Both approaches can work fine – but you have to make a strategic decision to prioritize ‘actual help’ and then follow through by devoting man-hours to it. What about your team? What changes have you made to actually be helpful to your users?