home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / 18417 < prev    next >
Encoding:
Internet Message Format  |  1993-01-01  |  4.0 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!sgihub!zola!zuni!anchor!olson
  2. From: olson@anchor.esd.sgi.com (Dave Olson)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Frustrated with SGI support..
  5. Message-ID: <ubbh8go@zuni.esd.sgi.com>
  6. Date: 1 Jan 93 19:04:49 GMT
  7. References: <34842@adm.brl.mil>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 70
  11.  
  12. In <34842@adm.brl.mil> andersen@marvin.ama.ttu.edu (Kim Andersen) writes:
  13.  
  14. | I have several SGI systems, all different models.  I was very happy with
  15. | the hotline service the first couple years - they were very speedy and
  16. | knowledgable.  HOWEVER, response time has increased dramatically (coupled
  17. | with a seeming decrease in competence) over the past year and a half.
  18. | Ever since 4.0.X was released.  Now I don't bother to call the hotline
  19. | anymore because on the rare occasion that I get a return call, they have
  20. | no clue anyway.
  21. | 
  22. | Sorry, guys, but that's my experience.
  23.  
  24. Well, along with 4.0.X, came the Indigo.  Between a whole new set of
  25. of software to support (X11 and Motif), and many thousands of new
  26. machines (and therefore customers), the support folks got rather
  27. swamped.  It took them a while to hire (and train!) enough additional
  28. people to catch up with the load.  Yes, they knew it was coming, and
  29. tried to staff up ahead of time, but it turned out much worse (in terms
  30. of numbers of machines and calls) than was expected.  That explains
  31. much of the response time changes.  On the other hand, they changed
  32. procedures (and are still changing them) to try to reduce the time to
  33. the first callback.  They haven't always succeeded, but it has gotten
  34. better overall.
  35.  
  36. Any of you who have ever supported software and hardware, either
  37. as part of your job or informally, know that the greater the number of
  38. products, the harder it is to even train people to ask the right
  39. questions about the problem, let alone to answer them.
  40.  
  41.  
  42. I'd also like to address another theme that has gone through
  43. this thread.
  44.  
  45. I don't understand why *anybody* expects that the support people
  46. would be able to answer everybody's questions (at least on the
  47. first call, or maybe even the second)!  After all, I have (not
  48. to be overly modest) a pretty wide breadth of knowledge of SGI's
  49. software and hardware, and there are plenty of things it would
  50. take me some time to find the answer to, or even to find out
  51. who would know the answer.  I also know that sometimes it takes
  52. 3 or 4 exchanges to even get enough info to find out what the
  53. problem is; some people seem to want you to pry the info out
  54. of them.  I'm sure they don't see it that way, but believe me,
  55. any of us answering questions, either as part of our jobs,
  56. or informally, see it that way from time to time!
  57.  
  58. Sometimes the answer is just "it is a bug in the released
  59. software, we don't know when it will be fixed, or how to
  60. workaround it".  While that may seem to customers like the
  61. support folks don't care, that is the answer that they get from
  62. the R&D engineers.  To their credit, they will push back when
  63. they get that answer, and if they start getting a lot of calls
  64. about a particular problem, they push even harder to get a
  65. better answer, and hopefully a fix or workaround.  Even so,
  66. sometimes it just goes on the open bug list.
  67.  
  68. So, if you don't call support because you think you won't get an
  69. answer, you have only yourself to blame if the bug/problem/lack
  70. of features persists into the next N releases.  Sure, if we see
  71. complaints of a problem on the net, *usually* somebody will turn
  72. it into a bug report if we decide it is one (or even just fix
  73. it then and there for the next release), but you can't count
  74. on that happening.  In addition, some groups of engineers are
  75. far less likely to read the net than others, and those of us who
  76. do may not have any idea whether it is a bug or not if it is in
  77. an area with which we aren't familiar.
  78. --
  79. Let no one tell me that silence gives consent,  |   Dave Olson
  80. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  81.     Maria Isabel Barreno                        |   olson@sgi.com
  82.