The Quality of Pyramid's Service

[Andrew Burt]

In article <30529 at mirror.UUCP> roskuski at prism.TMC.COM (Barry Roskuski) writes:
>In article <82731 at pyramid.pyramid.com> csg at 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 at du.edu

	      "Now go away or I shall taunt you a second time."