Tools for Creating Happy Users by Tom Limoncelli and Christine Hogan
I only joined the class in the afternoon, so I can not report on the material covered in the morning. Below I have taken some notes on the topics I found most interesting.
Handling Support Calls
The first topic was "handling support calls". Tom made a case, that handling support calls can be taught and is not just something one knows or doesn't. On the first level, each call can be broken down in to: Greeting, Whats wrong? Fix It, Verify It.
After the greeting, the second step is to get a complete problem statement. Where, When, Who, What? No special tech knowledge is required here, just social skills, active listening and probably some checklists. A complete problem statement will make the actual problem solving much simpler.
Getting a problem statement is already quite sensitive. Eg. one should never ask things which encourage the user to lie: "Is it plugged in?" is bad. Better: "Lets check both ends of the power cord". When a problem statement has been created the problem has to be verified/reproduced/scripted, because otherwise there is no way of verifying the effectively of an eventual fix.
The third step is where the tech/fixing skills are really important. In trying to find a solution, it can be helpful to involve the user into selecting which approach is taken, to fix the problem, and thereby taking their situation (eg time pressure) into account. Keep in mind that you want to know what caused the problem to go away, so only do One thing at a time.
The forth and probably most important step is, that both the person who fixed the problem and the user who reported it verify and agree that the problem has been fixed.
Unless you monitor something, you can not call it a service!
Customers rely on the services we provide, so if there is a problem with one of the services, we should know before the customers do. "Yes, we are already working on it, we expect to have this fixed by 10am, we will send out mail when it works again." is much better than. "Oh, for how long has the company website not been working anymore?"
Monitoring allows to find patterns in breakage, it assists in capacity planning and if combined with a knowledge base, solutions to known problems can be shipped out with the alarm.
My points: Optimize the monitoring for the case when all is well, because this is the state it will run most of the time. Don't have the monitoring system take 'counter action' because this leads into to the 'nanny trap' where successive layers of software are fixing the problems of the underlying system instead of fixing the root cause of the problem. Check out (isg.ee.ethz.ch ...) and also (people.ee.ethz.ch ...) for two tools in this area.
Want to learn more?
Incidentally Tom and Christine have written a book: The Practice of System and Network Administration (www.amazon.com ...) which expands on the soft topics of system administration.