The Quality of Pyramid's Service

[Carl S. Gutekunst]

A couple of armchair observations, from the hacker in the corner.

In article <17531 at bellcore.bellcore.com> tr at pcharming (tom reingold) writes:
>In some cases, the person handling my problem felt that since it had not
>been reported yet, it must not be a problem and that I must be doing
>something wrong.

Out of all the complaints I've ever heard about *any* field service organiza-
tion, this is by *far* the most common. And there are very practical, human
reasons behind it. RTOC takes thousands of calls every week. Greater than 90%
of them are User Brain Damage: the person calling didn't understand what they
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.

The non-trivial skill that has to be developed by the person answering the
phone is to rapidly identify that small fraction of the calls that are really
reporting problems. And it *is* non-trivial. Some people do it exceptionally
well. For others, they have to work at it. Patience is the byword here; you
*are* talking with another human being, after all, and over the telephone you
lose 70% of the communication that goes on in a conversation.

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. We have other people (who shall remain nameless to protect
the guilty) who have cried wolf so many times that it becomes very hard to
take them seriously. 

>In other cases, my problem is simply dropped.  I assume that RTOC assumed
>that since I didn't hound them constantly, it ceased to be a problem. This
>is very unprofessional.

You're right, this in unprofessional, but I don't believe that RTOC made any
assumptions. What I'm curious about is how often this happens. When I was a
Pyramid customer, we did have occasional problems we never heard about again.
They were all very trivial problems, although of course they weren't trivial
to us. :-) On my first day as a new employee, I was immediately handed a
stack of my *own* SPRs, so I then knew what happened to them. (I think they
called that poetic justice. At least one of those I closed as UBD, too.) 

In other words, problem reports that disappear aren't an RTOC problem; they
are either (occasionally) a Sustaining Engineering problem, or (more likely)
an R&D problem.

>They should go over their list again and again, checking back on each item.
>When something is resolved, it should be scratched. If it's not resolved,
>it should be review again....  Yes, they have a tracking system. But another
>computer vendor I deal with CALLED me to make sure that the bug fix he sent
>me worked.

On a regular basis, Sustaining Engineering runs through all the outstanding
SPRs. Someone then checks with each R&D manager for status. (This happens when
a customer calls in pounding on the table, too.) What would seem to make sense
to me is if we automated the process such that *customer* notification occur-
red in the same periodic fasion. In addition, no SPRs would be considered
"closed" unless the customer verified them.

This latter part is already done for high priority bugs. It could be difficult
and expensive for normal priority bugs, the sort that are simply fixed in the
next release (instead of a PTF). And most of them really *are* trivial; but
confirming it takes just as much labor as a more serious problem. Right now,
the bug is "closed" when the resposible engineer says it is; and as far as I
know, every computer company with more than 50 employess does it this way. Of
course, just because someone else does it a certain way, doesn't mean it's
"right." 

>My complaints above and many others were brought to our salesman's attention.
>He agreed that the service we have been getting is "a crock".  Those are his
>words!

Well, yeah, but any salesman would do that. It's called "ingratiation." :-)
It's his job to be on your side, and to advocate your position.

I would certainly *not* call Pyramid's field service "a crock." I've been
serviced by too many computer companies for that, most of them far worse than
Pyramid on its worst days. But there is always room for improvement. Indeed,
this is the whole reason I susgested that customers pound on the table in the
first place. Cranky customers bring about positive changes.

<csg>