Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!hpuamsa!frank From: frank@hpuamsa.UUCP (Frank Slootweg CRC) Newsgroups: comp.sys.hp Subject: Re: HP Customer Support... Message-ID: <7810021@hpuamsa.UUCP> Date: 6 Dec 89 08:39:29 GMT References: <203@limbo.Intuitive.Com> Organization: HP NL Lines: 119 Dave (Taylor) and *others*, I think we are getting somewhat closer to the right approach. As I indicated before UNIX/HP-UX customers generally want something else then HP SupportLine can currently offer. I basically agree with your proposal : >[possible scenario: HP sets up a bank of 800 numbers for their > customers, each being assigned a specific UUCP account & password. However we *also* need solutions for non-US customers, Internet users, etc. This is a complex and hence expensive matter. That does not mean that it should not be done, it just means that is should be well thought out, both from a technical and a financial/business standpoint (see later). >>- Patches *are* available (through the Response Center) between major >> releases. This mechanism was set up at the *same* moment we reduced >> the frequency of releases (on request from our customers!). > >Right, but the information dissemination problem is one of the main >things we're talking about here; how do we, as customers, know about >the patches and workarounds? Reading the SSBs is not a viable >solution, calling our SE's weekly isn't a viable solution, and >using HP SupportLine isn't viable either since it's not even an >announced element of HP-UX support strategy yet. Again, our current indication is that *most* customers do not want to get bug/patch information and associated patches for "all the problems they don't have". They do want HP to help them solve the problems they *do* have. This does not mean that we should not listen to the "minority" that does want the info/patches but we should get some grip on the number of customers that want this, how they want it, etc (see my earlier postings). This info *has* to be channeled to HP in a structured way (that is why I proposed Interex). A few people expressing their wishes or "demands" in a mainly technical *public* forum like "comp.sys.hp" is not going to do the trick. The audience in this forum on both sides are mainly technical people. Responses from HP are mainly one engineer trying to help out another (not a *supplier* helping a *customer*). Most of the HP posters do *not* have direct (note "direct") customer support as their job (I am the exception in this string). If you don't like *that*, then you should try to change it, but again in a structured way. I will do my best on the HP side to try to let people pay attention to what is being said in this forum. You and other customers should combine forces and express your concerns to HP in a structured way. It can only be done *together*. >The problem here is that HP is being, as Tom Peters might put it, reactive, >rather than "proactive" on these problems. I am the first to admit that a company can never be proactive enough. However you should also realize that HP's support products have generally been leading edge in our main markets (both technical and adminstrative applications, however mainly in companies and company-like institutes, less in universities etc.). The latest examples in this area are the various CD-ROM based support products. > That's exactly what is being >pointed to when we see things like patches that you have to call and >explicitly request, meaning you've already had to hit the problem and >spend the time needed to ascertain that it's an OS problem, not an end >user application problem. And that's just not a good solution. Again, this is *not* our experience. At least not in The Netherlands, even not, generally, for universities and other leading edge users. In any case you will have to determine if it is an OS problem or a user application problem *when* you encounter the problem. Being proactive can shorten this troubleshooting process but can not eliminate it. If you want to be proactive then, as said before, you have to "wade" every time through all the bugs (most of which you will probably never encounter). Most customers don't want this hassle (the principle is called "Return On Investment" (i.e. "How much time must I spend repetively to save some time when I have a problem?")). The customers that do want this proactive bug/patch info and patches should speak up in a structured way. >>- Indicate how they want it (*without* creating a liability and/or >> exposure problem for HP (see Dave Waller's and my previous response). > >Liability is no different if the patch is posted versus mailed on >a magnetic tape (with the caveats about spoofed news articles and >the limitations of commercial use of Usenet: see my suggested >solution above that solves both of those problems) *I* am not so concerned about liabilty. Every company, so also HP, is concerned about (negative) exposure, that is what I meant. Perhaps exposure is not the right English term. What I mean is that we do not want everybody (i.e. also non-customers, competitors, etc.) to have detailed information on the bugs in our products. We are not alone in this standpoint, our competitors have the same, it is just common business-sense. Note that we use the word "defect" instead of "bug" (both internally and in our documentation/communication to the customer). "Bug" has a too nice ring to it. Your car does not have a "bug", it just does not work, it is defective. Summary : - We are making some progress in reaching concensus in this forum. - What is needed next is - More volume (i.e. customers sharing the same needs). - A detailed technical and business proposal that satifies the needs of most of this customers). - A structured way of expressing these needs to HP management (R&D, sales, marketing, support, etc.). From the world of customer support, Frank Slootweg, Hewlett-Packard, Dutch Customer Response Center. Disclaimer: Only speaking for myself, not my employer. P.S. Give Dave and me a break. Let's here some more from other customers and HP employees (especially in support).