Should You Respond To Questions Before Your Members?

Here’s a common conundrum:

If you (the community manager) respond to a question in a community, other members are less likely to respond. This makes it harder for top members to earn points and feel a sense of influence.

But if you don’t respond to a question in a community, it can linger and look bad. It also means the person asking a question is waiting for a response and becoming increasingly frustrated.

Most community folks treat this as a binary problem and resort to either answering every question they can or only answering questions after 3 to 4 days have passed. Neither is ideal and reflects a lack of thinking about which questions you should or shouldn’t be answering.

There are two levels to this depending upon what data you have access to.

If you have limited data, you immediately respond to questions which:

  • You know it will be hard for most members to answer.
  • Don’t have a solution.
  • Stress a high level of urgency/frustration.
  • Are from first-time participants.
  • Are from high-value members/customers.

If you can scrape or analyse the data, you can If you have limited data to see what kind of questions will or won’t be responded to.

You can see an example below:

Product categories 3 and 4 – leave for members
In the above example, you probably don’t need to jump in for questions in several categories (especially product 4 product 3).

Developers and partners – check responses and add value
It’s also clear that developers and partners aren’t getting good responses. So you may want to check the responses you do get and add value where you can.

Product 1 – Escalate after 300 minutes
It’s also clear that the ‘product 1’ category has a high time to first response, but a low response rate. This suggests members are answering the easy questions, but the rest linger. You might set a rule that if a question lingers here for more than 300 minutes you jump in.

Product 2 – Jump in immediately
Finally, product 2 has poor responses all round. You should immediately jump in and answer these questions because the community doesn’t seem to have the expertise to do it.

Like most things, this isn’t a binary problem. You can dive deeper and develop a much better solution.

p.s. If you want to be really fancy, you can build a model using category, subject title, post length, and sender information to predict which questions will receive a response and jump in those that are unlikely to get a reply.

Documentation vs. Knowledge Base vs. Forums vs. Support Tickets

The definition and value of each has come up a few times recently, so here’s an easy way to think about it.

Here’s a simplified way to think about it:

  • Documentation (the manual). Documentation is the manual that tells you how to use a product or service. It should cover every feature of the product and how to use it. Documentation is created and maintained by the organisation, not by its audience/members.

Like a manual, it needs to find the balance between providing enough information that the audience can learn everything they need to learn without providing so much information that it becomes overwhelming. More importantly, documentation also needs to be written from the audience’s perspective using the terms the audience would and with empathy for how the audience learns.

  • Knowledge Base (the FAQ). The knowledge base is the troubleshooting guide (or FAQ). It provides up-to-date information and resources to solve the most common questions asked by members. As a result, it’s often created (or co-created) by community members sharing their best advice with one another. When an issue comes up often in the forums or support tickets, it should be turned into a knowledge-based article. The knowledge base helps members get the most from the products by providing the resources members are likely to need.
  • Forums (the experts). Forums give you access to the best experts who can help. They are the place to ask for help when you don’t understand something or are looking for ideas, opinions, and suggestions. Forums connect you with people who have been through your situation and can provide you with advice and support to guide you through whatever situation you’re facing. Forums are unofficial. Sometimes they suggest workarounds a company cannot endorse.
  • Customer support (emergency support). Customer support channels are the emergency services of getting help. They’re the fire brigade, police, or ambulance of the support world. Unless you’re paying for a premium support package (a lot like living in a building with private security), it’s the place you turn to for a) urgent help b) support which requires you to share private information c) when no other channel can help.

To summarise….

Documentation = Learn how a product/service works.

Knowledge base = Solve common problems.

Forums = Get the best advice.

Support = Get urgent help.

There are a few more things to note about each of these channels.

1) Update the documentation. If forum posts and customer support tickets frequently seem confused about how a product feature works, you need to update the documentation for that feature. There should be a constant loop between forum inputs (especially) and updated community documentation.

2) Turn common questions into articles. Common questions in a community should be turned into a knowledge base article (with links to that article in the popular discussions for the topic).

3) Don’t start a knowledge base unless you have a huge audience. You need a huge number of members and queries to sustain a member-curated knowledge base. Many organisations don’t have the audience scale to create, sustain, and maintain one.

4) Promote forums before support channels. If you promote customer support channels more prominently than community, people will use support channels instead of the community.

Also, see this take from UCLA.

Putting A Price On Being Accessible

A common story…

The community launches and quickly reaches a critical mass of activity.

A major benefit of the community to members is being able to engage directly with staff on issues that matter to them.

However, as the community grows, staff become busier and less accessible. Members start to feel neglected and sentiment in the community gradually turns against the organisation.

There are three interrelated problems here:

First, it’s hard to translate ‘accessibility’ into a metric. As a result it can’t easily be turned into a goal and thus rarely becomes a priority – at least not alongside more measurable priorities.

Second, you often don’t notice when accessibility is slipping precisely because you’re becoming busy with other tasks. You might think you’re still engaging with members at the same level, but members know that’s not the case.

Third, it’s easy to undervalue the importance of simply being accessible. If a superuser has a question, they should be able to get a reply from you within 24 hours in a private group. It’s good for engineers to visit the community frequently and tackle some questions. It shows the organisation cares.

Being accessible is important. It’s one of the major reasons to build a brand community in the first place. You get to give your most important audiences better access to you and each other.

The problems above also highlight a solution:

1) Make accessibility a metric you’re accountable for. Either add it as a question in your annual (or bi-annual) survey or measure the number of staff engagement in the community.

2) Recognise that new priorities will make you less accessible. As the community expands, you will become less accessible unless your headcount expands with the community.

3) Gather anecdotal feedback showing the importance of direct engagement. Whenever you see a positive outcome of direct engagement, capture it in Evernote (or any tool you like) and build up a growing collection of powerful stories to persuade others.

It might not entirely solve the problem, but it should hopefully help.

No-One Wants To Be In The VIP Room Of An Empty Club

You can’t expect to have successful groups within a community platform until the community itself is thriving.

This sounds pretty obvious, but judging by the number of groups being created in communities attracting just a handful of posts a day, it’s clear it’s being violated often.

People don’t need intimacy or a unique place to chat if there isn’t much chatter happening already. Each new group is like starting a new community. If you can’t get the public area thriving, there’s not much hope of getting the private area going either.

The rules for creating a group should be simple:

1) Are we getting hundreds of posts a month in our public community?

2) Are members screaming for a private place to have a different type of discussions?

If the answer to both isn’t an obvious yes, don’t start a group.

When To Create A Group vs. A Category?

During a member research interview this week, a member noted ‘I don’t really know the difference between groups and categories’.

That’s not a surprise. Most of the time there isn’t much of a difference. In fact, most of the time the group should simply be a category. It attracts more participation and is easier for members to use.

Groups typically serve one of three purposes:

1) Keep most discussions relevant. A group might be created to prevent the main discussion area from being overwhelmed by a topic which a small group of members are really eager to discuss but the majority aren’t. This is important when a homepage pulls in all the latest discussions. Groups also often serve as places to support different languages without replicating the entire community experience.

2) Provide a place for private, intimate, discussions to happen. A group of members want to be able to share details about themselves or their challenges where only trusted others can see. In this case, groups are typically smaller (often 8 to 12 people).

3) Coordinating actions. Provide a place for coordinating action amongst a small group of members (i.e. superuser groups). People can coordinate activities about what to work on next and it’s an easy means for the community manager to distribute news to all superusers at once.

There are some exceptions. In Salesforce communities, for example, groups serve as a place to post announcements that all subscribed members can see. But this isn’t the best medium to do it.

If your group doesn’t obviously fit into one of these molds, I’d suggest starting a category instead.

The Name, Tagline, Description, and Explanation

It’s important to clearly and consistently communicate your positioning internally and externally.

Far too often, the positioning is either unclear or poorly communicated.

If you look at the name, tagline, and description of a typical support community, you might find something like:

Community Name:
The [company] support community

Tagline:
Connect with peers, ask questions, and share feedback with [company]

Description:
The [company] community is a place where you can ask and answer questions, find others like you working in the industry, and share feedback directly with [company]. Whether you just want help with a small problem, are keen to learn from your peers in the industry, or help make a change in the product, this is the community for you.

This isn’t terrible, but it doesn’t really communicate the unique value of the community. It doesn’t answer the question; why not just contact customer support?

Let’s imagine an example where our research shows the audience feels traditional support channels are too slow. When we’re launching a community, our positioning is focused upon speed. Everything else flows from this:

Positioning:
Speed

Community Name (2 – 4 words)
Rapid Responders Community.

Tagline (one sentence)
Get rapid responses to solve your questions from your peers.

Description (one paragraph)
Our expert rapid responders quickly help you get answers, share their advice, and walk you through the steps to resolve your challenges. The rapid responders community is the first place you can turn to learn the best solutions to common challenges, find techniques for getting the most from your , and see some of the best implementations of in the ecosystem today.

Types Of Promotional Messages:

  • Avg. time to first response.
  • Fastest solution of the day.
  • Faster responder of the month.
  • Can you solve this question before others?
  • How long will you waste trying to find a solution elsewhere?
  • Cost per minute wasted looking for a solution.

Once you have the name, tagline, description in place, the promotional messages you send out flow naturally. You can even imagine in the example above the organisation might share social media images featuring some of the fastest responders and their record times etc…

Two more thoughts here about positioning based upon some (occasionally bitter) experience.

First, it makes a HUGE difference when everyone internally and externally communicates the same positioning (speed) in every interaction related to the community. It provides a natural reason to visit and engage in the community.

Second, positioning succeeds when it pushes an ‘edge’ that excites the audience. This means a trade-off. You can’t please everyone internally or externally. The problem with pushing an edge is you usually face internal resistance. For example, someone (perhaps the customer support team) might ‘not be comfortable’ with the positioning above and try to sand off the edges.

The skill is finding a path through the resistance without sanding off the edge.

The Curse Of Unanswered Questions

A support person told me today:

“We go through the support questions in our inbox first, then if we have time we answer questions in the community”

Isn’t this backward?

An unanswered question in an inbox isn’t ideal, but it’s only doing harm to one person. No one else can see it.

An unanswered question in a community is harming the entire community. It discourages other members from asking questions in the community. It’s a very visible sign about an organisation’s disinterest in its customers.

Worse yet, as unanswered questions accumulate people will stop using the community and send more questions into your inbox instead. You can reduce a lot of the questions in the inbox if you answer them in the community first.

Maybe support staff should answer questions in the community first and then look at their inbox?

There Are No Exceptions To The Rules

A situation emerged at a delicate time last year.

A community member was accused of making a racist remark on their personal Facebook page.

The accuser demanded they be banned from the community. When the community manager didn’t immediately do this, they published a tweet that included the alleged quote, @mentioned several prominent members of the black community, and demanded the member be removed. This was retweeted a couple of times and the brand’s CEO’s email was shared around to write emails too. This creates internal pressure to remove the member and follow up with a statement that ‘racism will not be tolerated here’.

I recommended not removing the member because she hadn’t broken the community’s rules. This was supported by two factors:

1) There was no proof to support the allegation (no screenshots or other witnesses to corroborate the claim).

2) It happened outside of the community and thus isn’t covered by the rules of the community

(the member quit the community before the ultimate decision was reached).

If you decide to remove a member based upon an accusation alone, you’re opening a pandora’s box of accusations and counter-accusations which will be impossible to police. Worse yet, it encourages snooping on private social media accounts of other members looking for anything which could be interpreted negatively.

Yet, this also highlights a problem in the future. If a member was clearly expressing racist remarks in a visible channel (whether it happened in this instance or not) it would be asking for trouble by allowing them to continue to engage within the community.

So we decided to update the rules. The new rule was simple enough to understand.

It read (paraphrased): If there is clear evidence a member is found to have engaged in speech or activities which are intentionally and unequivocally hateful either inside or outside of the community, the member will be suspended from the community pending a full evaluation of evidence.

For reasons which belong in another post, the terms ‘clear evidence’, ‘intentional’, ‘unequivocal’ are pretty important there. Likewise is the process (suspension pending evaluation of evidence).

A few final thoughts about the issue.

1) There should be no exceptions to your rules. Either you update the rules or you have nothing to enforce. When you make exceptions you’re inviting far worse problems later.

2) Rules are there to protect members, not punish members. Members might not like a failure to remove a member in the incident above, but the same rationale for not removing the member is also the rationale that protects them too.

3) If you bend the rules to public pressure, you’re no longer in charge. If you do what the mob tells you, you have mob rule (aside, it often takes far more courage not to remove someone than remove someone).

So, either update the rules or enforce what you have. No exceptions.

Balancing Loops In The System

Anything popular eventually comes up against an equal force of its own resistance. In systems thinking, this is known as a balancing loop.

When a good restaurant opens in town, it gets rave reviews and everyone wants to go. This means it either becomes too expensive or too difficult to get a booking. The restaurant might become a chain, but then maintaining standards becomes a challenge, and chain restaurants lose their luster and fewer people want to go.

When a tourist destination gets rave reviews it’s ruined by a flood of tourists.

A while back, it became clear that pithy, absolutist, statements on Twitter attracted the most attention. Everyone rushed to embrace the same tactic. This creates fatigue and undermines the credibility of everyone embracing the same approach (remember listicles? ‘You won’t believe number 7!’).

The popularity of podcasts and newsletters is another example. The more people who create one, the fewer people each will attract. This in turn creates fatigue with the medium and an eventual backlash against their perceived value.

Communities are no different. As your community grows in popularity it encounters similar balancing loops. It becomes a target for bad actors. It becomes harder to feel like you belong. The community attracts poorer quality (or repetitive) questions (which in turn tend to drive the experts into private spaces).

It’s important to consider the strategic implications of balancing loops. Anything that is exploding in popularity will eventually clash against its own balancing loops. Whether you should incorporate or embrace it depends on whether it supports your strategy. Most of the time, the answer is to be patient and stick to the plan.

Change The Incentives To Resolve Community Issues

If you look deep enough at why a community isn’t working, you often find an incentives problem.

A person (or persons) at a senior level isn’t incentivised to make a community click.

In one community, the most frequently cited problem is technological. The experience is so bad and clunky, members give up on using it. This problem rolls up to the person responsible for the Salesforce platform. This person is incentivised by budget, speed to resolving critical problems, and the ability to scale the platform.

This doesn’t mesh well with goals like active members, member feedback on the experience, utilization of the unique features of the platform etc…

So the community team is always fighting for scraps of time to make minor improvements. It pretty much kills the entire project.

Getting to know the IT team can help. But, ultimately, you’re going to have to go a level higher to change the system. This probably means making a financial case (i.e. ‘the community is costing us [$$$$] per day and not achieving its goals’), a logical case (i.e ‘we shouldn’t be driving our best customers to have their worst experience’) and an emotive case (i.e. ‘our competitors are all doing much better than us’).

It’s a choice really. You can accept whatever scraps of support and attention you get from IT (and other teams) to make the community work. Or you can look at the incentives (or objectives) of each group and try to change them to make the community work.

Don’t Make Changes Until You Understand The Ecosystem

An incident recently reminded me of the Ron Johnson/JCPenny story.

In 2011, JCPenney hired Apple’s retail chief Ron Johnson as CEO.

Ron Johnson decided JCPenny should be more like Apple. Senior staff are replaced, advertising and PR agencies are changed, sales and promotions are cut etc…

A year later, JCPenny’s sales plummeted by 32% (“the worst in retail history”) and Ron was fired.

It’s common when you’re going from a very successful community to another community to make your new community like the old. This frequently means changing the platform, bringing in new rules, adopting similar processes in managing the community etc..

And it’s equally common for this approach to fail miserably – often disastrously (the worst case I can recall led to members abandoning the expensive brand-hosted community and creating their own, far more popular, community elsewhere).

Two considerations here:

1) Did your previous community succeed because of what you did or in spite of what you did? Building a community in a mature, fertile, environment (i.e. where you have lots of support, a large flow of incoming members, a high-risk tolerance) is very different from building a community in a more challenging environment (i.e. a smaller, private, community).

2) What benchmarks can you improve? What is the community doing well at the moment? What should be changed? Where are the incremental areas of growth?

Don’t make big changes until you really understand the full ecosystem.

Facebook Gives You Quantity, Forums Give You Quality

A while back, this screenshot appeared on my Facebook feed.

MoneySavingExpert (a former client) is promoting a forum post (note: promoting forum posts via social media is a good idea).

It’s interesting that there are 77 comments on the Facebook post compared with just 53 on the forum post it’s promoting.

So why not simply post discussions on Facebook and do away with the forum?

The answer is in the quality of comments. Most respondents on Facebook probably didn’t read the forum post (or they would reply in the forum instead of returning to Facebook?). This shows in the quality of discussions. They’re generally more emotive and antagonistic.

The posts in the forum however are more considered and helpful.

Compare the above with the posts below.

The extra friction that a forum demands (registering/logging in, clicking the title that interests you, and reading the post) creates a far greater exchange of quality information.

If engagement is all you want, Facebook might be a great tool for that.

But if you want an exchange of quality information, forums, and hosted community platforms are usually much, much, better.