Now its almost December, we can begin to think about cheery stuff like giving, sharing and helping others. One interaction that technically meets this description but may not be so cheery is your helpdesk queries and responses.
After about 10 years supporting IT in libraries, I feel the festive need to spread some goodwill and have tried to scrawl down a few tips to help Librarians and their systems support folk better work together.
I’ve tried not to patronise, all of the below is based on personal experience in several roles. I know we as help providers can often do better, but equally, things can go much more smoothly if we get useful information upfront and some effort to manage expectation is made.
I’ve also another angle. In the strange world of library systems and IT services, we make use of a lot of third party services and products. This often puts library systems people in the unenviable position of feeding one set of helpdesk requests directly into another, and sitting in the middle. So we know heldpesk frustration. As such, this is based on my experiences both as a user and provider of helpdesk services.
1) Be precise and be concise!
I’ve seen plenty of queries written up as two long conversational paragraphs with little factual data about the actual problem. This is often fun to read, but really wastes time at both ends. The first stage we attempt in diagnosis is often reproduction of a problem and we need hard facts and examples to do this. You will get a better, quicker response if you help us to reproduce problems, specifically:
a) Provide context. Describe what you would expect to see or occur, and what you get instead. Often, it may be the first time your IT support is looking at the software or use case you are presenting, so this can be invaluable
b) Provide clear examples. If web page URL’s or specific records or identifiers are involved, please list them.
c) If there are specific criteria or patterns associated with a problem, list these (i.e. it only affects undergraduates)
c) Provide details of your environment. If you are using a web browser, say which one and version. If you are outside of a University network, say so!
e) We may need to check log files, so time / date of trying something that failed is often helpful
2) “Could you just try turning it off and on again” …
It may be a cliche, but it works. So do please try turning things on and off first and reproducing a problem yourself. This includes restarting software apps, reloading browsers and rebooting PCs before trying again. You may get it to work, or equally, if you try this and still see a problem, you will hopefully reinforce in the mind of a helpdesk worker the possibility of a real bug or config fix.
If you can, trying to reproduce on a colleagues’ machine or via another web browser is also really helpful.
If the problem goes away, it should not prevent you from reporting it, but may give you a workaround and better help us diagnose the cause.
3) Use official mechanisms
Generic help-desk emails and phone lines may seem soul-less and full of jargon filled messages about response times, but we use them for a reason. Namely, we can cover in case of leave (holiday!), or give time to staff wanting to do other stuff, like improve or change things as well as fixing them. So please use them rather than direct emails or calls.
Equally, if you see us eating lunch or having coffee, don’t assume thats an open helpdesk opportunity. We need a break too. (And we really usually cannot fix your home PC just for fun, would you honestly ask a plumber for free advice?)
Lastly, if you get really frustrated or have a genuine emergency, do go knocking, but only if its ok to do so. If you are lucky enough to have IT support with an open door policy, then congratulations. I know of Sys Admins who live behind locked doors and intercom systems …
4) Understand what you are dealing with and learn about it
As I said in the introduction, many of the IT support folk you interact with are often having to play as middle-men. Even when working with open source or in-house systems, they will not necessarily have access to source code or the time to develop a fix straight away. Understand that a true solution may take time to provide. In many cases, you will just get a work-around. This is largely a by-product of economies of scale and a fact of modern life, no matter how frustrating it may be.
In many cases, F.A.Q.s and documentation will be made available directly to you. To a certain point, reading and taking these in is part of personal professional development, so at least give them a try in the first instance.
Libraries are now heavily focused around IT, they are not places for the computer-phobic to hide. Learning new things constantly is a necessary part of any IT workers’ job. To a degree, its now the same with librarians as well.
You can also try Googling a description of the problem or an error message. Without wishing to entirely remove the curtain from around the wizard, this is often a key strategy in our ‘effective problem resolution’.
5) Have perspective
Your problem may be urgent to you right now, especially if you have a deadline or angry user to deal with. However, do try and avoid ‘affirmative sentencing’ such as ‘this needs to be rectified as soon as possible‘ or ‘we need an immediate response‘ when an americanised label on a web page offends or an e-journal vendors site is down. Unless you really are the director of an institution, this usually just amuses, or winds folk up.
To responsible IT Professionals, real serious problems like downed systems or missing data generally fall into this category anyway and we would (or should) have automatic mechanisms for picking them up and maybe even dealing with them.
With that done, I would appreciate that you may have some opinions about your expectations as helpdesk as users. I do.
So in turn, here is what I think that you (and myself) as users of help-desks really should really should expect…
1) A useful answer in good time
Helpdesk queries that ‘fall between the gaps’ suck. This happens to me. Persistence in having to chase often pays off but seems to be a root cause in raising workplace stress. As such, you should always be entitled to an answer, and if not a satisfactory response or conclusion, an understandable and non-patronizing explanation as to why your needs cannot be currently be met, preferably with some tips for a workaround.
If service level agreements are in place regarding response times, they should be met.
2) A means of escalation / further support
Any service you use should have a clear line of escalation if you are not happy with an answer. This should be to a line manager of senior member of staff. Being polite and constructive here is the best way to get a response, rather than an outright attack on what may just be a harassed / overworked helpdesk worker on the front-lines. Explain what you need to move forward and what you felt was missing from the original exchange.
3) Your back covered
As librarians, most of your problems are often the problems of others, your readers and users. When those others are red and hot faced in front of you, they seem all encompassing, and sometimes never willing to go away. Ultimately, I think systems people should be able to provide some level of contact and backup in this situations, and even offer to deal directly with users on your behalf. This is a natural part of teamwork, after-all.
Lastly, if like me, you are also seen as a source of IT advice to extended family and friends, here is another great XKCD...