amanda@mermaid.intercon.com (Amanda Walker) (06/27/90)
In article <1990Jun26.192623.7121@efi.com>, tim@efi.com (Tim Maroney) writes: > maybe you could let the screeners know that if, say, Rich > Siegel, Amanda Walker, Gary Fitts, Joel West, Tim Maroney, etc., ask a > question, it should almost surely be passed along. Obviously, this has > problems too, and you might also want to extend it in the other > directions if a lot of someone's questions are RTFMs, but it's better > than nothing. Tech Support Triage like this might be effective, but I can't see much of a way to make it practical, not to mention palatable to the people who aren't on the "good list". Of course, some of this happens already on an informal level. For example, I have a small collection of Apple business cards and email addresses that enable me to call up an engineer and bypass MACDTS altogether. Since I know enough not to do so except as a last resort, they know that if I'm calling with a problem, it's (a) really a problem with their stuff, (b) serious, and (c) reproducible. I know enough not to waste their time, just as they know enough not to waste mine in similar circumstances. If I were to start abusing this privilege, my phone calls would start getting lost in Apple's Voicemail system... :-). I suspect that I'm not the only one in such a position. This is one of the benefits of going to things like trade shows, the DevConf, and so on. You get to know people. On a slightly less informal level, people and companies that have proven themselves end up working with evangelists, which is still a cut above the average Apple Partner who sits on AppleLink and goes through the standard queue. The biggest barrier seems to be getting a real live good product out the door. After that, Apple takes you more seriously. On the flip side, one of the things about forking over the yearly fee is that you get as much access to MACDTS as anyone else on AppleLink. This has its good points as well as its bad points. I also sympathize with the MACDTS people, since I know how hard it is to find good technical support people... -- Amanda Walker, InterCon Systems Corporation -- The customer isn't always right, but they do get an unnatural amount of slack.
minow@mountn.dec.com (Martin Minow) (06/28/90)
Having worked as a support person for six years (with corporate responsiblity for support of a major product for two), I can well sympathize with the problems MACDTS folk are going through. I would add a few comments, however: For "us": -- When someone in MACDTS (or Apple Engineering) goes out of their way to help you, send their boss a thank-you note. If you don't know their boss' name, send it to John Scully, with a request to pass it to the right person. This doesn't get you invited to Scully's barbeque parties, but it does end up in the person's personnel file, where it can give their boss an incentive to reward (salary) the helpful person. Send a thank-you note by real mail, not Email. -- Don't waste MACDTS time. If you're reporting an errror in their system "for the record," let them know. If you have a deadline "I need this answer by July 30," let them know that, too. When you report a problem, give them all the info: reproducible, which system/hardware, strange inits, etc. For "them": -- My experience is that triage really has to be done by an experienced person, mind-numbing and painful though it may be. If you rotate the task among all the MACDTS engineers, it becomes less of a chore (a half-day per month, perhaps). This keeps all the engineers aware of the kinds of problems folk are having. Give your triage person the job of writing/solving the easy problems. -- If the same problems crop up again and again, don't blame the dumb customers (RTFM), but blame the folk who didn't explain the system adequatly in the documentation. The recent set of sample programs is useful. You might also look at the Mark Williams C documentation for the Atari-ST: each "toolbox" function is illustrated by a short explanatory program. -- Don't forget, the customers are paying your salary. Martin Minow minow@bolt.enet.dec.com
keith@Apple.COM (Keith Rollin) (06/28/90)
In article <1718@mountn.dec.com> minow@bolt.enet.dec.com (Martin Minow) writes: >Having worked as a support person for six years (with corporate responsiblity >for support of a major product for two), I can well sympathize with the >problems MACDTS folk are going through. I would add a few comments, however: > >For "us": > >-- When someone in MACDTS (or Apple Engineering) goes out of their way > to help you, send their boss a thank-you note. If you don't know > their boss' name, send it to John Scully, with a request to pass > it to the right person. This doesn't get you invited to Scully's > barbeque parties, but it does end up in the person's personnel file, > where it can give their boss an incentive to reward (salary) the > helpful person. Send a thank-you note by real mail, not Email. Our boss is Dave Szetela. His E-Mail address is szetela@applelink.apple.com. > >-- Don't waste MACDTS time. If you're reporting an errror in their system > "for the record," let them know. If you have a deadline "I need this > answer by July 30," let them know that, too. When you report a problem, > give them all the info: reproducible, which system/hardware, strange inits, > etc. Yes! Oh yes! As a matter of fact, we're toying with the idea of letting the questioner assign a priority to their question, from 1 to 4. Initial reactions here are that everyone would put a #1 priority on their questions, but we've seen that MicroSoft has used this system with satisfying results. If anyone else out there - especially those with support experience - know of ways that we can more efficiently support 7,000 developers, please let us know. > >For "them": > >-- My experience is that triage really has to be done by an experienced > person, mind-numbing and painful though it may be. If you rotate the > task among all the MACDTS engineers, it becomes less of a chore (a > half-day per month, perhaps). This keeps all the engineers aware of > the kinds of problems folk are having. Give your triage person the > job of writing/solving the easy problems. This has been suggested, though never tried here. > >-- If the same problems crop up again and again, don't blame the dumb > customers (RTFM), but blame the folk who didn't explain the system > adequatly in the documentation. The recent set of sample programs > is useful. You might also look at the Mark Williams C documentation > for the Atari-ST: each "toolbox" function is illustrated by a short > explanatory program. This situation should be getting better. DTS makes an ever increasing effort to review all documentation that comes out these days. However, there's only 25 MacDTS people, and thousands of pages to review. Myself, I've got about 1500 pages of MacApp documentation to review. We have a rule of thumb here that says that we seem to average reviewing about 8 pages a day, so that MacApp documentation would take me 6 months to review. Given all the System 7.0 stuff I've got to grok before DTS can support you, it makes it difficult to do good manual reviews. But we do try. Tech Pubs is also getting the message. I can't really speak for them in terms of specifics, but I think that I can safely say that all your messages to them are getting across. > >-- Don't forget, the customers are paying your salary. I never do. Thanks for the feedback. > >Martin Minow >minow@bolt.enet.dec.com -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
chuq@Apple.COM (That's MR. Idiot to you) (06/28/90)
keith@Apple.COM (Keith Rollin) writes: >Yes! Oh yes! As a matter of fact, we're toying with the idea of letting the >questioner assign a priority to their question, from 1 to 4. Initial reactions >here are that everyone would put a #1 priority on their questions, but we've >seen that MicroSoft has used this system with satisfying results. I've found this generally works. Most folks are honest. It ALSO helps if you make it clear, up-front, that if you find someone putting bogus priorities on things then you'll summarily assign a priority of 3 or 4 to everything they send in, even if it IS important -- self-policing with a nice stick for when people can't police themselves. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Wherefore could I not pronounce 'Amen'? I had most need of blessing, and 'Amen' stuck in my throat. --Macbeth
tim@efi.com (Tim Maroney) (06/29/90)
In article <1990Jun26.192623.7121@efi.com>, tim@efi.com (Tim Maroney) writes: >> maybe you could let the screeners know that if, say, Rich >> Siegel, Amanda Walker, Gary Fitts, Joel West, Tim Maroney, etc., ask a >> question, it should almost surely be passed along. Obviously, this has >> problems too, and you might also want to extend it in the other >> directions if a lot of someone's questions are RTFMs, but it's better >> than nothing. In article <26883CF9.2BCB@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Tech Support Triage like this might be effective, but I can't see much of >a way to make it practical, not to mention palatable to the people who aren't >on the "good list". Just keep a database on questioners, supplemented by reports from the networks and technical article publications.... And yes, it *is* annoying that William Gibson is more certain to get through to Ellen Datlow than I am, but I accept it as a fact of life. (And I still get better responses from Ellen than from DTS! And she gets hundreds of manuscripts a month!) >Of course, some of this happens already on an informal level. For example, >I have a small collection of Apple business cards and email addresses that >enable me to call up an engineer and bypass MACDTS altogether. Since I know >enough not to do so except as a last resort, they know that if I'm calling >with a problem, it's (a) really a problem with their stuff, (b) serious, >and (c) reproducible. I know enough not to waste their time, just as they >know enough not to waste mine in similar circumstances. If I were to start >abusing this privilege, my phone calls would start getting lost in Apple's >Voicemail system... :-). I use e-mail. I have such contacts in several areas, but they hardly cover the entire Mac OS. I send about one question a year to MacDTS, in areas that my personal contacts don't cover. Last year, it was a question on figuring out what list was being clicked in a clikLoop routine (no answer); this year, it was on a couple of announced features of System 7.0 whose fate was in dispute (no answer). So why bother with the MacDTS line at all? Does anyone have any good experiences to report with it? I did have a question answered in 1987, I'll admit. It concerned the error return from the ReadPacket routines in socket listeners and protocol handlers, and was followed by a new Tech Note disambiguating the issue generally. I believe that was the only time anyone there has been any use in an official MacDTS capability. The DTS engineers here in public are often quite helpful when they don't get overly defensive, though. >On a slightly less informal level, people and companies that have proven >themselves end up working with evangelists, which is still a cut above the >average Apple Partner who sits on AppleLink and goes through the standard >queue. The biggest barrier seems to be getting a real live good product >out the door. After that, Apple takes you more seriously. Well, I only have five real live good products out, so I guess I'll have to wait a bit longer....
amanda@mermaid.intercon.com (Amanda Walker) (06/29/90)
In article <1990Jun28.182240.17652@efi.com>, tim@efi.com (Tim Maroney) writes: > Well, I only have five real live good products out, so I guess I'll have > to wait a bit longer.... Sorry about how that sounded... sigh :-). My scope got more general as the article progressed... -- Amanda Walker InterCon Systems Corporation -- "The problem with X is that it's overadequate" --Dennis Ritchie
wdh@well.sf.ca.us (Bill Hofmann) (06/29/90)
>Yes! Oh yes! As a matter of fact, we're toying with the idea of letting the >questioner assign a priority to their question, from 1 to 4. Initial reactions >here are that everyone would put a #1 priority on their questions, but we've >seen that MicroSoft has used this system with satisfying results. I think it would work. Some of the questions I've asked have been "I need to know this, but I'm asking now, three weeks before I *need* to know", and of course, those are the ones that get answered in a day, and the "I've got a release tomorrow, ..." questions drop into a black hole. A priority scheme would be just fine, if it could be kept to. -Bill Hofmann
ts@cup.portal.com (Tim W Smith) (06/30/90)
< bother with the MacDTS line at all? Does anyone have any good < experiences to report with it? I recently asked a question and in response DTS sent me a think package full of documents marked "FOR INTERNAL APPLE USE ONLY" and a diskette of sample code. This stuff will save about four months of work on a big project I'm working on. I think this qualifies as a good experience. Most of my bad experiences with DTS can be explained by a lack of understanding on the part of the question screener. For example, let's say you wanted to make a Macintosh CD-ROM drive. Your first question is probably something like, "Can I just license the Apple CD-ROM stuff and have it work with my drive, or do I have to write my own driver which the Apple CD-ROM stuff can use, or do I have to write my own external file system to use this?". The problem here is that when you send this question, the screener will look at this and see that you mentioned licensing Apple's CD-ROM stuff, and send you a letter saying DTS does not deal with licensing issues and directing you to the licensing people. Now that I've found out that someone who is not highly technical screens the questions, I can phrase them in such a way as to avoid having them misdirected. I suspect that this knowledge will eliminate the few cases where my questions get bounced.
ts@cup.portal.com (Tim W Smith) (06/30/90)
>Yes! Oh yes! As a matter of fact, we're toying with the idea of letting the >questioner assign a priority to their question, from 1 to 4. Initial reactions >here are that everyone would put a #1 priority on their questions, but we've >seen that MicroSoft has used this system with satisfying results. How about bribery :-) I mean, DTS engineers eat lunch, right? Maybe if people in a hurry offered to take a DTS engineer to lunch, they could get a quicker response. The person with the question would send the question, along with a proposed place of lunch, and DTS could then set up a date. For a question that's not very important, the questioner might offer McDonalds. For a more important question, Togos would be indicated. As deadlines approach, we could move up to Jade Tree. Ok, maybe it's a silly idea, but I live and work in Cupertino, and it sometimes seems that I'm practically surrounded by Apple buildings. There must be some way to use this to my advantage in deealing with DTS... Tim Smith
alexr@ucscb.ucsc.edu (Alexander M. Rosenberg) (07/06/90)
In article <31280@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: > For a question that's not very important, the questioner might offer > McDonalds. For a more important question, Togos would be indicated. > As deadlines approach, we could move up to Jade Tree. No, you've missed the point. Sport City Cafe. DTS Engineers like to be pampered a little. I mean, I eat at Jade Tree about once a week. Sport City Cafe is like once every three months or so. Of course, bribery in any form is out of the question anyway, so this is all moot. (Bleah, ignore the addresses in this .signature. I can be reached at: Alex_Rosenberg.INTEGRATION@gateway.qm.apple.com) --------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alexr@ucscb.ucsc.edu - Yoyodyne - - 330 1/2 Waverley St. - UUCP:ucbvax!ucscc!ucscb!alexr - Propulsion - - Palo Alto, CA 94301 - BITNET:alexr%ucscb@ucscc.BITNET- Systems - - (415) 329-8463 - Nobody is my employer so - :-) - - - so nobody cares what I say. - -
keith@Apple.COM (Keith Rollin) (07/07/90)
In article <8993@goofy.Apple.COM> alexr@ucscb.ucsc.edu (Alexander M. Rosenberg) writes: >In article <31280@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >> For a question that's not very important, the questioner might offer >> McDonalds. For a more important question, Togos would be indicated. >> As deadlines approach, we could move up to Jade Tree. > >No, you've missed the point. Sport City Cafe. DTS Engineers like to be >pampered a little. I mean, I eat at Jade Tree about once a week. Sport >City Cafe is like once every three months or so. Of course, bribery in any >form is out of the question anyway, so this is all moot. Huh? Who says bribery is out of the question? Hobee's will be fine. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
sirkm@ssyx.ucsc.edu (Greg Anderson) (07/07/90)
In article <8993@goofy.Apple.COM> alexr@ucscb.ucsc.edu (Alexander M. Rosenberg) writes: [about buying DTS engineers lunch:] >................................................ Of course, bribery in any >form is out of the question anyway, so this is all moot. I thought that Apple employees could accept gifts of nominal value (<$50) and still be well within the ethics guidlines set forth by the company. ___\ /___ Greg Anderson ___\ /___ \ \ / / \ \ / / \ /\/\ / \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
minow@mountn.dec.com (Martin Minow) (07/08/90)
In article <42701@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > >Huh? Who says bribery is out of the question? > >Hobee's will be fine. We have restaurants in Boston, too. Some not yet discovered by tourists. Let me know when you're in town. Martin. minow@bolt.enet.dec.com