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.
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:
The [company] support community
Connect with peers, ask questions, and share feedback with [company]
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:
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.
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?
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.
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.
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.
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.
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.
In surveys, we often questions like:
“On a scale of 1 to 5, with 5 being the highest, how satisfied or unsatisfied are you with your community experience?”
“On a scale of 1 to 5, with 5 being the highest, how relevant or irrelevant do you find the information shared within the community?”
This is a useful measure as it gives a simple score for the community you can improve over time.
When we worked on this project, this was the benchmark we were using.
You can use the following weighted averages to interpret the results:
- Above 4.5 – Excellent
- 4.2 to 4.5 – Very Good
- 3.75 to 4.2 – Ok
- 3.3 to 3.75 – Poor
- Below 3.3 – Extremely poor
I’d recommend undertaking the survey every 6 to 12 months and tracking changes over time.
(p.s. This is also a good way to measure the impact of a major platform change).
There are probably three tiers to this:
1) Tier One: Anyone can ask questions. In this scenario, anyone can join a community and ask a question. The upside is this is good for engagement. The downside is you might get a lot of spam and poor-quality questions. It requires extra work to filter the good from the bad.
2) Tier Two: Only Customers/Registered Members Can Ask Questions. In this scenario, only those using an email domain that is recognised as a customer can ask questions. The upside is this prevents most spam and improves the quality of questions. The downside is it might lead to a lot of poor quality questions and the person asking the question might not have knowledge or permission to fix the issue they’re addressing (this is especially common in B2B SaaS communities where the software users, admins, and buyers are different people).
3) Tier Three: Only Key Contacts Can Ask Questions. In this scenario, only the key contact (typically the technical contact) can ask questions in the community. This drastically improves the question quality and community satisfaction (the poster can utilise the answers themselves). Superusers also tend to like higher-quality questions. But it comes at a heavy cost to engagement, it’s; harder to reach a critical mass of activity, and often requires time to validate each person who joins the community to ensure they’re assigned the right permissions.
In most cases, tier two is the best answer with a private group for key contacts to get unique support from top members.
Ideally, members reply to each other’s questions.
You and your support team would be left with questions that are especially complex, unique, or involve the exchange of personal data to solve.
Sometimes that doesn’t happen. Most frequently, it’s because too few people have the expertise to answer the questions. Okta, one of our clients, is an example. Most responses come from staff today.
So if it’s still staff answering most questions, why not just ditch the community and continue with other support channels?
The answer is simple; search. Other people might find the answers being posted.
One good answer from a staff member might help just the original poster or it might help thousands of others looking for an answer to the same question. This in turn helps visitors get the answers they need faster, reduces support costs, and attracts more people to the site.
If a gamification system is poorly designed, the same force which motivates members initially will demotivate them eventually.
In the beginning, it’s usually quite simple to quickly rise up the levels/collect new badges.
For example, let’s imagine each answer is worth 3 points, with a typical point system like that shown below you can see how people can rapidly advance:
- Level 1: 5 points (2 answers)
- Level 2: 10 points (4 answers)
- Level 3: 20 points (7 answers)
- Level 4: 40 points (14 answers) etc…
Answering 14 questions will probably only take a couple of weeks.
The danger here is people rapidly reach the maximum level (Salesforce, for example, allows a maximum of 50 levels). Therefore, most gamification systems make it increasingly difficult to advance to each new tier. At the higher end, this often means a system like:
- Level 44: 20,000 points (6,667 answers)
- Level 45: 25,000 points (8,331 answers)
- Level 46: 31,000 points (10,333 answers)
Each new level becomes increasingly less achievable (see the exponential curve). Advancing once took weeks and months. Now it might take years.
Sometimes, there simply aren’t enough questions in a community to make achieving a new level viable. I’ve seen communities with 20 to 30 questions per week have levels that are thousands of questions apart.
Worse yet, levels have less meaning. Do you really care if you’re level 47 or 48? Would advancing from level 94 to 95 have a big impact?
Due to our laziness and determination to ensure not enough members reach the top level, we design systems that eventually demotivate some of our previously most active members.
There are two better options here:
1) Power-ups. These enable members to accumulate points faster as they advance up levels. For example, being an MVP, attending events, or completing training courses might allow people to earn hundreds of points per month/attendance.
2) Points for beginners, badges for veterans. Use levels with far smaller increases until members reach the highest possible level and then use badges to reward members past the top-level (i.e. level 50). You can often create an infinite number of badges and missions that can be tailored towards the needs and desires of top members. This is far more scalable and sustainable. It’s also clear levels are to get newcomers up to speed quickly, badges are for top members.
Choose at least one (with care).