[Originally published 3/29/2023 via LinkedIn]
I like to be hands on and technically curious about, well everything. When I was a kid, I loved to take apart anything electronic, figure out its innerworkings, and put it back together (not always successfully). It drove my parents crazy (one particularly irksome discovery for my mom on a Sunday night was a half-disassembled alarm clock). In my role as a support leader, I’m often reading through active incidents to understand technical issues my team is dealing with. Sometimes I ask a lot of questions (although I think they hide if they see me coming) which gives me good context internally with product and other stakeholders.
Sometimes the incidents come to me, in the form of an escalated customer issue. I remember one such time when the customer was irate, demanding to speak to someone who could explain why their technical issue had languished for nearly two weeks before a simple resolution was provided. As I looked through the issue history I started to understand why she was so upset, and then wondered how this could happen. A relatively simple setting in a custom template wasn’t syncing with the backend cloud component, which a service side refresh quickly solved. Except that in this case, the entry tier techs had no resources with that information, so it went to the advanced tier engineers where it bounced around until the one person who had solved this for other customers saw and resolved it.
This was several years ago, and at the time we didn’t have a consistently used knowledge-based tool or process for capturing or sharing technical support information like this. We had a lot of very smart and capable support engineers, but too much of the depth information to address incoming customer issues like this one resided in their heads or in notes they curated in silos as reference. When we analyzed the related data, the custom template syncing issue was something customers encountered on a regular basis, and drove a low but consistent volume of support contacts- each of which took a similar long path with similar customer sentiment about our handling of it.
Deploying a Knowledge-based platform dramatically transformed our ability to resolve issues quickly at a significantly lower cost and with higher customer satisfaction.
Fast forward to present, having pivoted our entire lens for analyzing the issues instigating support contacts, our knowledgebase platform has enabled 50% higher issue resolution at entry tiers, raising first contact resolutions and lowering overall end to end resolution windows – both with tangible cost associations- while spiking customer satisfaction with faster and more incisive fixes to the issues they encounter. Moreover, we have a rich dataset we can share with engineering teams to drive the highest impact product fixes, eliminating them for customers altogether. It’s a closed-loop win-win.
Our earliest knowledge strategy and deployment was targeted for online and phone channels, but the much larger opportunity lies in extending a knowledge platform to power self-service, chat and other proactive and digital channels as an analytics driven contextual ecosystem. Tools like Coveo, Search Unify and others can powerfully knit knowledge creation and use endpoints together in countless ways to meet organizational needs.
One piece of a support portfolio
What I’ve often found in my work is that in complex environments like customer support, there rarely is a single silver bullet that can move the needle on nuanced operational outcomes. I know I titled this like it is one of those silver bullets- and it can be for aggregating technical support information- but more commonly there are various connected levers that work in tandem, and knowledge is certainly one of those within a set of support capabilities across tools, process, analytics, CRM, training, quality management, people development and others.
It’s also a major lift to plan, deploy and manage a knowledge framework effectively and to provide the intended capabilities and outcomes. Our experience was that the change management needed to create the competencies and skills around writing, editing, keywording, curating and integrating knowledge content usable by internal and customer audiences, and enabling all this constantly within existing support workflows was time intensive and required significant project management. It was a growth curve, to be sure.
The industry standard KCS framework includes extensive content, resources, whitepapers and training around all the aspects of capturing and sharing knowledge, structuring knowledge for searchability and usability, curating and re-using knowledge and the organizational, structural, cultural and process components that are all necessary to standing it up and operating it successfully.
But from a cost-benefit standpoint, it can pay huge dividends in terms of cost-to-serve, customer satisfaction and retention, data driven product improvement and support lifecycle maturity.
Today, that angry customer I spoke with wouldn’t have to wait for two weeks for her resolution- she wouldn’t encounter it because we used the data to prioritize the impact and fix, but if she encountered something similar, she may get knowledge-generated in-product help, or could use online self-serve help, or if she needed to contact support, she would quickly reach a support tech via chat, web or phone with ready access to the knowledge to resolve her issue.