Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ico!nbires!isis!aburt From: aburt@isis.UUCP (Andrew Burt) Newsgroups: comp.sys.pyramid Subject: Re: The Quality of Pyramid's Service Message-ID: <2623@isis.UUCP> Date: 2 Sep 89 14:44:21 GMT References: <17531@bellcore.bellcore.com> <82731@pyramid.pyramid.com> <30529@mirror.UUCP> Reply-To: aburt@isis.UUCP (Andrew Burt) Organization: Math/CS, University of Denver Lines: 60 In article <30529@mirror.UUCP> roskuski@prism.TMC.COM (Barry Roskuski) writes: >In article <82731@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >>were doing. In addition, RTOC's objective is to fix your problem as rapidly as >>possible. Assuming that you made a mistake, and trying to figure out what, is >>not only a human reaction, but it will be accurate and get the problem fixed >>very quickly most of the time. > This is an extremely dangerous assumption to make. This is a great way > to turn off the customers that *do* know what they are doing. I sat for > about an hour watching an RTOC engineer remotely dialed in to my system > duplicating the EXACT same steps I had told him I had done to diagnose > the problem and getting the EXACT same results I reported to him. Is that > getting the problem fixed as quickly as possible?? Pity he should believe > that I just _might_ know what I am doing. I don't think reproducing the problem is a bad first step at all. I would say communications was lacking, however: He should have said, I want to make sure I understand what you told me the problem is, so I want to duplicate it. I.e., phrase it in a way that implies the FE wants to make sure he didn't forget about a step in writing down the problem, etc. If it takes an hour just to get to the point of failure, it is reasonable to assume the conditions for failure are complex. What if you accidentally forgot one small step? E.g., you wrote down the steps after it happened, and one just slipped your mind? If the FE assumed you were 100% right your problem might have taken twice as long to fix, with the first 50% being caused by not having the right information. But the issue is the same: don't treat the customer like a moron. Make them feel they are completely right, that there is definitely a problem, and you definitely want to get to the bottom of it. "The customer is always right" works for support too. >>Personal credibility *does* help. If Bob Sutterfield or Greg Noel call, most >>people here know that they really know what they are doing, and most likely >>have a real bug. Clearly, some people reporting the problem understand their own problem better than others. Perhaps the support people should inquire into the background of the person reporting the bug. If they're a kernel hacker there's a good bet they know what they're saying. Just by way of small talk find out what experience the caller has. I would also add that customers should not have to follow up on problem reports. If a customer reports a problem, that should be all they need to do until they are informed what they have to do to fix the problem (e.g., "a tape is on the way, put the fixes in place"). Someone said something to the effect that if the customer wants it bad enough they should keep bugging you. Very bad attitude. Customers have much better things to do than deal with bugs. Even if it's their own damn fault, they still perceive the problem as yours, so it becomes part of the job description to accept that some people are messed up and you have to be nice to them while they tell you it's your fault. -- Andrew Burt uunet!isis!aburt or aburt@du.edu "Now go away or I shall taunt you a second time."