|
Virtual Seminar Tech Talk Series
Help Desk Strategies
June 17, 1998
Participants:
Judith Boettcher (JB)
Greg Marks (GM)
Russ Vaught (RV)
|
Topics covered include: To find a specific term or phrase from within this transcript, use your browser's search function.
JB: Welcome to the CREN expert event Webcast, and to this session with Russ Vaught on Help Desk Strategies. You are here because it is time to discuss the leading core technologies in your future. This is Judith Boettcher of CREN, one of your hosts for today's session. Greg Marks, our regular co-host from MERIT, is back with us today. Welcome back, Greg. GM: Judith, thank you. It's a fascinating and important topic today, and we'll, I think, explore a lot of interesting things. JB: All right, great. Our guest expert today is Russ Vaught, who is the senior director for the Center for Academic Computing at Penn State University. Russ is well known for his innovative strategies and principles for handling large scale academic research and support issues. Most of these principles are proving very useful at smaller academic institutions as well. Russ will also be facilitating sessions on this topic at pre-conference seminars at Educom and CAUSE this fall, if you would like an opportunity to have a longer, more extended focus on this topic with Russ. Welcome, Russ, and thanks for being an expert with us today. RV: Hey, Judith, I'm really very glad to be here. Having started off as a computer user in '66, and needing my own share of assistance over the years in using computers to do my work, I have long seen this as really an important thing for the delivery of services. JB: Well, certainly, as well -- all just really need help in learning how to use all these tools. We're really anxious to hear how Penn State is addressing these issues. Greg, would you like to tell folks how we're going to be handling questions today? GM: Right. First off, as you said, before we start the discussion, let us make clear how people can ask questions. You can send your questions to Russ during the Webcast by sending e-mail to expert@cren.net. And he will be watching, as will Judith, the e-mail coming in at expert@cren.net, and they will respond to as many of those as make sense during the session. Very likely some of them will not be handled during the session, and those will be responded to at the CREN site, so you can look there, both for a transcript and a real audio recording of the session and some of the Q and A afterward. I should also add a note that there are some extra materials that Russ has made available for this session which you can go to at the following Website: www.personal.psu.edu/rsv/HelpDesk. You'll see a set of slides which go along with a number of points that Russ will be making during this session. If you reload the website sometime in the next five or ten minutes, you'll probably find that URL up at the CREN website, the one that you are using to reference this RealAudio broadcast. JB: Thanks very much, Greg, for that detail. Will the folks have any difficulty both hearing and watching that? Should they launch the audio first and then go to the other website? GM: Launch the audio, and then RealAudio players are quite robust. I've actually seen machines essentially crash, but the RealAudio player just keeps running, so it's pretty immune to your going off and doing anything at all. JB: So we can do all these sorts of things at the same time. GM: Right. You can answer e-mail, you can do all sorts of things while the RealAudio player is running. JB: All right, great. Well, actually (and I'd like to just note and thank Russ again for putting up that kind of detail), and that will of course be up with the archives as well. And it gives us a chance perhaps to try another little model here of distance learning, where we have both the audio as well as then basically some slides to go along with it. Okay, Russ, the topic of how to help folks in their use of technology is really a universal challenge, and at Penn State, you have an extraordinarily large community requesting support. Just how big is your user community? RV: Well, we have over 100,000 active accounts that use e-mail and our Web services and those kinds of things, including dial-up. They also -- as many of them as well have webpages and those kind of things. We estimate that we have roughly 80,000 desktop computers that use our system, so we're a reasonably large operation. By the way, we have 24 locations -- actually 25 now, as of fairly recently. And we provide some level of services to all of those locations from this center. JB: That sounds like certainly, in some sense, the world. You're really scaling up in terms of reaching out to people. How about giving our Webcast participants kind of a roadmap of the topics that we're going to be talking about in today's session? RV: I'd like to chat essentially about some of the functions and ways of delivery -- venues, if you will --, the staff required to do it, the effort, and then begin to talk about the software that we use and that others use for this purpose. What kind of training you need to use for your Help Desk people -- frankly, I think that's one of the most important elements of the whole thing: what kind of campus model we use to deliver these services. One size doesn't fit all, certainly. And what's worked for us -- and frankly what won't. I always think you learn more from your problems than you do from your triumphs. JB: And we hope that those balance out, right? RV: It is long noted that all of us in this business are just one step ahead of the hangman. If they don't balance out, the hangman gets you. GM: Why don't we start out by your saying a bit about the functions and the way you deliver those services? RV: Okay, let's do that. We use a whole variety of things. We use the telephone rather heavily. We use walk-in services (like most people). We use e-mail -- and I suspect we'd use courier pigeon if we thought that it would work! So essentially, any way we possibly can. We also have Help Desks in our microcomputer clusters. That has worked extremely well. We've got one that runs 24 hours a day, seven days a week during the semester. The others phase in and out. The expense there, by the way, is very high. That's something you go into slowly. Those only cover the smaller set of stuff on those clusters. And we also have two other things that we do that I think are reasonably novel. The first one is a workbench where customers actually who haven't been able to be helped by the normal methods can bring their machines in, leave them with us. We'll find out whether it's hardware or software: if it's hardware, we refer them to the repair service; if it's software, we help them fix it. And we also have a disk recovery service, which I think is an important thing. JB: Russ, you mentioned cost and everything in terms of the microclusters. What about the cost on the data recovery and the workbench. Are those cost recovery services, or are those just provided? RV: Those latter two, I've been asked why I don't charge for them, and I think a lot of people would probably do that. My feeling is it generates so much goodwill that it's well worth the thing, no matter what it costs. The simple fact is that people who are having trouble with their machine typically blame the people in the central computing organization or their local computing organization -- actually, anything but themselves -- and by providing this service, you put a human touch to it that says, "We really care." GM: You say that they tend to have those kinds of negative aspects, but do you do a lot of work in terms of training? Do you make a lot of that available to people to try to reduce and offset the Help Desk costs? RV: Yeah, I'm going to hit that one a little later. But we do an awful lot of training in terms of workshops and those kinds of things. And we're trying some newer, innovative things -- including taking advantage of some of the things that CREN's been doing in that area, which I think we ought to discuss at some length later on. JB: Do you want to talk perhaps a little bit more about your telephone and the services that you do provide via telephone and e-mail, and just a little bit about how that's working? RV: Yeah, that's working pretty well. We have a number of telephone lines. Frankly, in the fall, we don't have enough. Typically the first line of support is students. We train them. Actually, interestingly enough, the training of our Help Desk students is not what you'd normally think. We select them on the basis of their technical skills, and in an interview that determines whether they have good interpersonal skills -- and a lot of our training really is devoted to interpersonal skills, customer relations, those kinds of things. They're pretty good techies; we want them to be pretty good humans, too. JB: Maybe it might be worth mentioning the kinds of questions that are coming in, Russ, in terms of where do you need your staff that's most expert versus where do you first kind of start students or your support staff out? RV: We start our support staff out typically in the clusters -- That's a more constrained problem: we know what the software is on them, we know what the hardware is because we control that. And so that's where our consultants start out. And after about a year working in a lab or a cluster Help Desk, then they have a chance to move on to our main Help Desk. We have two of those: we have one that is focused primarily on general users, and another one that's focused on graduate students and faculty who are doing research, so there's a slight difference there. By the way, a number of other units also have Help Desks, and we feed questions to them -- so it's a multifaceted kind of a web. GM: Russ, you spoke of the clusters as a more constrained or controlled environment because you know what's there. What sort of practices do you follow in terms of managing the update process and rolling out updates, both to your clusters and to customers? And do you support, in terms of outside the clusters, just anything that a customer comes in with, or do you have a list of what it is you're prepared to provide help on? RV: That's really a good question, Greg. Within the labs, we do most of our rolls of software during the summer, and I think most people do that. We try to freeze it as much as possible during the semester with kind of another set of changes during the inter-semester break during the holiday period, December-January. And of course, we'll answer questions on any of the software that is in our labs. The general Help Desk will try to answer questions on anything, but of course, we do have our list of software that we basically support, and we guarantee success there. But we haven't been as sticky as some people on that particular subject. So we'll help you on almost anything if we can. Or find somebody who can. GM: Let's talk a little bit more. You said a little bit about how you select the staff. How many people do you have engaged in this, and how much turnover do you have, and so on? RV: Well, actually, professional staff, we've been pretty good at holding turnover down. We have ten professional staff members in the center who directly support the Help Desk. In addition, we have 154 students that work for us: one hundred of them really work for the center, another 54 work for the residence halls as of July 1. We agreed to spawn part of our operation off -- and that's a good way to do it, by the way. I believe that central computing organizations ought to get things going and then spawn them off. Twenty-three of those students, though, are undergraduates. They work directly on the Help Desk. Seven of them are graduate assistants who get tuition, etc. They work on the graduate Help Desk. And then we have actually 70 lab consultants who work in the microcomputer clusters. JB: I think maybe now would be a good time for us to briefly remind folks that since you're giving them all these numbers that these will all be up on the website and the webpages so folks can go back in and take a look at those. And also perhaps it would be a good time to remind folks that they can send questions to you at expert@cren.net. Then following up on those staffing issues and all -- do you want to talk at this point about the training? Do you take freshmen in or sophomores in for your undergrads and train them? What kind and amount of training do you give your students? RV: We give them actually quite a bit of training. We have about 15 hours of training for them. JB: You give that to them right away, at the beginning? RV: Right. We give them 15 hours over three days at the beginning of the fall semester in particular, and we do the same thing for new consultants in the spring semester. We don't try to retrain the ones we hired in the fall (pretty hard to keep people tied down for the same thing twice). And then we give what I call a series of booster shots throughout the semester -- short, one hour sessions. As I said earlier, a lot of this training is not on technology, because they're pretty good technologists. A lot of them have been using technology for a long time by the time they come to us. What we really train them on is how to help other people use technology. The actual helpdesk consultants usually have about one year of experience in the clusters, and they get specialized training on a continuous basis. And of course, the graduate students -- Penn State's a big engineering school, big physical sciences school, and they're using a lot of this stuff in their graduate work. GM: In addition to the training, do you find that in terms of your professional staff and your managers that they need to spend a good deal of time essentially dealing with burnout and kinds of issues that simply come from the fact that these are pretty stressful jobs, especially for the undergraduate students? This may be their first time in real work dealing with people -- and even after you've done your training about how to deal with people, it's just stressful, discovering the world's like that. RV: That's a real problem. Of course, some people do burn out, quite frankly. We do a lot of things that -- they've got t shirts and those kinds of things to help bring a little pride in what they're doing. We tend to rotate them on and off. They aren't on for a terribly long period during any one session. In the spring session, though, frankly we do begin to have some problems with burnout. The general stress of just being a student at the end of the semester coupled with having heard the same question all year round. I used to fly in the Navy, and there's a real problem with flight instructors. After about the tenth student has tried to kill you, you begin to get a little angry. JB: I hope that our technical support people aren't in danger of their lives, though! RV: Actually, this is much safer than that! JB: Russ, going back to the workbench concept for just a moment, we do have a question that has come in from Stanley Bittner, who is Associate VP of Computing Services at Kettering University. He particularly is interested in how many folks you have that are working on the workbench. RV: That's about five people who kind of rotate through. That isn't their only job by any means. Essentially, people bring in the machine, we get them to sign a release, and then they just leave it. We regret that sometimes it can take as long as a week to find out what's wrong with it. You know, it's usually software -- computers are pretty reliable these days. If we find out it's a hardware problem, though, then we have it sent over to the computer repair shop or suggest that the customer take it over there. They actually fix the hardware and get it back. These aren't full time jobs. The numbers are surprisingly large. JB: Which numbers? RV: The numbers in terms of the number of actual help. For instance, last year, we actually diagnosed 1,200 machines during the 1997 calendar year, so it's not a low level activity, but it doesn't require full time staff. JB: I imagine many smaller schools might be interested in this kind of a concept, because they certainly wouldn't have the staff to have people full time doing that. What is the mix of responsibilities a person who might be working on the workbench might have in your organization? RV: These are typically fairly high-end techies, obviously. If you haven't been able to diagnose the problem with a walk in or over the phone or by e-mail, it's usually a pretty serious problem. So we use some of our best people on that. JB: So what you said was very illuminating, too -- that the workbench is really the backup to the backup to the backup. RV: That's exactly right. GM: What I'm trying to think about is the point at which the decision is simply that there is a serious hardware problem and this machine needs to go off to a repair shop? And there's costs involved with the hardware and so on. Sort of how do you help people make that decision in a way that you don't end up with a lot of costs of your own doing the triage? RV: That's a good question. We frankly are trying to build goodwill and provide a service here, so frankly I haven't put a lot of thought into the cost of it. I think we're really in the service business, so we work as many as 30 to 40 hours on one machine. Most machines don't take that long -- they take maybe half an hour, an hour to diagnose and prove that it's either hardware or software. But you can have some odd things. My Mac in my office here has gotten flaky, and I'm beginning to think it's got a very random bus error. That would take a long time to determine whether that was software or hardware. JB: Russ, we have another question that has come in that links back to just how one organizes to handle all the various questions. It's coming from Terry Calhoun at SCUP, Society for College and University Planning. He's mentioning that the pendulum keeps swinging back and forth in terms of support, and in some places, that support is being even more decentralized. Just how do you handle something like a PageMaker problem -- that sometimes the central phone number may suggest that you call your own department's techie? How do you handle just the range of questions, and what do you see are the pros and cons? That's about three questions in there, I guess. If we can boil it down: How do you handle and consider the pros and cons of handling the broad range of problems at a central helpdesk? RV: Actually, that really refers in a lot of ways to another area that I'd like to discuss before we're done -- that's some of the ways that you organize. Frankly, I don't think that either totally decentralized or totally centralized help works very well. I think each of those approaches have strengths and weaknesses. If you look at the people that we've got on our front-line Help Desks and particularly in our labs, they're really generalists -- so they're very much like general physicians, private practitioners in medicine. They're pretty experienced in a wide variety of things, but they're not deep experts in any particular area. The second line consultants, and in fact the professional staff that back them up, are more like specialists -- and in many cases go well beyond what you would find in an academic unit, for example. So it's kind of like the department and college consulting and our front-line consulting and our microcomputer labs is like a local hospital or a local internist, and the central organization plays more of a role like a large university medical center -- handling the really tough problems. We then coordinate that to a great extent. We have a thing we call the Network of People where four times a year we take half a day and the people in both the central organizations and also in the departments and colleges who are doing similar kinds of things all get together and discuss problems and how they can coordinate better with each other. JB: That sounds like it would be very helpful at addressing a common problem for support help people, Russ, in that often if they are decentralized, then they're out away from a peer group and somewhat isolated from all the technical trends and issues and happenings. And so that really helps to keep folks connected and share their pool of knowledge among that network, then? RV: That is correct. I mean, really, you get a nice balance here between both centralized and decentralized approaches. I think you've got to do both. I think anybody that says one way or the other but not both really ought to go back and look at it again. GM: I think it's really fascinating, though, that you have been able to do this in a way that these folks work well together, because it's so easy for folks to think that some other part -- either the local folks or the central folks, depending on where you're sitting -- that they aren't carrying their share of the load. And I suspect that your quarterly get-togethers have a lot to do with building that social fabric that makes this work. RV: Yeah, we buy cookies. JB: And donuts? RV: [Inaudible.] There's nothing worse than people that you want to have working together than to have someone like me stand up in front and tell them what to do. JB: Russ, we've got a couple other questions coming in. In fact, we're kind of getting a backlog of some questions here today. Let me just mention that the link to all of your slides is in fact now active on the site, so if folks definitely want to reload that URL, they will find it. But let me mention a couple of the questions: Two of the questions really have to do with whether or not you use a commercial package or what kind of tracking system you are using to track problem calls, and whether or not end-users have access to this system. That's coming in from Dana Reichart at Kettering. RV: Actually, we've got our own local home grown stuff which users don't have access to. I want to take a much closer look than we had at some of the things like Remedy. I know that the folks over at Princeton have had good luck with it. I have some questions about cost benefit. Our own system is by and large a tracking system. We, of course, take advantage of the various vendor sites as well. For quite a while we had a system that had common questions in it. We have found that doesn't work, although we do have a lot of that kind of stuff up, so that users can answer their own questions. There isn't one approach that's going to solve all these problems is what the bottom line is. JB: In fact, there's a related question to the tracking system, Russ. Maybe it's a good time to take it. Someone's asking whether or not you use any type of remote diagnostic software. I think that probably links back to questions in terms of trying to diagnose some of the problems folks might have with their computers. RV: We do have some diagnostic software, although a lot of the hardware stuff -- we do have some hardware diagnostic stuff on the workbench, but it's merely a first cut. There's some specialization there. JB: And you're not using any remote diagnostic software right now? RV: We're not using remote diagnostics at all. That's something, certainly, that I've thought about. JB: Maybe we should go back. You had mentioned the fact that there are some commercial packages that are perhaps getting a little bit more robust than they have been in the past. You mentioned one that was called Remedy. Is that spelled just like it sounds? RV: I'm pretty sure it is. JB: Russ, I think now might be a good time. There was just one other question, and then maybe we want to go on to what doesn't work and what does work and what flunks.
The question is from Robin Maine from Texas Christian, and she wants to know -- I'm assuming it's a she -- wants to know whether the Help Desk consultants that are doing academic consulting for faculty are the same ones that are doing the consulting for the other members of the community. RV: Yes, that is in fact the case. At one time, I didn't think that would work, but it seems to work pretty well. [Inaudible] this training in how to handle customers that we do at the beginning of the semester with some booster shots. I think that's a really important element.
JB: On that, you've mentioned that two or three times now, Russ, about the training in customer service and customer relations and all the rest of that. Folks might be interested to know, are you using standardized packages for that or do you bring people in, or just how do you provide that kind of training? RV: We have brought people in. In recent years -- it's just more we've got our own syllabus. JB: So you've got internal folks that are doing that? RV: That's correct. JB: Okay. GM: Has that syllabus been shared through organizations like SIGUX? RV: I'll have to take a look and see how formal it is, to tell you the truth.
JB: Russ, you've got some things that after all this experience, you kind of have a feel for -- "Gee, this stuff really works well and this doesn't work well." How about sharing what you find has really worked well for you? RV: What really works well -- the best thing of all -- is the workbench and the disk recovery. By the time a person gets to the point of needing those services, they are usually getting pretty desperate. And the goodwill that that generates is just absolutely incredible. As I mentioned, we did about 1,200 machines on the workbench. We also did about 2,500 disk recoveries. Two thousand of those just the student consultants could handle. Another 500 of those were a little more difficult and the professional staff had to get involved in. But it's not unusual for somebody to have on a disk, an un-backed-up disk, something that's really very valuable to them. And to be able to salvage most or all of that is really a great act of human kindness. GM: Russ, have you ever kept statistics on repeat offenders, people who keep coming back, not doing their backups? RV: I think it's usually one-trial learning. JB: It's usually what? RV: One-trial learning. JB: Oh, dear. Actually you do provide a nice backup system over the 'Net if folks want to take advantage of it, right? RV: That's correct. We do provide network based backup for all of our users. It's a for-fee service, but it's pretty hard to do it that cheaply yourself, especially off-site. The other thing that works extremely well is our 24 hour lab consultants in one lab. GM: On the desk and all around the clock. RV: Around the clock, seven days a week. There are some people that really need that kind of help -- and we, of course, don't do that during semester breaks and those kinds of things -- but during the semester, especially at the beginning of it with new users, and towards the end of it with desperate users, it is an absolute gem. GM: And that's a place that people all over the campus know about, so if they're 3:00 in the morning of a Sunday morning and they've got to get something done by Monday and they just desperately need help, they can walk over to that lab and find help? RV: That is correct. JB: That's tremendous. Have you experimented with telephone support at 24/7 as well? RV: No, that's something I'm looking at. We in fact may do that this coming year. And I'm also looking at some other things along that line that maybe we can talk about in a moment. JB: Okay, sounds good. RV: Something else that's really worked well are graduate assistants as consultants. They're more mature and they're knowledgeable, and that has been absolute gold as well. Another thing that doesn't sound like much -- but the Wal-Mart type greeter? JB: What was that again, now? RV: Wal-Mart type greeters. Just greeters. People stand in line quite often to talk to our consultants. I think that's true at all our locations, all campuses, all universities. And we have people who are essentially just greeters during peak period who go around and start the conversation about what their problem is. They don't really try to solve it in most cases (although sometimes they can), but it's just a way to say there's a human being here that cares. And that's been extremely successful. JB: I can really see where that would be helpful during the peak periods that everyone has, particularly in the fall when you've got just a myriad of things that everybody's trying to do. RV: That's right, and it lowers anxiety levels a lot. The final thing that I think I would single out as working (and we've got a pointer to it on our webpages here) is we have a structured request form for help. People really have trouble giving a consultant all the information they need, especially in the case of e-mail and where there isn't an ease of interaction. And by having them fill out this form with structures of query, the consultants are quite often more successful on the first try. E-mail consulting can be pretty slow without that kind of stuff. GM: Just because people don't think of all the things they need to tell you, or don't really stop to articulate it very clearly. RV: That's right. So what you do is you guide them through the process and you get the primary information that you need. That then sends an e-mail file to the helpdesk.
GM: Interesting. So you've found these to be very successful. What, as you put it, flunks? RV: Let's talk about the flunkers. First of all, phone requests in general are a real problem -- for the reasons we just discussed, although the webpage helps. During the fall, we simply don't have enough telephone lines, and I think that's not unusual. If you try to call a software vendor, your experience can quite often be the same. Because we're trying to provide consulting at 24 locations, telephone costs can get pretty high, and we're looking at voice-over IP to help do that. There's also -- with telephone calls in particular -- sometimes some confusing handoffs. As I said earlier, we don't provide all the consulting, so the handoff can become somewhat of a problem. And it's quite often really hard on a telephone to get a good and accurate picture of what the problem is. The second thing that I find is a real disaster for all of us is just fall -- that first month of the fall semester, in many ways, the lights go out on the helpdesk. JB: Someone did tell me once that they had a new Help Desk and that they had an unlisted phone number. RV: [Inaudible.] At Penn State, we have 12,000 new users every fall, and that's 12,000 people who are really having trouble using a new technology that's foreign to them in many cases -- in some cases, they've been resistive of up to that point. It would challenge any organization. We're also challenged by some of the games that go on. When I was an undergraduate, young males went around steam tunnels at night. Well, I think the Internet has replaced steam tunnels. [Inaudible.] So fall is just not much fun at all -- at least the first six weeks or so of the fall semester. JB: Well, I think you have some strategies for dealing with the fall, but maybe we could just insert a couple of follow-up questions on a couple of topics here, Russ.
First of all, we do have a question -- both a "Hi" from Linda Cabot at Georgia Tech as well as a question. And the question is, do the decentralized people report to you or to the departments? RV: They report to the department. But that seems to work pretty well. My basic feeling is that we're all in the same business, so we don't have too many examples where that's a problem. JB: And your Network of People, then, is also the attempt that brings all those folks together as you described them? RV: Yeah, in fact, basically I really don't like matrix organizations all that well, but in this particular instance, it seems to work rather well. Getting these people together in a room and letting them meet each other causes a very nice network of people, as the name says, and it really works pretty well.
JB: And one other quick follow-up question on the workbench -- that sounds like a topic that folks are really kind of interested in. This comes from Alex Henson at the University of Chicago: How do you keep people from just coming to the workbench without making an honest attempt to go through the helpdesk first? RV: We take referrals. The workbench isn't advertised. You won't find it referred to on any of the webpages that we have for people, and so it only takes referrals from the helpdesk itself. But that essentially controls it that way.
JB: That sounds good. I think that we want to go back and look at and talk about the fall situation and some strategies for perhaps dealing with that phenomenon. RV: Like a number of institutions, we're creating a CD that contains our software distribution and those kinds of things, and also some preliminary training material. We plan to distribute that to all new users this fall, so we'll have a common set of software. One of the problems that you have in this distributed world that we live in is that software gets out of sync, and by having a common set of software out there, you get some constraints that naturally reduce the load on your helpdesk. The second thing is, we've got a series of home-grown tutorials that are on line that supplement our normal. We run all the normal-user-services-type training sessions, but these tutorials are on-line. The CREN tutorials also show promise in that area, that people will be publicly aware that what CREN is working toward is a series of very nice tutorials from a CBT company that has the whole Microsoft Office Suite and Windows and those kinds of things on it that should be available this fall. I think those kinds of things -- to train an awful lot of people in a very short period -- are the kinds of solutions we're going to have to have to supplement the normal workshops that we all hold in these types of organizations. Something else that we've done, by the way, is we have what we call an Open House. And we take a microcomputer laboratory and reserve it for walk-ins, and we have professional staff in there, one for every two or three machines. And people come in who are really having trouble and they sit down. I think when you were here, Judith, you may have gone over and done that yourself. JB: Actually, I was going to say, I participated in those a couple of evenings and they were definitely during those peak times in the fall when everybody was trying to figure out how to get on, getting over that big hump of just getting starting. RV: Some people are really almost computerphobes, and a little socialization and those kinds of things really goes a long way. JB: They did seem to work well. I'd forgotten about that. Well, you know, I can't believe that our time is just about up for today. If you have time, there's just one other question, perhaps, that we could take, if you have time.
GM: I have one other question that is on the phone service -- do you handle that by having a human being answer the line immediately, or do you start out with a call director kind of system where a series of questions and punching of buttons, like "Press 3 if your computer is on fire." Which way do you handle that? RV: More the human being. We've done some of the other. I have very mixed feelings on it. I can argue either side. I get awfully tired when I call my bank and go through 15 or 20 layers of those things to only then get a recording of music that I don't want to listen to. JB: Or to say that they're closed for the holidays. RV: That's the one that really gets to you!
JB: That's true. Okay. There's one other question, Russ, from Tim Fazil (I believe it's pronounced) at Michigan Tech, and it goes back to another topic we talked about -- asking whether or not you've considered Web-based utilities to aid in consulting as an unmanned help utility for people to navigate and to troubleshoot? RV: Actually, we have more Web-based tutorials. I don't know if we've got any utilities. If he has some utilities he'd like to share with us, it's be great to have him send it to us. JB: Okay, he said they're looking at a similar system for Web-based help and are curious, so perhaps he could send us a note and send us some information and we could link that on the site and see what kind of input we get. All right, very good. Greg, do you have other questions or Russ, do you have any final comment for our folks? RV: Actually, Piet Hein, the Danish poet said it all -- and I think that it really applies to this whole problem of helping people use computers to do their own work. That is, "Problems worthy of attack, prove their worth by hitting back." This one has for the last 30 years or so -- has evolved and hit back. JB: And it doesn't show much sign of ceasing, does it? GM: I don't think it's going to. [Inaudible.] JB: Greg, what about you? GM: I think this has been a great session. JB: I do, too, and I want to thank all of our Web participants for being with us here today with Russ. If you do have any other follow-up questions, you can send them to expert@cren.net and we will forward them to him and get an answer. We will answer them most likely here and on the Web. Also, be sure to check back at the website for transcripts of our spring Webcasts, and also for further announcements about CREN. As Russ mentioned, we will be putting up an announcement very shortly about our new partnership with CBT-Systems, and that will include about 25 end-user titles on CD's. We're very close on that, so keep watching for that. With that, I'd like to thank everyone who made this session possible today: the board of CREN, our guest expert Russ Vaught, our host Greg Marks, Brian Vaughn at UM Online for encoding, and all of you -- and a special thanks, too, for Annie for getting that link up. It's all set there. You were here because it's time. 'Bye, Russ. RV: 'Bye-bye. JB: 'Bye, Greg. GM: 'Bye, Judith. JB: 'Bye, everyone. RV: Have fun!
|