NO MORE UPDATES TO THIS PAGE PLEASE. SUBMIT ALL FUTURE COMMENTS TO

Random comment: one of my teammates once said: "We don't do customer service -- we do patient care." It's true, too. If a man wanders into a hospital bleeding profusely and asks for morphine, he's more likely to get the help he needs instead of the thing he requested. Customers will often ask for particular solutions instead of reporting their problems, and it's our job to gently delve into the underlying issues. Sure, handing out morphine results in happy customers, but only in the very short term; sometimes the trick is to hand over a leeeeeeettle morphine while you bandage their wounds.

-- BenjyFeen - 16 Sep 2006

Comparison, pg 303

Another theory (of mine) in why SA training needed to mature is in the nature of who is now an SA. Originally an SA was someone who was interested in computers, had experience of the system, has been a user, has been a developer, has debugged his own code and application and systems and so became an SA with experience and a good intuitive grasp of the processes. Today people get into computing as a job and jump straight in as SAs without much more experience than running their Windows desktop. Very few of them even installed Linux or a BSD on their home PCs, let alone ran their own server somewhere. Because of this an SA has to be trained in process and procedures, even needs to gain actually skills.

Or maybe I'm turning into an old fart and being condescending to the new young whippersnappers

-- StephenHarris - 17 Aug 2006

16.1.2 pg 305

Note that sometimes the SA is the customer when dealing with other departments help desks; eg when calling the NOC. It's important to treat both your customers and other help desks with equal courtesy and politeness.

16.1.2 pg 308

Re the ping issue (paragraph 2) "All other information is superfluous". Err, in this example, no. Other useful information could be if machines on the same subnet can see each other OK, if machines on different subnets are having the problem etc. For example I had periodic (about noon, every day) trouble reaching a server in my lab. Ping times were 5s or more with 90% packet loss. Additional useful information was that machines in the lab could see each other OK and that machines in London, New York, Delaware and Singapore were all having trouble seeing the lab. It can be very difficult to determine superfluous information!

Re putting the customer on the defensive and printer problems (pgs 308 and 310). An anecdote.

At my first job we used serial printers hooked to terminal servers, with the Unix servers making "reverse telnet" connections to the terminal server. This was a legacy of older machines which only had serial ports and no networking. SunOS^? kernel issues meant that data could be lost under certain circumstances. Due to this complexity it was expected to have a printer problem at least once a month, thus it came as no surprise when one of the cleverer users phoned telling me that his month-end reports weren't coming out of the printer that was only used for this purpose. I checked the queue; empty. I ran a test job and it spooled correctly and sent the data to the printer and cleared up. I went to the printer to check the output, and found it not there. A quick visual inspection showed no lights on the printer and tracing this fault led me to find the power cable had been unplugged from the socket (I theorise the cleaner used it for her vacuum). I plugged it in, powered it up and tested; all OK. When the user asked me what was wrong I told him "It was unplugged; someone unplugged it; it works OK now. I blame the cleaner." Next month, same user, same problem. This time the problem reported included "I even checked to see if it was plugged in!" Investigation showed that it had been turned off at the switch. The user felt embarrassed that he'd missed such obvious faults both times that he bought me beer at lunch time. By not cricising the user and by keeping him in the loop he learned from the experience (I never got another call about that printer) and we remained on friendly terms.

Step 7 pg 313

"The dialog has to be adjusted"... Beware the customer who thinks they know a lot. You might tell them to do X, but instead they'll do Y; not because they misheard you but because they thought they knew better and thought you were wrong. Always verify that the customer has done what you asked them to, eg by getting them to read out the first line of the file that you've asked them to open in the editor.

-- StephenHarris - 18 Aug 2006