As a developer, let me start off by saying that I hate meetings. Oh, don’t get me wrong. I understand why they are a necessary evil… but that doesn’t mean I have to like them. I’m always watching the tipping scales of productive time lost versus time spent in meetings.
A particularly irksome brand of time piracy revolves around meetings scheduled to address issues that were resolved in the past. I’m not talking about the “let’s discuss why we went with this approach meetings.” I’m talking about the “I’m pretty sure this a brand new issue that isn’t actually a brand new issue meetings.”
The resolution for these issues may be found in closed tickets or (shudder) in emails and archived meeting notes. Unfortunately, there may be no way for your users to know about the prior issue resolution. So they raise an issue with your support desk and the issue gets escalated.
At this point you may be asking, “why doesn’t someone familiar with the previous issue just speak up?” It’s entirely possible, and actually quite likely, that the composition of your support team and development team has changed enough that no one has even a vague recollection of the previous issue.
So now people scramble and a meeting is scheduled to deal with the issue. Sadly, this is a frequent occurrence that I have had to suffer through on many occasions, particularly during peak usage periods.
If only there were a way for users to see the solution to their issue before contacting the support desk…
Good news!!! If you are using Jira Service Desk (JSD) and Confluence, there is. You can link a Confluence knowledge base space to your JSD, allowing users to search for issue resolutions themselves. This is incredibly useful for issues as simple as determining if a user’s browser version is incompatible to more complex issues like configuring user settings. You can even include step-by-step guides and tutorials in the knowledge base.
Now you will have happier users, developers and support teams.
Developers, this next bit is for you: Make sure to update the knowledge base when you deal with an issue that may benefit your larger user base. You will normally be the expert here. The knowledge base is only as good as its contents. If it is not continually updated and groomed, it will be a useless tool. So be diligent. In the long run this will help reduce your meeting/ticket/email load and let you focus on what you should really be doing… writing code unfettered by unneeded meetings.