aNewDomain.net—It’s 2013 and remote access aka remote support is now standard fare in most IT departments and consulting firms. For many end users, this technology still seems magical and not for them. The specifics of the technology is not visible to users, so they don’t fully understand how simple it is for support staff to correct something with a remote session. “I just didn’t want to bother you” is a common response from users when I ask why they didn’t ask for help. If only end users understood how easy this was, many issues could be addressed early on.
Image credit: Jeremy Lesniak for aNewDomain.net
Remote access, for many end users, snuck into the IT world. Unlike other technologies that directly affected users, like faster Internet access or larger hard drives, remote access products such as GoToAssist or LogMeIn Rescue just popped up. In the history of technology, most end users have only just begun to experience remote access. This means users don’t know about it.
There are lots of ways you can train users to use remote access for support requests. If you’re able, allow users to initiate requests from software or a website. Having those issues immediately handled is also important. Once a user experiences a quick response and resolution to a problem, he or she will likely remember to use remote access again when a problem arises. You can also send an email explaining the benefits of updating your end user support protocol document (if you have one).
One common issue tech support professionals face is the end user’s concept of what constitutes a severe problem. While a user understands the relationship between logging a support request and resolution, he or she may not understand the universal benefit of reporting minor issues. I can guarantee that support professionals have heard users offer up symptoms foreshadowing failure after the catastrophe occurs. “I heard my computer making these clicking noises, but I was on a deadline,” or “I was getting a few pop-ups, but I didn’t think it was a big deal.”
How do we get users to report these problems?
There are a few factors here, and most of them are cultural workplace situations.
First, the IT department can never make a user feel that the problem they report isn’t worth reporting. The moment a user feels foolish for requesting support is the moment you’ve lost him or her. Every problem needs to be checked out and seen as a relationship-building opportunity, no matter how insignificant it may seem. Take the reports as opportunities to educate users on what to look for, and make sure it’s in a way that makes the user feel like an important part of the resolution process.
Second, problems need to be addressed quickly, if not immediately. The longer users wait, the less likely they are to report problems in the future. If the user feels that the issue reported isn’t getting the appropriate attention, it’s just as bad as making him or her feel foolish. If a problem can’t be resolved right away, immediately communicate that to the user. Set an expectation for when the problem will be resolved and stick to it.
Third, end users need to be educated on what to watch for. The main reason that precursor symptoms aren’t reported is because users don’t understand the consequences of ignoring them. Training users on how problems can creep up is important. A good way to educate users is in small groups, but a short document with bullet points and easy non-technical language also works.
Remote access has dramatically changed IT by reducing costs and head counts. It has also taken a lot of the personal relationship out of support interactions. Show end users how to partner with you to make remote access more effective, and you’ll make everyone’s lives easier and reduce stress in your job.Cloud Computing,Productivity,Technology