Philosophy of tech support

A few observations on working in technical support.

  • Make sure you understand the user’s underlying need. Sometimes you’ll get a request asking to do one thing, when the user has actually taken the first few steps in thinking through solutions themselves, and is asking you to solve that problem rather than their real problem (which may be much simpler.) There may be a simpler, more elegant solution to their problem if you know what they’re trying to accomplish.
  • Make it easy for users to describe their problem. For example, keep network drive assignments consistent across the board (The T: drive should always point to the same share). Colour-code printer names; it’s a lot easier to say there is a fault with “the black printer” than with “the Kyocera 2100D near where Jacqui sits.”
  • Provide frequent feedback. If you are dealing with a fault, let the person requesting the fix know that it’s still being worked on, even if little progress is being made. Communication is key.
  • Underpromise and Overdeliver. When asked what benefits will be provided, be conservative about the benefits and timetable, but try to deliver more than was promised and ahead of time. If you promise a feature in one week and deliver in two, your users will be unhappy. If you promise delivery in three weeks and deliver in two, they will typically be happy. This leads to a related point…
  • Don’t overestimate yourself. I’ve found most technical staff (including myself) will underestimate the time taken for any given task. Most commonly this is because they haven’t taken the time needed for testing & debugging into account. When making an estimate, remember your limitations. For nontrivial tasks, your first impulse should be to double your initial estimate.
  • Complaints are golden. Any complaint is a vote of confidence in your ability to solve a problem. If your users are very quiet it may not be a good sign – your users may have given up on you as a source of help.
  • Don’t be afraid to inform users of the scope of a request. As technical staff, when asked to do something or if something is possible, our initial response is initially to say “yes, but…” People don’t hear the “but”; they only hear the “yes”. Couch your answer in terms of costs, or answer “effectively no”. If your answer is “That will take eight hours’ work; are you sure you don’t want me working on (some other important problem) instead?” most people will decline gracefully.
  • Don’t always turn down the hard requests. This is the flipside of ensuring that users know how hard a request is. It can sometimes be tempting to tell somebody that a job that is merely difficult is impossible.Taking those jobs will stretch your skills and, if done right, substantially benefit your user base.