The famous flaw in most enterprise communities is the majority of people don’t visit to join a community, they visit to solve a problem.
This is why the majority of contributors to a community have made precisely one post.
They asked a question, received an answer (or didn’t), and then left never to return. The vast majority of attempts to shift these numbers have failed miserably. This audience simply doesn’t want to connect, share, and ‘join the conversation’. They want to solve their problem and be on their way.
The challenge facing most enterprise community professionals is less about trying to nurture a sense of community amongst members and more about building the right support experience around the community – where community plays a critical role in supporting every other support channel.
Enter the community-powered customer support hub.
The Five Layers Of The Customer Support Hub
The trend in recent years has been fairly clear, organisations are creating integrated support hubs which include knowledge bases, federated search, virtual agents, community, customer support tickets, and product suggestions.
This is slightly different from a customer portal which handles a broader range of use cases than support (e.g. it might include the academy, events, product updates etc…)
To get the support hub right, you need to execute extremely well on five distinct layers. These are shown here.
We can tackle each layer in turn.
The Foundation Layer: The Knowledge Base
Pretty much every organisation has a knowledge base for customers to browse. The purpose of this knowledge base is to preempt the majority of questions customers are likely to have and help customers follow best practices in the setup and usage of products.
Whenever a customer searches for an answer to a question, the knowledge base is often the first place they visit. A great knowledge base will have articles showing up in search results, in chatbot recommendations, in responses to community questions, and be referenced by support staff.
The cheapest way to solve a customer query is in the knowledge base. This can reduce 80% or more of questions from downstream channels.
(Aside, this is also the problem of measuring activity levels in a community, the community should inform the knowledge base – which in turn should reduce the number of questions in the community.)
However, the knowledge base has to perform a tricky juggling act. It should be comprehensive enough to resolve the 20% of queries which represent 80% of the volume of questions. But it shouldn’t aim to be so comprehensive to try and tackle every query.
This becomes impossible to maintain and is overwhelming for members. The knowledge hub needs to have well-maintained content that’s refreshed regularly. It also needs to archive out-of-date articles.
A great knowledge base aims to maintain a smaller number of articles up to an incredibly high standard. For other queries, there are other channels.
An excellent example of this is the Asana knowledge base.
Notice the clean interface, great use of white space, clear search bar, and collapsible navigation menus on the left-hand side so as not to be overwhelming.
The tabs are well categorised by likely challenges and by problems members will potentially encounter. All of this makes navigation simple.
Asana seems to have taken a less is more approach – maintaining a fewer number of high-quality articles instead of tackling every eventuality. Developer articles have also been smartly separated from other articles.
The knowledge base should always be receptive to what’s happening in a community (and other channels). If the same question repeatedly appears in the community, it needs to be tackled as a knowledge hub article (don’t forget to update community discussions with the link to the knowledge article). Likewise, if an article in the knowledge base isn’t getting much traffic, it might be time to archive the article.
Ultimately, the knowledge base is the foundation layer of support. If it’s well-designed and implemented, it makes the entire support experience much better for everyone.
The Search Layer
This is the layer where people are on the site and search for the information they want to find.
This comes in the form of search bars and chatbots.
Traditionally this was by a search bar which, like Google, would often retrieve the result which best matched the query.
The biggest problem with this is organisations frequently use different platforms for the knowledge base, documentation, academy, community, etc…But the search tool used was often limited to retrieving information from a single database. In recent years, organisations have shifted to using unified (Federated) and cognitive search tools.
These tools can retrieve results from multiple databases and enable the organisation to assign weightings to different results to skew where customers are most likely to visit as needed. This means the results can be retrieved from the corporate site, dev community, webinars, roadmap, pricing, knowledge base and more. This has a big impact on reducing knowledge silos within the community.
A good example of this is the Logitech support centre.
You can see here that relevant results are retrieved from the knowledge base, product documentation, downloads, and the community. When it works well, it gives members a single box to enter a question and find what they want.
At the moment, many organisations still don’t deploy a federated search tool – this has a hugely negative impact on the customer experience who must then visit multiple places to find the answers they need. Note: Documentation is not the same as a knowledge base.
In the past, chatbots were rudimentary tools that operated on decision trees that relied heavily on keywords. By following a set process, the chatbot would either provide you with the information you were seeking or guide you to the next step in your journey
An example of this in practice is the Logitech Chat Bot below:
You can see above that it’s still following a fairly basic decision-tree format to try and guide the individual to the right answer. It’s becoming increasingly common for chatbots to act as a screener to solve a problem before redirecting the question to a virtual support agent (skipping the community entirely).
Recent incarnations (up to 2023) were far more advanced and used a combination of natural language processing to be able to ask questions, check what has been attempted before and try to guide someone to the right solution.
The biggest question is how quickly ChatGPT (or ChatGPTesque) will be incorporated. This will greatly enable higher quality levels of interaction and the ability for members to get detailed answers specific to their questions. If this works well, it should significantly reduce the number of challenges which drop through to the next level.
A community also supports this process by providing a huge amount of training data to process. The more community questions there are, the better the AI bot will be able to surface the right answer for members. Over time this should lead to fewer and fewer questions reaching the community.
As we’ve written before, ChatGPT and similar tools thrive when customers either don’t know what terms to search for or can’t browse mountains of information to find what they need. They fail, however, when the customer needs the best solution to a problem, needs a workaround (edge case), or is looking for personal experiences (e.g. would you recommend [vendor?]).
The Community Layer
The community and social media layer is where customers go to ask the in-between questions.
These questions aren’t so easy they can be solved by existing documentation, but don’t require the customer to reveal personal information to get a resolution.
Generally speaking, the success of a community hangs upon how many in-between questions people have.
One of two things happens at this layer.
First, people ask the question in a search engine and they land on a question which has already been asked in the community. This typically accounts for the majority of traffic in most communities.
Second, if they don’t find the answer to their question, they might ask the question themselves in the community.
By community, we’re not just referring to a hosted community but any place where members can interact with other members to get an answer. This includes social media and third-party platforms (Reddit, StackExchange, YouTube, Twitch etc…).
The community layer should resolve as many of those in-between questions as possible. It should also be used to inform other layers. It should highlight questions which should be tackled by knowledge articles, provide on-site search and chatbots with answers to the surface, and provide support agents with ideas they can try to resolve the customer issue.
Atlassian (a FeverBee client), is probably one of the best examples of this today.
This doesn’t mean a community is exclusively for in-between questions, there are plenty of people who simply prefer a community compared to filing a support ticket. A community helps reinforce the innate desire for self-service.
There are also plenty of use cases a community offers which don’t involve Q&A (user groups, events and activities etc…).
The Customer Support Agent Layer
The next layer is where a human support agent is involved.
In my experience, organisations can take one of two approaches.
The first is they want to reduce the number of calls which reach support agents as much as possible. Sometimes the cost of resolving an issue can reach hundreds of dollars per call. This means there is a huge benefit from resolving these issues in the community.
The second is they want to have as much time with customers as possible. In this approach, the goal isn’t to get customers off the phone as quickly as possible but to use the opportunity to build a better relationship with them and understand their needs.
In my experience, the former is more common than the latter – but some truly customer-centric organisations excel here. If your scaled support system is implemented correctly, your customer support team should only be tackling questions which either:
- Require a member to share personal data to be able to resolve.
- Are too complex or rare for the community to resolve (edge cases).
- Are from the highest value customers paying for a dedicated support agent.
- Are from customers who have a natural preference for support agents (often older customers).
Whenever community support questions require Personally Identifiable Information (PII) from the customer and are moved to a private support ticket for resolution, it’s critical to also provide an update on the original community thread.
This approach prevents the interaction from appearing to have abruptly halted with a move to a private support channel, which could leave the community feeling uninformed, probably resulting in more support tickets about the topic, which is counterproductive to the self-support model.
Ultimately, whether by support ticket or by phone call, the goal is to route the question to a person with the right answer as quickly as possible. The customer support layer is primarily the catch-all for issues which can’t be resolved anywhere else. You want your paid staff to be tackling the toughest questions for the highest value customers.
Ideally, the customer will be able to file a support ticket via the same destination as they can search for information, ask the community, engage with a chatbot etc…
The Product Ideas Layer
The final layer is the product suggestion (or ideas) layer.
It’s relatively common for customer support staff to recommend a customer post any problem which can’t be resolved as a suggestion for a product enhancement. This is a common route to suggesting an idea but it’s not the only route.
Often customers will simply want to suggest an idea without having to begin with an initial problem. Regardless, the product ideas layer is the next. It aims to be the final place to offer customers hope for a solution when any other channel fails.
A good example of this is the DigitalOcean community (hosted by Pendo).
You can see here it’s easy to add the idea and track its progress over time. The big danger of having an ideation area, however, is when the ideas aren’t utilised.
This quickly becomes seen as a dumping ground which upsets members. You should only implement an ideas or suggestions layer when there is a product team eager to receive, filter, and provide feedback on the ideas. If that’s not in place, don’t offer ideas.
Build Your Community-Driven Support System
Customers are like water following the path of least resistance. Whichever pathway seems like the easiest (or quickest) way to resolve their challenge is the one they will take.
If that means asking a question in a community, they will happily do so. If that means searching for an answer in the search bar, they will do it. If that means filing a support ticket, they will do that too.
But here’s the rub, customers don’t want to visit five different places to do those things. They want to fuss around logging into different systems. They want all of these things to be accessible to them in a single destination. They want to achieve their goals with the least amount of effort. They don’t want to ask the same question across multiple channels to get an answer.
The challenge for community and support professionals is to build a seamless support hub.
A common mistake by community professionals right now is to focus on increasing less important areas of the community experience (e.g. gamification, groups etc..) at the expense of the areas which would immediately add more value to people looking for answers to problems (better integrations, search optimization, question flows).
The future of enterprise communities isn’t to build the most perfect standalone destination but to integrate the community as deeply into the support experience as possible.