tr@pcharming (tom reingold) (08/31/89)
What I am about to say does not reflect Bellcore's policy but definitely does reflect the opinions of many people at Bellcore. Pyramid's service is not good enough. I have called in many problems to RTOC. 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. I wonder what does constitute a problem in that case. If reporting it doesn't carry credibility, why have RTOC? 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. We pay big bucks for support. Dropping problem reports is not what I call support. Carl S. Gutekunst (csg@pyramid.pyramid.com) writes: csg> Don't keep it to yourself; make sure you RTOC knows when you have csg> problems like this! If you already have told them, tell them again. And csg> tell them that you already told them. :-) I should not have to do this. They should see to it that a problem is fixed. 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. That's what I do to support my users. csg> Generally RTOC and Sustaining Engineering do a terrific job of bug csg> tracking and fixes. csg> [...] Not good enough. 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. He said he had to keep calling me until I said yes before he closed the call. In fairness, I am giving them another chance. (I don't have a choice. We have lots of money and time invested in these machines and can't scrap them easily if we wanted to.) 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! He put the screws on some people at Pyramid, there is now an increased effort to help us. Whether or not they will succeed in the longer term is yet to be seen. I should not have had to put screws on anyone at the rates we pay. Scott Hazen Mueller (scott@zorch.SF-Bay.ORG) writes: sm> Let me second this most vigorously. When I was at Pyramid working in sm> the RTOC, I recommended to several customers that they not only report sm> their problems, but that they call in frequently for status updates. As I have said, this should not be necessary. I do it because I have to. But that's my labor that I think we have paid Pyramid to spend. sm> Since I don't work for Pyramid anymore, I can also feel free to advise sm> you that if you aren't getting adequate response out of RTOC, call your sm> salesman. If you are planning on buying anything additional from sm> Pyramid and can threaten to hold the order up, you're in a great sm> position from which to deal with them :-) I've spoken to our salesman, and yes, this worked. But we don't have any purchases planned now in my area (where I run two Pyramids). Then what would you suggest? We have about ten or twelve Pyramids in this company. Should we have to threaten? Should anyone have to, even if he has only one? Tom Reingold |INTERNET: tr@bellcore.com Bellcore |UUCP: bellcore!tr 444 Hoes La room 1H217 |PHONE: (201) 699-7058 [work], Piscataway, NJ 08854-4182 | (201) 287-2345 [home]
scott@zorch.SF-Bay.ORG (Scott Hazen Mueller) (08/31/89)
In article <17531@bellcore.bellcore.com> tr@pcharming (tom reingold) writes: [Tom states that Customer Support Engineers should follow up all calls; that every problem should be worked until resolved; and that he should never have to call in the same problem twice.] Ideally, all problems get followed up and resolved. Ideally. In reality, some problems get dropped in all support organizations. Your half of the deal is to show continued interest in having your problem solved. For complex software problems, RTOC serves only as a contact point into Sustaining Engineering and R&D. RTOC engineers by and large don't have the time and the expertise to dig into complicated system software problems, no offense intended to my former co-workers. Once a problem has been referred to Sustaining, it becomes merely one of a *large* number of open SPRs they have in work. In order to maintain priority of one problem, the customer *must* take an interest in getting it fixed. You are not Pyramid's only customer, and the time and attention of the backline support people gets focused onto those customers who squawk the loudest. RTOC's database provides collective memory, but that is no guarantee that you will reach the top of the priority queue. >Should we have to threaten? Should anyone have to, even if he has only one? If you'd like to debate the basic philosophy of customer support, we can do that in email. If you want Pyramid to fix your problem(s), you'll swallow your dislike of the facts and work within the system. That's all that Carl and I are saying. We're not saying that's its right or wrong to have to pressure RTOC or Sales - just that we know from experience what works. You're under no obligation to take advantage of our experience at Pyramid; but when dealing with a sales-driven organization, you use the strategies appropriate to that sort of organization. >Tom Reingold -- Scott Hazen Mueller| scott@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott 685 Balfour Drive | (408) 298-6213 |Mail to fusion-request@zorch.SF-Bay.ORG San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email
csg@pyramid.pyramid.com (Carl S. Gutekunst) (08/31/89)
A couple of armchair observations, from the hacker in the corner. In article <17531@bellcore.bellcore.com> tr@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>
roskuski@mirror.UUCP (Barry Roskuski) (09/01/89)
In article <82731@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >A couple of armchair observations, from the hacker in the corner. > Well, here's another hacker in the corner doing some real life observations. >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. > >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. > Are we one of those who have cried wolf??? I started here at Mirror Systems in April, right in the middle of our worst problems with our system. RTOC would not look at them blaming everything on our bad power. We got the bad power fixed, and low and behold THE SAME PROBLEMS WERE STILL THERE!!!! Sure gives me a warm fuzzy feeling about the credibility of RTOC. They are getting fixed one by one now, but I resent the fact that we had to wait through 3 months (plus probably more time before I arrived) of crashing a minimum of 3 times a week without anything being done about it. Well, enough complaining for one morning. Let me say though, that I have had much better experiences with the customer support of other computer companies. At least they didn't let me know that they assumed I was an idiot. Also, I have done a limited amount of customer support myself. I understand that yes, the customer is wrong a good deal of the time, and just needs to be gently corrected, but you just can't let people know that you think they are fools. It is not good for customer relations. In all fairness too, our last few calls into RTOC have been handled in a much better manner. Of course, our FE had to light a fire for us to get any response on one of them. Maybe we are just getting better people on the other end of the phone lately. > ><csg> ---------------------------------------------------------------------------- Barry J. Roskuski Mirror Systems 2067 Massachusetts Ave. Cambridge, MA 01240 roskuski@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!roskuski
markd@rtech.UUCP (Mark P. Diamond) (09/02/89)
From article <82731@pyramid.pyramid.com>, by csg@pyramid.pyramid.com (Carl S. Gutekunst): > > 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. 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. Maybe it is not a bug in your system, but if someone is having a problem maybe you have poor documentation, maybe the installation instructions were not clear, maybe you are not listening to what the customer is really saying. Try an experiment: you are a user of a pencil. If you are right handed, try writing with your left, or vice versa. What? It's awkward? Can't do it? You've been using a pencil for many years, what is the matter with you? Are you "brain damaged?" As an engineer, if someone can't use my system -- for whatever reason -- I have a problem. It is incumbent on me as an engineer to make my systems usable to eveyone. Mark <> Mark P. Diamond {sequent,mtxinu,sun,hoptoad}!rtech!markd markd@rtech.com " 9.17 sys3b SYSTEM CALL (SYSTEM V) * * Every book should end with a good joke." -- Marc J. Rochkind, Advanced UNIX Programming
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/02/89)
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@rtech.rtech.com> markd@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>
aburt@isis.UUCP (Andrew Burt) (09/02/89)
In article <30529@mirror.UUCP> roskuski@prism.TMC.COM (Barry Roskuski) writes: >In article <82731@pyramid.pyramid.com> csg@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@du.edu "Now go away or I shall taunt you a second time."
hassler@ASD.WPAFB.AF.MIL (Barry D. Hassler) (09/05/89)
Might as well throw my two cents in this fray for all its worth too.... I currently am pleased with RTOC's support for the most part, but that was not always the case, and there continue to be exceptions to this. Pyramid seems to have done an awful lot of work in the past year and a half in beefing up RTOC and improving is ability to respond properly to customer complaints. However, by the tone of some of the other responses to this subject thread, maybe they are just treating the organization for which I work differently (Control Data/IIS is a large VAR of Pyramid with installed systems scattered across the country, and for which we are responsible for administration and on-site support). Tom Reingold complained in his original posting that he constantly has to hound RTOC to follow up on problems, and Carl Gutekunst agrees this is the "right" thing to do. While I agree that constant hounding is sometimes necessary, it shouldn't have to be. Maybe I'm lucky, my "rep" inside RTOC (I ALWAYS call the same small group of individuals - they are familiar with my particular systems, their use, and their configuration) does follow up with me. When I am in a "critical stage" (ongoing problems impacting performance of the system(s)), they generally follow up on the order of at least once per day. This should be the norm - RTOC following up with the customer on the status of SPRs. Working with Users as I do occasionally, I must agree that MANY problems are really just User Brain Damage (to quote Carl Gutekunst). I can certainly imagine it is difficult for RTOC to weed out those situations from the other "real" problems. This is another reason why I alway's ask specifically for one person at RTOC whenever I call (and a few alternates). These few people know that when I call, the chances are that it is a "real" problem (I humbly admit to a recent case where I should have "RTFM'd", but didn't and was rather embarrased by the answer). I don't think Pyramid condones this as the norm, but it certainly works for me. All in all, from my standpoint, RTOC has greatly improved over that past year or so. We (Control Data, IIS) used to have to make high level phone calls from our management into the upper levels of Pyramid management to get problems resolved. At least for those systems I am more-or-less in touch with that we support (as well as the few I am directly responsible for), the situation has improved greatly. I am also fairly certain Pyramid is aware that RTOC still has some work to do in improving its responsiveness to the user and is working in that direction. Naturally, the opinions expressed above are my own, although I believe they represent those of my employer and others within the organization (how's that for a disclaimer?). -- Barry D. Hassler hassler@asd.wpafb.af.mil Control Data Corporation (513) 427-6369 Integrated Information Services Project Leader, ASD Central Datacomm System Wright-Patterson Air Force Base, Ohio
royf@pwcs.UUCP (Roy Forsstrom) (09/05/89)
In article <3535@rtech.rtech.com> markd@rtech.UUCP (Mark P. Diamond) writes: >From article <82731@pyramid.pyramid.com>, by csg@pyramid.pyramid.com (Carl S. Gutekunst): >> >> 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. > >This attitude really bothers me. Users are not stupid. Engineers, technical I agree! UBD may be an inside joke for RTOC, but it is a bad attitude to have come out in any way when dealing with customers. I've had an RTOC 'engineer' say..., well never mind. I was commenting on the documentation and the fact that not everyone has worked with pyramids before, some have vax and sun experience behind them. If RTOC can't handle the routine questions, then they should make sure the information is getting out some other way, email, newsletter or even a phone call. So far I've had pretty good service from RTOC. Yes, requests have been lost and such, but at other times I get the impression that one of the 'engineers' is spending all day just on my difficulty. That's more than I would expect from any of the other vendors I deal with. -----------------------------------+------------------------------------------- Roy Forsstrom 612-298-5569 | What are the Rights of Man and the Public Works Computer Services | Liberties of the World but Loose-Fish? pwcs!royf royf@pwcs.StPaul.GOV | - Moby Dick -----------------------------------+-------------------------------------------
linda@cc.brunel.ac.uk (Linda Birmingham) (09/13/89)
From a Brit's view UKRTOC has improved considerably in the last year or so. From my view this is greatly because of the appointment of an excellent person on the telephone support side of things who asks all the right questions and makes all the right noises when user brain damage is discovered. Thanks Deeko. I believe it's also because of re-organisation of the team which allows the problem solvers to beaver away uninterupted. However, when problems have to get sent to the States they seem to take a long time to get solved. I have constantly complained about the quality of PTF's and the osx one STILL overwrites my adapted accounting stuff (like /usr/.attlib/acct/holidays). BTW my accounting stuff is adapted 1) To cope with our number of users and 2) Because it doesn't do the accounting correctly. So to summarise, I think UKRTOC have an excellent team but appear to be poorly supported by the States. Linda. -- Brunel University, Uxbridge, Middlesex, England. janet: linda@uk.ac.brunel.cc | :-) uucp:...ukc!cc.brunel!linda |