How to fix Enterprise Knowledge?
The purpose of any knowledge is to help answer a question in a concise, precise, and timely way when people want, where they want, and how they want it. From anecdotal experience of using any enterprise product, you may recall that finding answers to any issues whether as a customer or even employee is a very poor experience. Often times, the answer is not found and even if it is, then odds are that it is stale. Knowledge is distributed across multiple disparate islands — google docs, white papers, intranet, slack channels, technical documentation, customer facing knowledge base etc. and it exacerbates the pain. In the era of SaaS software, where customer experience is celebrated and customer churn is frowned up, helping your customers or even channel partners to find answers they need should be the top most priority of any organization but again, what was the last time you were amazed by that experience in a positive way.
This post examines some reasons for why this problem occurs in the first place and possible ways to fix them.
Key Challenges & Possible Fixes
Enterprises have an inside-out view on knowledge versus an outside-in view.
Usually, there are three separate teams (that usually don’t talk to each other) that generate customer-facing information — Techpubs (usually sits within engineering and generate product documentation), Technical Marketing (usually sits within Product Management or Marketing and generate how-to-sell/how-to-configure/competitive collateral) and Support (generate the Knowledge Base articles).
The issue with having separate teams is that there is no consolidated and holistic view of knowledge. Instead, it ends up becoming a reactionary response to a point question resulting in fragmented knowledge. Further complicating the matter, these teams end up using different tools for generating knowledge resulting in a mismatch in format, style, and sometimes even contradictions in the content.
This three-pronged approach to knowledge generation is not by design but most likely the result of how companies evolve.
When a young fledgling startup releases its first product, the requirement of technical documentation comes first. This is typically met by the engineers themselves. Later, when the company grows, professional writers are hired but they still continue to work under engineering — no one questions the structure due to inertia and nothing seems broken. Moreover, it seems intuitive to have technical writers work closely with engineering. So far so good.
Now, customers start using the product and when they face issues, support tickets and emails start trickling in. They are looked at by the newly built support teams. They figure out the answer to the problems but they start documenting the findings in the “Knowledge Base” which is a feature of most customer support tools. This is where things start to really diverge. Engineering teams more often than don’t have access to the ticketing systems (they are priced per seat so only customer support engineers have access to it) — that implies engineers / Techpubs teams are not aware of knowledge being generated.
Lastly, as the companies grow bigger and have well-defined sales teams, the need for “sales collateral” for priming the direct sales/channel arises which is then met by a separate team — the Technical Marketing team.
Customers, however, view knowledge through a simple and singular lens — something that helps them answer their questions promptly so that they can go about doing what they were doing. Calling the knowledge by different names like technical documentation, white paper, blog post, knowledge article is a vendor view and not a customer view.
Possible fix
One possible way to fix this problem is to centralize information creation by using a common knowledge platform across different teams. Technical publications, product marketing, customer support teams serve a particular purpose and these functions will continue to exist. However, by enabling all teams to use the same platform will eliminate most problems that arise with distributed teams. Problem is that no such software platform yet exists that transcends these organizational boundaries and can act as product help, white paper, and knowledge base article at the same time.
Knowledge creation is artificially restricted
As mentioned above, knowledge generation is usually restricted to specific internal teams only. However, as Wikipedia has proven, there is also a proven crowd-sourcing model for creating knowledge. Enterprises have surprisingly not harnessed this power. Customers who are consuming the knowledge know whether it works or not. However, the only way for them to provide feedback usually is thumbs up/down or give us feedback or fancy google way of point-me-the-area-and-tell-me-the-problem (click on “Send feedback” to experience the workflow). The problem with all these approaches is that the feedback (if ever given) goes into a black hole (at least from the point of view of the submitter) leaving no incentive to take this action now or in the future.
Possible Fix
A Wikipedia-like approach (with verified customer login) enabling customers to edit the knowledge inline and changes to be verified and then published for all customers could actually work here. Additionally, rewarding the submitter with a public acknowledgment or some sort of points (gamification) could also make knowledge generation fun. Maybe these points are counted for free entry to the vendor’s conference etc.,
Another disenfranchised entity in knowledge generation is also the Channel partners. Channel partners understand products deeply (especially the ones who deploy products and also support them) — however, any knowledge they generate is currently limited to that partner only. Partners can be incentivized to share this information through the vendor by adding partner branding to the knowledge (good quality knowledge will funnel more end customers to that partner versus other partners). This approach can also help to fill the gap of knowledge creation in local languages (countries like Japan have a huge focus on localization of knowledge).
Knowledge access is full of friction
Customers, channel partners and even employees expect to get answers quickly and without any friction which means they expect the answers in their current workflow. However, that is rarely the case today.
For SaaS products, that workflow is within the product. However, the only knowledge that resides within the product is the technical documentation which is the description of what the feature does and how to configure it. Technical documentation is not written with the problem-solving perspective. Another problem (and this is strange but understandable) is that this documentation is not easily accessible within the product — the user has to leave their in-product workflow and go to a different website, re-authenticate themselves, and then do a grudging treasure hunt for knowledge. This is an absolutely terrible experience for the customer exacerbated by the fact that this treasure hunt works only 10% of the times (from my conversations with the support leaders, issue deflection on portals hovers around that number). That means for the rest 90% of the times, customer has to spend time documenting their problem, file a ticket with no clarity on when the issue will be resolved. Worst, some customers just churn. This is an absolute nightmare both for customers and the vendor.
Possible fix
A way to fix this would be to bring knowledge to the product (instead of taking the user out of the product throwing them in support portal maze). For this to work, one needs technology that understands what the user is doing inside the product, who they are, and use this context to find the best matching knowledge (could be technical documentation, white paper, a video essentially anything) and surface that knowledge inside the product.
For new customers who are browsing the company’s website, there are questions around pricing or packaging, or features — they are usually handled by data sheets or chatbots. This is an area that could use significant improvement. Inside sales reps and Sales Engineers can help by surfacing the kind of questions customers ask and creating an NLP like interface to the knowledge bank.
Knowledge gets stale quickly. In fact, very quickly
Transition from Hardware to SaaS delivery model has also resulted in rapid releases with new features being released as quickly as on a weekly or even daily basis. This has introduced huge challenges in both knowledge generation and maintenance. A knowledge piece that was relevant yesterday may not be relevant today. Companies today have no way to know which knowledge has become stale. Instead, they do the following — on a quarterly basis, they look at view counts of knowledge articles (on support portals) [this approach excludes other knowledge like technical documentation, etc.] and articles with the highest views are reviewed manually for that. This approach is not scalable and error-prone as well.
Possible fix
Though this kind of technology doesn’t exist today, it is possible to match knowledge with product screens and when product screens are updated, the technology can automatically flag articles that may require an update. This proactive approach for refreshing knowledge can help reduce the problem of stale knowledge.
Summary
Effective creation and consumption of knowledge stand to benefit not just customers, partners but internal employees as well. Any organization that puts a strong focus on this low hanging fruit stands to gain tremendously by increasing both customer loyalty and employee productivity.
