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

26.1.2 pg 551 & 552

"Why does this person keep calling me with the same question?" That's the question that leads to the customer being called a "luser"; not that they ask questions but the same question time and time again; they demonstrate an inability or non-desire to learn. The SA has to be able to distinguish between those with an inability and those too lazy. Personally, I don't believe there are any that are incapable of learning, merely those who don't want to (for whatever reason), and those do end up wasting SA time.

To avoid being caught in the "do everything for the customer trap", I go in with the attitude "Just because I can do it, doesn't mean I should; let's teach this person how to do it themselves so they don't have to ask again." If you get a good customer then they are happy to learn from you!

At my first job I had such a customer; he wasn't too savvy about computers but was willing to go that extra yard and try to solve his own problems before calling me. I'd spent a fair few sessions scribbling out diagrams of how things fitted together to explain why things work the way they did (teach them the infrastructure fundamentals, they'll understand the more complicated stuff easier). Sometimes it was specific to our setup, other times just more general "how things work" diagrams. After one session I screwed up the paper and threw it away. He looked astounded, fished the paper out and smoothed it out claiming he wanted to look at it more. A couple of years later he retired, and as I was helping him pack his personal stuff up I spotted a box full of scrap paper. Glancing in I saw it was all the scribbles I'd done over the past four years. He'd kept them and liked to look at them in an attempt to learn more about computers. They were so useful to him that he was taking them home, including the screwed up piece of paper I tried to throw out!

26.1.3 pg 553

I've found that when working from your desk spending the first few minutes on the phone with the customer, basically talking out loud and saying "Hmm, that's interesting" or "Huh, it shouldn't do that" or similar, and then after 5 minutes telling them that this needs more work and I'll call them back when I have information is a great way of making the customer happy; they know you have prioritized their emergency request because you're looking at it "live" while you're on the phone to them.

How to automate pg 559

One thing to be careful of when automating procedures is not to try and cover each and every weird corner case. If you can write an automation script that will perform user account creation and meets 80% of the requests, then do it! Don't try and solve 20% of requests that require a more complicated configuration just now. That can be solved in the next version of your program!

-- StephenHarris - 28 Aug 2006

BUT: if you automate 80% of the requests being handled, it becomes even more important to document the heck out of the cases which require manual handling, and to make it clear how to escalate a truly weird case to someone with deep knowledge. This is because

(1) the process is being done far less often, and so your staff will soon forget its nuances (2) you're making it so that your sysadmins never see how 'normal' cases are handled -- they'll have no baseline against which to compare the broken cases with which they're being confronted. Which is great -- as long as they can have good docs to read and know how to escalate to someone when they're really lost.

I guess I'm saying: sure, automate to the 80% level, but be sure to document to 100%. Well, okay, 95%

-- BenjyFeen - 01 Sep 2006

That's a good and important point; automation never replaces documentation; automation augments documentation. Every piece of automation must be documented so people know what it does and why it does it; what you would have to do if you were to do the same job manually etc etc.

-- StephenHarris - 01 Sep 2006

Something that came to me last night; some automation tasks may not speed up tasks. For example, if it takes a week (40 hours) to automate, test, rollout something that can be done manually in 5 minutes and is only done once a week then it will take many years to recover the time spent. At least that's how it looks. The benefit of automation, however, is in knowing that you've done the job correctly each time and that you won't make mistakes. A mistake could turn that 5 minute task into an hour task and impact other departments. By automating it you've added reliability and consistency to the system.

-- StephenHarris - 30 Aug 2006

26.2.5 pg 563

The newsletter can be a link to a web site; the same web site that hosts the status page. That newsletter can link to the status page, and the status page can also link to the newsletter archives.

-- StephenHarris - 28 Aug 2006