The Quality of Pyramid's Service

[Carl S. Gutekunst]

I said:
>>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 article <3535 at rtech.rtech.com> markd at rtech.UUCP (Mark P. Diamond) writes:
>This attitude really bothers me.  Users are not stupid. Engineers, technical
>writers and service people are stupid for thinking that they have built a
>system which is easy to use.

I didn't say anything about not *helping* the user. It's just that it if you
assume that the user made a mistake, rather than assuming a system bug, you
will be right almost all of the time. (UBD was a very poor choice of terms on
my part, since it implies that the response was to RTFM. Not at all.) Where we
(and everyone else!) can improve is in our skills at detecting when it really
is a system bug, thereby reducing the frequency of customers complaining that
their real bug reports are not being taken seriously. As I said, this is non-
trivial. Many UNIX utilities have abysmal error recovery, meaning that user
errors can produce behavior one would normally associate only with software
bugs, e.g., core dumps. 

Incidentally, mistaking system bugs for user errors doesn't even happen all
that often; but when it *does* happen, the customer feels put off, as if his
competance was being questioned. I think that's why it's so commonly mentioned
across the entire industry: even an isolated incident is very memorable.

As far as preventing those sorts of calls in the first place: There is no
question that UNIX documentation and user interface needs to be improved. A
lot. Sun and AT&T each have more people working on UNIX documentation than we
have in our entire R&D staff. Doing so will reduce the number of calls from
users. There will never be a day, though, when users will stop calling with
questions. IBM prints arguably the best documentation in the industry. I
thought Sperry did an outstanding job in their day, too. But they still get a
lot of questions from confused users. 

The reasons for this are multifold, but I'll site the two I see most often:

- Users regularly attempt tasks larger than they are capable of handling, or
  for which the lack fundamental skills. This is inevitable. DP shops are
  usually understaffed, with everyone having to wear multiple hats. So they
  have to try new things with little or no warning or preperation. When they
  goof it up or get stuck, and don't know what to do next, they call the
  vendor. (If the project is late, they may try to *blame* the vendor.)

- Users regularly fail to RTFM. There is no way around this simple fact. In
  the case of UNIX (and for that matter, IBM) this is often because they can't
  find what they are looking for, or because of previous unhappy experience
  trying to find something. That is the vendor's fault, and could properly be
  considered a "documentation bug." Unfortunately, this is the minority of
  cases. Even in UNIX. Fact is, a lot of people don't even try.

  UNIX also introduces another kicker: systems that are almost-but-not-quite
  the same.  I've lost track of how many times something blew up because one
  system didn't didn't act "just like" a Sun, or a VAX, or a Pyramid, or a
  3B20, etc. Of course, the user just proceeded in the way he was used to
  working.

In both cases -- even the RTFM cases -- a good vendor holds the user's hand
and gets them unstuck, and sometimes will refer them to an expert who can give
them the background information that they need to understand what they are
doing. That way, they can figure out similar future problems by themselves. 

The way to prevent calls about bugs, of course, is to never have any. :-)

<csg>