How can you improve the customer experience though knowledge management, you might ask? From an incident perspective we should start with the Service Desk to determine exactly what types of calls are coming in, a “top ten” of sorts. These may be common questions that, if they are handled through some form of self-service functionality, can reduce the calls into the Service Desk right at the beginning. It is likely that your Service Desk has some of these available already.
Part of the journey to be able to accomplish this will be to put forth some dedicated resourcing and regular review through reporting. If everything starts to go as planned, you will see a reduction in many of the previously escalated issues as they are addressed by knowledge records. It will be essential to be able to measure the amount of usage that your knowledge base has in an effort to make further improvements, as well as to line up to other departments’ metrics as it relates to the overall continual service improvement initiatives.
As we work to reduce service-affecting incidents through knowledge management we also need to look at incident KPIs. For example, the current MTTR of incidents can help us to determine a baseline of our mean resolution times, but we can review the information provided in the incidents themselves to assist us in areas of improving the resolution times. Is there information available that we could leverage to facilitate a quicker resolution?
Like anything worth doing, there are going to be some obstacles. While the initial pieces are beneficial to the Service Desk, we need to start thinking long-term to being a better business partner, which is where having a collaborative knowledge culture is critical. This part is not as easy. Some of the challenges may include the following:
There are people who believe that, if they are in control of the knowledge, they are in a better position as the “go-to.” In reality this is not the case; they end up spending their time fixing the same work over and over again rather than working on something that may provide better value in the long term. In a collaborative space we should ensure that the information is not only available but relevant as well.
Making knowledge part of the way we do things
People can be change-adverse so they will see this new activity as “more work,” or they might say, “I am not a writer.” We aren’t necessarily looking for Pulitzer material, but think of it in these terms: Suppose that we could reduce 10 calls a day simply by having a knowledge record available. Further to this assume that each call for that same issue is approximately 5 minutes. That works out to 50 minutes of work that could have been taken care of by spending 10 minutes of writing a knowledge article—40 minutes’ worth of savings. Making knowledge a part of the incident, problem, or even change process could have a domino effect in redundant work expenditures. It could be as simple as a record doesn’t close until the knowledge record has been created.
This will be for nothing if we cannot report on what we are seeing. We should be able to track through our knowledge repository what issues were corrected with the knowledge records (no incident created), as well as how many incidents were resolved as a result of knowledge. Being able to quantify the success of the knowledge process will position us better to make further improvements on future activities.
Gathering feedback on the information in our knowledge can be easy, but managing the output of that feedback may be more difficult. If we are soliciting feedback, we may need a way to respond to those that are supplying it. Some foresight may need to be applied to this before proceeding, so my advice is to keep it simple to start.
In the end you will be in a position to review and make adjustments where needed. You will also be in a far better place to work with the customers for these issues. Allowing you to further understand their business will enable your other ITSM processes to make improvements as well.
For more brilliant insights, check out Ryan’s blog: Service Management Journey