Button pressers and non-button pressers

I have often wondered what separates the people who support technology from those who use it. I got my answer in a most surprising place this weekend.
——————————————————————————————————————-

I was in the local co-op supermarket in Swanage when I overheard a snippet of conversation between two elderly ladies who had caught the technology bug.

First lady: “My Grandson has just come back from his gap year; he said he was going to bring his photographs around, but he only brought a CD with him.”

Second lady: “I thought CDs were just for sound….â€

First lady: “No, Elsie dear, apparently you can put any kind of files on them. He put the disc into my DVD player, and the photos came up on the screen!”

Second lady: “Really?â€

First lady: “Oh, yes; he plays DVD films on his laptop as well. I thought they were just for writing letters on.â€

It got me thinking though; most of what I know and understand about technology is what I have found out through pressing buttons to see what happens. There are those people who are happy to press buttons, and those who have a strong need to know what will happen before they press the button.

How many times have you received a call from a user asking what would happen if…? The usual way to answer the question (if you don’t already know the answer) is to try it and see.

If someone asks how to do a particular task, you open the application and work it out. It seems obvious to us as support people, but you have to have the mind-set that allows you to experiment and take risks.

This allows us to amass the experience to help others and to take the risks on their behalf. I analyzed some of the logs raised by our team and found that they were almost exclusively reporting failures. Advice calls are not common, because we are a team of experimenters and “suck and see” people.

Other teams that use the help desk may have a different problem profile, which got me thinking that it might be a good idea to have a separate phone number for advice rather than fault reporting. This would help us to keep a separate log of help calls, which could be used to supplement user training or identify the users who could use some extra help.

I firmly believe that the role of the help desk is to grow the skill sets of the user base, to identify trends, not only in system reliability but for gaps in knowledge, to generate shortcuts that can save time, and to share other generalized knowledge.

By reviewing the help calls, you can use the information you amass to create proactive support tools, like FAQs, post a “Tip of the Day” on the help desk intranet page, provide extra input to the user training program, or include in the new starter’s induction day.