So you’re invested significant resources into a self-serve IT support platform so that it can run on autopilot for the lowest value tasks, but it isn’t working. You have bought a brand new wiki/knowledge base solution like Confluence, but for whatever reason it is underutilized. The same thing happened when you chose your ticketing solution (like Jira Service Management). Its as though it doesn’t even exist because everyone seems to just ask for help in the #it-support channel in Slack.
It just doesn’t make sense. Everyone knows that Confluence and JSM are there, but no one uses them. The volume is becoming unmanageable and resources are being wasted on a solution that should work. Something has got to change.
This common problem has less to do with the software your team has procured and more to do with a lack of workflow continuity that is steering support seekers away from the desired outcomes.
Self-serve support tools aren’t optimized for workflow
The reason most self-serve support strategies fail is because they are too many degrees of freedom away from existing support seekers workflows. It seems like a small ask to request that users access a webpage to search for knowledge or create a ticket, but unfortunately, it isn’t. Support seekers will always take the lowest effort path, even if it creates more work for others (whether intentional or not). If you want to solve this problem, you will need to ask yourself a very important question, and that question is…
Where are questions asked?
The first question one should ask themselves is, where are support questions asked? Do you know? If not, look and listen for evidence of where that is. Is it over email, telephone, Zoom, in-person, on Slack… or somewhere else entirely?
Go and look. We’ll wait till you come back.
Have you found it? Now stop right there. Put a stake in the ground. Your journey is complete. X marks the spot. Mission complete. This is exactly the location where you need to concentrate on.
It seems simple, but the place where support tools need to be injected is at the exact place where support questions are asked so that they don’t have to go anywhere different or find another tool. If you have an existing self-serve support tool it must integrate with this spot in the workflow or it will almost certainly fail. If your existing tools don’t integrate with this touchpoint, chances are you’ll need to find a third-party integration that achieves the desired outcome. Trust us, if you have identified this point in the workflow as a location where support questions are asked, almost with certainty, someone else has found that too, and tools do exist to remedy the problem.
Since many companies are opting for remote or hybrid-remote work arrangements, support questions are commonly asked in virtual channels, such as internal messaging platforms like Slack. “Shoulder taps”, as they’re known, have shifted from telephones and in-person interruptions to Slack because its asynchronous convenience. Moreover, support seekers can attach evidence with screenshots or recorded video to add context to their “asks”. You likely even have a dedicated channels for support questions related to IT, customer inquiries or HR. These channels are fine for infrequent use, but once scaled, they become unmanageable and requests often get missed, which stagnates productivity.
Wherever your support questions are asked, its time to seriously consider and evaluate solutions and strategies that inject support workflows at that exact location.
The best self-serve support strategy is one in which support seekers always self-serve knowledge first, then explore other channels. So that means that the self-serve support workflow must begin with at least some attempt to check if there is path to resolution that does not involve any other people whether they are support agents or other employees.
Now, recall the location where support questions are asked in your company? Let’s turn our attention back there. The key to success in putting knowledge-first is putting knowledge access exactly where support questions are asked.
Take for example the example one of the most popular internal wiki solutions on the market: Confluence. Part the Atlassian suite, Confluence is a very robust knowledge management tool, but arguably its biggest downfall is that it fails to integrate well with common workflows like self-support in Slack. Since more and more knowledge workers are spending their days in Slack, its just easier to ask questions there instead of leaving to enter the same query in Confluence. Ultimately, if you choose to continue to use Confluence, you’ll need to find a tool that enables Confluence search in Slack.
Optimize knowledge for speed
When you are already dealing with the delicate situation in which your support seekers are refusing to use existing self-serve support channels because its simply easier to “ask in Slack”, you must be careful with how knowledge is served. By choosing a knowledge format that is optimized for speed, support seekers will be less incented to steer away from self-serve support. Sometimes referred to FAQs in the support space, repeated questions that require low value interventions need to be instantly accessible directly from the places where questions are asked.
There are times when self-serve support is impossible, even after a cursory knowledge search is completed. For example, consider the situation where a support seeker needs help setting up a VPN connection. Let’s envision the optimal process for when unsuccessful self-serve support should lead to self-serve ticketing. By creating their own ticket, support seeker can avoid asking agents to do so needlessly whether that is over the phone, email or in Slack.
What you don’t want happening is for there to be a knowledge gap identified and the support seeker simply asks the question in the channel anyway because, as with knowledge search, its simply too many degrees of freedom away from the current workflow. If it is too difficult (beyond just one or two clicks), the user may just default to the counterproductive behavior.
Optimal self-serve ticketing workflow
Creating tickets is not the entire endgame for enabling ticketing functionality in Slack. There is more nuance to it, and here is a more optimal workflow to strive for:
- Search (from within Slack) for knowledge related to VPN connection issues.
- If a knowledge gap is unearthed, it should be identified by the support seeker to request closure for future support issues.
- The gap is logged and the IT helpdesk is notified of a request to update the knowledge base.
- The support seeker is prompted, from within Slack, to create a ticket.
- A simple form is filled out and the IT helpdesk is notified and the support seeker is tagged with updates on the ticket status.
Unfortunately, JSM does not have a deep integration with Slack currently, but there are tools that enable JSM ticketing in Slack to make this a reality.
If your self-serve IT support strategy isn’t working as well as it should be and your helpdesk agents are inundated with Slack messages that are getting lost in the #support channel, you don’t have to give up JSM and Confluence, it can be fixed via deeper integration with Slack.
Hey before you leave, check out how a 2 minute video on how Obie helps internal support teams get the knowledge they need fast – it’s the Fastest Video Demo EVER