Users are going to need help, it’s inevitable.
On the heels of the last post, I’d argue that seeing support cases is a sign of effective adoption (well, that’s probably a bit of stretch, but, it *could* be accurate in *some* cases!).
Supporting your users through their system journey is key. If you’ve been following along, you may recall the tidbit from the Training Framework post about ‘teach a person to fish, you feed them for a lifetime’. Well, sometimes the fisher-person needs some help getting the line untangled. We want our users to feel motivated and confident, even when they have questions.
What is the Point of Support?
First off, let’s ask ourselves what the point of supporting the user is. In my opinion, there are two key types of support:
- Functionality issues (product – as in, the system isn’t doing what it’s supposed to)
- Knowledge gap issues (user – as in, the user isn’t doing what they’re supposed to)
In both cases, it’s important that the user feels heard and you acknowledge you are aware of the issue. To this end one could gather that the point of user support is to ensure your users know you are there for them.
If it’s functionality related, you are going to need time to triage. Users want to do their work, so this requires a bit of a balance. In my experience the simply acknowledgement that you see their note about the problem and are aware provides assurances that you/the team are “on it”. I find these don’t need to be lengthy or complex – a simple “OH! Thank you. I’m digging into it now to get a sense of what’s going on!” can suffice.
If the issue is a knowledge gap, we’re in a slightly different ballgame, though there are some consistencies. First off, you may not realize it’s a knowledge gap item just yet, and triage it the same way you would a functional issue. Upon your own test you confirm it’s working as intended, and as such we now enter a period where we need to support the user through that knowledge gap.
This can be done with a quick explanation, or screensharing call to walk them through the process, pointing them to support resources that exist for the area of the system they are struggling with, or a combination of these things. Sometimes how we respond depends on how they approached us.
Oh The Ways To Reach You…
There are various ways incoming support requests arrive from your users….
They could ping you in Teams or another form of IM.
They could email you.
They could open an internal case.
They could call you.
They could yell over the office divider to you.
They could send you a carrier pigeon with a note.
They could swing by your office with candy or donuts or coffee and dangle it just out of my grasp until I answer their question (may or may not have happened before…to a friend. Ya, an admin friend. That.)
I think the manner in which you handle incoming support calls from your users depends heavily on the volume of those users. Not solely because there are some important data aspects you should consider which we’ll talk about, but generally speaking if you have two users and they are in close proximity the framework for user support is going to look very different than a user base that is geographically spread out.
But the underlining theme to whichever method you choose is that you need to demonstrate patience and a genuine desire to help. Predictability is key so users know what to expect when they put forth a request. This helps disarm users. I don’t mean users are angry or hostile, but let’s not forget that until they ran into this problem they were on their way to do a task to accomplish a goal and the fact they ran into a hurdle means they cannot complete that task therefore not reach that goal. They could be stalled until you get to them.
It’s More Than Troubleshooting
One of the considerations you may want to make about how you accept support requests is around how the data of those requests can help you. The most obvious scenario is that by collecting insights about the request, you can review those to understand trends in user behaviour or challenges with the system design.
Example: If users are constantly getting stuck on how to input information into a specific part of the form, perhaps the form design needs a review.
But like all analytics, depth of data is important. Just because one person had trouble finding that section on the form does not necessarily mean a revamp is needed. Read the example again – constantly. That’s an important word as it signifies that we have a recurring issue, and when we have a recurring issue we should seek to prevent that issue from arising all together.
I talked about user adoption and engagement in the previous post. If you’ve successfully engaged your users to the system in a way that fosters their desire to drive it’s efficiency and effectiveness, they are going to be vocal when issues arise, which is important to ensuring that the admin team can become aware of the issues so they can start to triage and diagnose the issues quickly.
Collecting data on the support requests also provides a window into the effectiveness of your training resources. If you have documents and videos created to help users through common issues, but you keep getting questions about those things because people aren’t using the resources, it begs the question if the users understand how to access those materials. Are they in a central or, better yet, logical location? Do users know they exist? (Remember: folks are busy – just because you told them a resource exists when you created it a year ago doesn’t mean they remember it’s there). If they ARE all those things, then it might be time to review/re-watch yourself and see where the disconnect is.
A Word on Support Speed
While it’s important to acknowledge the request in a timely fashion, this also comes with a dangerous caveat – if you respond and solve every situation immediately, your users are going to grow accustom to this and, in my experience, it breeds a sense of “don’t look for the answer, just ask and we’ll get the answer back right away”. This actually does everyone involved a disservice because there are going to be times when you/the team can’t respond right away. Particularly as systems grow and there are chunks of planning and new development needing attention.
How do we combat this? Set the expectations accordingly. Be open with your users – you can’t fix every issue that comes up in record time. You have other tasks and are juggling. Their requests are extremely important to you, but you need to balance your time.
Perhaps you set specific days or times that you spend on issue resolution. Or you set an auto-response on your case form that tells people you will read the item within the next X hours/business days/etc.
The point here is to be open and honest with your users about resolution times, as sometimes being the person who responds immediately to everything at all hours can be a curse on many levels. I speak from experience.
What are some of your staples when it comes to supporting users? Do you agree with what I’ve laid out here? Disagree? I am really interested in hearing what YOU do! Drop a line in the comments or join the discussion on social related to this post!
We’re all learning. Why not learn together?!