There’s an old joke among actors about doing things without planning things properly. It’s only one line: “There’s a barn—let’s do a show!” It has to do with the thinking that the result comes before all the preparation and processes, rather than the other way around. You can’t just “do a show” because there’s a space. You need the right script, a director, a cast, rehearsals, lights, marketing, sales, and so on. Likewise, we can’t say, “Here’s a wiki. We have a user support community!”
So often, overenthusiastic advocates of any initiative jump into action before thinking the process through, especially when the idea (or directive) comes from the boss. Just because someone saw an article about how one organization saved money by using peer-to-peer support doesn’t mean it will work in every organization in the same way.
“Culture Eats Strategy for Breakfast”
Even if you have a well-conceived plan for providing a peer-support community, the culture of your organization may have the last say. If your organization (in reality, not in the ideal) has a negative view of helping each other or of new initiatives in general, you will need to have a very good plan for organizational change to accomplish your community goals. You’ll need to pay very close attention to the why of your initiative, and address the “what’s in it for me?” from the customer’s perspective. You will need those anyway, but especially in the case of a negatively biased culture.
Another cultural element that can damage your peer-support initiative is a tendency to berate those who ask “dumb” (i.e., “newbie”) questions. The saying goes that there’s no such thing as a dumb question, but too often in online groups, more experienced users get impatient with newbies to the point of ridicule, and thus scare off new users with simpler questions and less understanding—precisely the ones who need the most help and support.
Start with Why
What are your reasons for going down the road of peer support? Cost-cutting may be appealing to some managers, but it’s not a reason for end users to buy in. If you start off the right way, cost savings will be a side effect of your peer support system.
Two key pieces of information you want to have upfront are:
- Who’s likely to be asking questions?
- Who’s likely to be answering questions?
Chances are, a bit of research in your current ticket-tracking or ITSM system will turn up the answer to the first question. Who in your organization are the “frequent flyers” who are already asking lots of questions? Every organization has them.
As for the second question, you probably already know them as well: Your “power users” out in the business units who are key contributors to project plans and pilot groups have already been helping you provide support in one way or another, and are probably also answering questions from peers on a daily basis. Every department I’ve ever seen has “go-to” people for questions about the tools they use.
Every organization has frequent flyers or power users. Find them and use them.
By providing a structured way to have these questions asked and answered, we not only can tangibly improve the level of support available to end users, we are also bringing to light a lot of the questions and conversations we didn’t know were taking place.
Some reasons you might cite for engaging end users in a support community are:
- Finding good answers without having to wait on the phone or wait for an email response
- Leveraging subject matter experts who use the systems or applications every day
- Being able to go back and find the answer without having to find the person and ask again
You’ve Got the Why. Now What?
You need to think through the requirements, like any other bit of technology you might invest in. Here are some points to consider:
- You’ll be entrusting a good deal of your organization’s knowledge to it, so it needs to be stable and secure and have a long future road map. It shouldn’t be an unknown startup product.
- It must be as easy to use for the community as possible. Friction at any point will reduce participation, and therefore value.
- It should be accessible to everyone in the organization, from the warehouse worker who uses a computer once or twice a week to the sales staff, engineering staff, and development staff. This means it has to work on a thin client in a virtual desktop environment, or on a mobile device, or on any other platform.
- It shouldn’t require any experience with HTML or any special code, although code may be available for use if desired. (Ex: If I paste in a link, it should be a live hyperlink. I shouldn’t have to know the HTML behind making it a live hyperlink.)
- It must be thoroughly searchable and not (entirely) dependent on tags, which users may forget to include.
Sometimes, a beginner’s question can prompt more experienced people to rethink the way they’re doing something, and that leads to innovations that help everyone.
Also consider these questions, which should be answered not just by support personnel, but by stakeholders from business units as well:
- Do posts appear immediately, or do they need to be moderated?
- Will suggested solutions be checked for accuracy and adherence to policy? If so, who will do that and how much time will it take?
- Will there be internal incentives to contribute either questions or answers—or both? These can be points, badges, and so on.
- What policies do you need in place to prevent any bullying or other negative behaviors?
- What other types of behaviors need to be prohibited or governed?
- What will the consequences be for those who violate policies, and who decides?
What you want to accomplish, ultimately, is to have a community in which your newest, least experienced people can feel that they have a good place to ask questions without being ridiculed, and also a place where they can go on to start answering questions themselves once they gain a little experience. It’s not good to have a community where all the questions are asked by newbies and all the answers are provided by “experts.” Sometimes, a beginner’s question can prompt more experienced people to rethink the way they’re doing something, and that leads to innovations that help everyone.
Roy Atkinson is HDI’s senior writer/analyst. He is a certified HDI Support Center Manager and a veteran of both small business and enterprise consulting, service, and support. In addition, he has both frontline and management experience. Roy was a member of the conference faculty for the HDI 2015 Conference & Expo, and he’s known for his social media presence, especially on the topic of customer service. He also serves as the chapter advisor for the HDI Northern New England local chapter.
This article first appeared in the March/April 2015 must-read issue of SupportWorld.