I recently suffered through a frustrating hour of trying to unsuccessfully add a URL link to one of my blog posts in WordPress.
Let me first defend myself by saying: I’ve been using WordPress for quite a while; I’ve added dozens, if not hundreds of successful URL links. But suddenly, this particular link kept redirecting to my blog instead of to the desired external page. Surely this was a WordPress bug. (It couldn’t possibly be USER ERROR!)
I looked at WordPress forums and did a search for similar problems, to no avail. I finally contacted a WordPress-savvy friend. I explained my problem, and he didn’t have an immediate solution. He asked me to record a screencast of my process, which I did with ScreenFlow. Upon seeing my screencast, he immediately contacted me and told me I was forgetting to put “http://” in front of my URL.
DUH! Yeah, OK, I felt really stupid. (And again, let me defend myself by saying: Of course I know that – it was clearly a case of caffeine-deficiency rendering me unable to complete basic thoughts.) Even though I explained my problem to him, what it finally took was a simple screencast for my friend to see what I was doing wrong and put me on the right track.
This made me want to herald the virtues of screencasting as a tech support tool.
Go beyond simple communication
Getting to the bottom of technical support problems often involves the user describing to the support technician exactly what he or she is doing. Even with the best communication skills, when someone who is frustrated and been trying to solve a problem for awhile describes his problem, he can easily leave out critical information – either because he doesn’t know it’s critical, or because he’s already eliminated it as a possible problem during his own efforts to solve the issue.
In my case, I kept telling my friend I was “entering the URL”. As a user, I was frustrated and SURE that my problem had something to do with WordPress. So, when I explained my issue, the last thing on my mind was that I was doing something wrong. From this perspective, it is easy to see how minor details can easily be left out during a conversation. When there are native language differences between the user and the technician, this can make it even more complicated.
Having the user create a quick screencast to detail his or her process can mean the difference between a frustrating support experience and a successful support experience. Especially helpful for a user to include in a screencast is a shot of your software version number, or browser version number, or any other operating system or configuration that the support tech will need to help diagnose the issue.
A tool for both the “supportee” and the “supporter”
My example was from a user perspective, but screencasting can also be useful for helping support technicians demonstrate solutions to issues as well. Here at Telestream, our support department is using ScreenFlow more and more often to help demonstrate to users how to solve their issues. Rather than trying to describe the step-by-step procedure(s) for fixing a problem, our technicians are whipping up short ScreenFlow demonstrations, with basic narration, to describe and demonstrate the solutions.
The added benefit is that they then have a ready-made answer for others who call in with the same support issue, saving them lots of time.
So the next time you have a support issue, I suggest making a screencast, to help you get answers fast!
Have you used screencasting to help solve a tech support issue (either as a user or as the one providing support?) What has been your experience? What advice would you give to anyone using screencasting to help them get or give support?