Tech support is a key to our future.

Our role in tech support has evolved slowly but surely as our operations have moved online. It's sneaked up on us and now it's a part of our (often unstated) mission. I suppose you could say it's the law of unintended consequences at work. Put something online, and people will have problems using it, so the type of support we provide has undergone a transformation. We're a service profession and providing help is in our blood, so we forge ahead and try to solve problems that are laid at our feet. We're accidental tech support staff.

In this entry, I'm addressing technical problems that are on the remote users' end, not ours. If the problem is ours - a service is down, a database doesn't connect, a link is broken, the link resolver has an error, an ILL request didn't go through - it is obviously our responsibility to get the problem fixed and the steps are pretty clear.

Let's consider support from a different, more interesting angle: problems with remote users' computers and network configurations that interfere with access to and use of our resources and services. Here, the situation is more murky.

Are we responsible for these problems?

Based on anecdotal evidence, I'd say that the answer is Yes. (I wish there were good research on this topic.) There seems to be pretty widespread agreement in our profession that if we offer something online, it's our responsibility to help with technical problems on the users' end. Maybe it's just me, but I find this development in librarianship to be quite interesting. We're willing, at least on some level, to address problems with someone's operating system, personal firewall, pop-up blocker, browser settings, wireless connection, and other factors that can interfere with access. And it's not just IT staff who are presented with these problems. Complaints can come to anyone, especially staff at public service points. We're all in this together.

How important do you think this type of tech support will be in five or ten years' time? Correct. And it's important now. Given this, it's surprising that many of us handle these activities with procedures that are, well, hardly procedures at all. For the most part, in my library, this type of support just happens based on who gets the question. Sometimes the targeted staff try solving these problems themselves, sometimes they forward the issues to staff who might have the expertise to deal with them. Certain problems are sent to a listserv tracked by IT staff. Some staff are trained in problem solving, some are not. It's a hit or miss proposition.

A lot of what happens in my library is based on common sense. I'm all for common sense - when it works. I've seen plenty of off-campus problems get solved quickly and accurately. I've also seen enough users get the run-around, enough library staff unsure of themselves when solving problems, and enough solvable problems go unresolved, to know that something is not quite right.

Here's an example of the problem. A few years ago in my library, we worked out a set of procedures for a handful of staff who would be handling problems with electronic resources. It was a good idea. These problems included off-campus access, broken links in the catalog, connection problems, subscription issues, and so on. My role was to handle off-campus access issues because I manage EZproxy. What interested me about the exercise was the fact that the nature of my off-campus support went entirely undefined. What types of problems, exactly, was it my responsibility to solve? And on what level? I was given no guidelines. In fact, the issue wasn't even discussed. If I chose, I could refuse to deal with certain issues as being out of scope. I've never done that, but theoretically I could based on this lack of definition and oversight.

To begin to address this problem I might, for example, propose that we purchase copies of the most common personal firewall software, establish a knowledge base about this software, and provide users with step-by-step configuration advice when problems arise. Most likely this proposal would be rejected due to staffing and fiscal constraints. That's fine. But talking about it would help us establish an agreed-upon level of service: We will attempt to identify a remote problem ("It's probably your firewall, and you should check the cookie settings.") but not provide step-by-step help ("In Zone Alarm, first click on the Privacy option."). Knowing the paramaters of our support service would be helpful in managing expectations for both users and staff.

One admirable example of how to do tech support well is described in a 2002 article by D. Scott Brandt, "Automating Your IT Help Desk" (Computers in Libraries Vol. 22. No. 3, 52-55). Purdue University Libraries have made a solid commitment to tech support. I realize that we all can't attain this level of sophistication. But many of the concepts for good support are laid out well in this piece. The accountability aspect is particularly well done.

And so: let's be clear about the types of tech support we'll provide to remote users when the problem rests with their technology setup. Let's determine who will provide this support, and at what levels. Let's be sure that staff on the front lines are sufficiently trained to handle common questions and make appropriate referrals. Let's provide decent Web-based FAQs to assist with basic, recurring issues. And by all means, let's conduct regular assessments.

If your library has worked out these issues, my hat's off to you.