What’s the first rule of using a computer? I’d wager that nine out of ten support staff would agree on this one. We might all think it’s a no-brainer, but for as long as I’ve been in this business (20+ years), rule number one was to save often. I’m amazed at how many people don’t. Here are some of the things I see.
I recently upgraded a bunch of computers in the office, and to accommodate busy work demands, I would swap the boxes after hours. More times than not, I would find that people went home for the day leaving any number of files open. Of course, when I closed them, I was asked if I wanted to save the changes. That can only mean that it wasn’t saved before that person went home. Some of them didn’t even have a proper file name, since I was asked if I wanted to save Document1, or Workbook1, or some other default name. Personally speaking, I never even walk away from my computer without saving, much less go home for the night without doing it. In fact, I seldom leave anything open when I leave for the day.
Someone approached me recently with a gripe about how Microsoft will sometimes automatically reboot his computer after an upgrade. I have these computers scheduled to check for upgrades late at night so people aren’t interrupted with it during the day. Of course, his gripe wasn’t really about the automatic reboot, but rather how he lost some work because of the files he left open — without saving. One question will put an abrupt end to that gripe: Didn’t you save your work before you went home?
Another person called me over not too long ago because, for some unknown reason, our primary application software, AutoCAD, threw a rare hissy fit and displayed an unrecoverable error message. Nothing was responding, and the only way to proceed was to end the task. Of course, this meant the file couldn’t be saved. When was your last save, I asked? The three-hours-ago answer she gave was a tough one to hear. However, all might not have been lost, I thought, since AutoCAD has a nice auto-save feature. But for some reason, the file created by that auto-save was incomplete. I’m not sure why, but it probably has something to do with how AutoCAD references different files and such. But for whatever reason, it just wasn’t there.
Okay, maybe this is all a minor rant, but after repeating rule number one — save often — over and over (probably into the thousands of times over the years), it’s still something a good number of people obviously don’t do. I have to wonder why, but the answer remains elusive.
Okay, one more minor rant: Someone asked me today why his e-mail was not getting out of his outbox. Just a hunch, I said, but perhaps it’s the 47 MB file attachment you’re trying to send!
P.S. I’ll be on vacation for the next week, so I’ll look forward to replying to any comments after I get back.
Saturday, June 28, 2008
Fixing the fault, fixing the customer
Let’s face it, we all deal with the fault on a PC or network as a matter of routine, but how often do we consider that we also need to fix the customer? It may be that their confidence in the equipment/service/company has been strained and maybe even broken, and it may be that some work may be needed to restore the customer’s faith in your work.
Is it enough to mend a fault and leave? It may be that the customer has concerns that a few words and a minute or two of listening might make the difference between leaving a happy customer and leaving somebody considering a move to another support service. A few nods and an “I see” or two and some other empathetic noises can make all the difference. One of my worst failings is to listen to the customer, right up to the point where I think I know what the problem is, then I switch off as I start the fix. There may be more to the problem than I’ve heard from the user, and I have often had to backtrack and hear the rest of the story.
In my keenness to get on and fix the fault, I often forget about the customer and get too involved in the technicalities. I recall an incident when the customer had been reporting some minor fault or other on an almost daily basis. After a couple of “no fault found” callouts, I began to wonder if the problem was with the equipment or with the user, so I decided to get them to show me the fault instead of just describing it. It very soon became obvious that the problem lay with a lack of training, and I was able to sort out the problems quite quickly.
I seem to spend a lot of my time banging on about people skills or soft skills, as they are often referred to. Sometimes you can win with soft skills where you fail on the technical fix. Sometimes we have to give bad news, or maybe we can’t fix the fault straightaway; we may have to wait for parts or get a problem fixed on a remote service. It is the way we communicate this kind of information to the customer that determines whether we leave them happy or anxious that we haven’t appreciated the seriousness of the situation.
How do we give bad news without annoying the customer? First, we have to understand that no matter how well you communicate a problem, you can’t always leave the customer happy. It is foolish to think otherwise and could lead to your suffering a lot of stress in the process. Give the news straight and tell the customer what you are going to do about it. If that isn’t good enough, ask what they would like you to do. If you have an idea that might provide a workaround to the problem, run it past them. You will nearly always be able to come to an agreement that will mollify both parties, but it is important to remember that, provided that you have done all you can, you can leave with a clear conscience. Above all else, don’t take the problem home with you.
Is it enough to mend a fault and leave? It may be that the customer has concerns that a few words and a minute or two of listening might make the difference between leaving a happy customer and leaving somebody considering a move to another support service. A few nods and an “I see” or two and some other empathetic noises can make all the difference. One of my worst failings is to listen to the customer, right up to the point where I think I know what the problem is, then I switch off as I start the fix. There may be more to the problem than I’ve heard from the user, and I have often had to backtrack and hear the rest of the story.
In my keenness to get on and fix the fault, I often forget about the customer and get too involved in the technicalities. I recall an incident when the customer had been reporting some minor fault or other on an almost daily basis. After a couple of “no fault found” callouts, I began to wonder if the problem was with the equipment or with the user, so I decided to get them to show me the fault instead of just describing it. It very soon became obvious that the problem lay with a lack of training, and I was able to sort out the problems quite quickly.
I seem to spend a lot of my time banging on about people skills or soft skills, as they are often referred to. Sometimes you can win with soft skills where you fail on the technical fix. Sometimes we have to give bad news, or maybe we can’t fix the fault straightaway; we may have to wait for parts or get a problem fixed on a remote service. It is the way we communicate this kind of information to the customer that determines whether we leave them happy or anxious that we haven’t appreciated the seriousness of the situation.
How do we give bad news without annoying the customer? First, we have to understand that no matter how well you communicate a problem, you can’t always leave the customer happy. It is foolish to think otherwise and could lead to your suffering a lot of stress in the process. Give the news straight and tell the customer what you are going to do about it. If that isn’t good enough, ask what they would like you to do. If you have an idea that might provide a workaround to the problem, run it past them. You will nearly always be able to come to an agreement that will mollify both parties, but it is important to remember that, provided that you have done all you can, you can leave with a clear conscience. Above all else, don’t take the problem home with you.
What can support pros learn from their auto mechanics?
When I was recently arranging a routine service appointment for my automobile, I was struck by the fact that, for once, the shoe was on the other foot. I’m used to being the expert who has to explain a complicated technical issue to a nontechnical customer. When it comes to repairing cars, I know just enough to make myself sound stupid. Suddenly, I find myself in the position where I have to have things explained to me, often more than once.
I have a great mechanic, so when I work with him, I’m seeing customer service done really well. My visit to the garage got me thinking about some of the practices of good auto service professionals, and I realized that the techniques that produce a positive car repair experience could serve as a guide for creating a positive support experience for my users. Here’s the list I jotted down while waiting for my car to come down off the lift.
Triage effectively. My mechanic, Jim, is great about making sure that emergency situations are given special attention. Engine threw a cylinder on the highway? He’ll immediately send a wrecker to pick you up. Just need your oil changed? If there are more pressing tasks, Jim will gracefully let you know he’s too busy and will ask you to drop off your car in a day or two. The takeaway here is that most customers don’t mind waiting for nonemergency service, as long as they’re given a firm date when they can expect attention.
Provide an estimate. When I work with Jim, his estimates usually have two parts: the cost and the timeframe in which the work will be done. Cost may not always be a factor when the help desk is serving a user, but there are other things to take into account. It may be necessary to order replacement parts, for instance. Providing your customers with estimates of what the work will entail and when it will be completed will manage their expectations and lower their stress level.
Offer alternate arrangements. In the auto-service industry, this takes the form of the courtesy car. Consider keeping a couple of serviceable machines on hand as cold spares that you can loan to users whose regular workstations may need significant repair. With a “courtesy computer,” at least the client can continue his or her work.
Update the customer. Mechanics revise their estimates; sometimes it’s necessary because the work required is more extensive. This can happen when a machine is on the repair bench, too. If the situation has changed — for the worse or for the better — make sure that the customer is informed.
Explain things clearly. Think of it this way: your customers won’t appreciate your work if they don’t understand your description of it. Avoid jargon as much as possible. Put the situation in terms that are easily understood, and contextualize things for the users. If they have an understanding of how you’ve helped, they’ll feel better about the experience.
Suggest future maintenance. Lots of car trouble can be avoided if the owner takes care of the vehicle. The same holds true for computers. If there’s a way that the user can avoid the inconvenience of future problems, share that knowledge with them.
I recommend my mechanic to anyone I overhear complaining about the last time their car had to be serviced. There may be a guy out there with more qualifications than Jim, but his work is solid, and his customer service is second-to-none. When I’m in a situation where I’m out of my depth, I appreciate working with a professional who is concerned about the quality of my experience. Your users will, too.
I have a great mechanic, so when I work with him, I’m seeing customer service done really well. My visit to the garage got me thinking about some of the practices of good auto service professionals, and I realized that the techniques that produce a positive car repair experience could serve as a guide for creating a positive support experience for my users. Here’s the list I jotted down while waiting for my car to come down off the lift.
Triage effectively. My mechanic, Jim, is great about making sure that emergency situations are given special attention. Engine threw a cylinder on the highway? He’ll immediately send a wrecker to pick you up. Just need your oil changed? If there are more pressing tasks, Jim will gracefully let you know he’s too busy and will ask you to drop off your car in a day or two. The takeaway here is that most customers don’t mind waiting for nonemergency service, as long as they’re given a firm date when they can expect attention.
Provide an estimate. When I work with Jim, his estimates usually have two parts: the cost and the timeframe in which the work will be done. Cost may not always be a factor when the help desk is serving a user, but there are other things to take into account. It may be necessary to order replacement parts, for instance. Providing your customers with estimates of what the work will entail and when it will be completed will manage their expectations and lower their stress level.
Offer alternate arrangements. In the auto-service industry, this takes the form of the courtesy car. Consider keeping a couple of serviceable machines on hand as cold spares that you can loan to users whose regular workstations may need significant repair. With a “courtesy computer,” at least the client can continue his or her work.
Update the customer. Mechanics revise their estimates; sometimes it’s necessary because the work required is more extensive. This can happen when a machine is on the repair bench, too. If the situation has changed — for the worse or for the better — make sure that the customer is informed.
Explain things clearly. Think of it this way: your customers won’t appreciate your work if they don’t understand your description of it. Avoid jargon as much as possible. Put the situation in terms that are easily understood, and contextualize things for the users. If they have an understanding of how you’ve helped, they’ll feel better about the experience.
Suggest future maintenance. Lots of car trouble can be avoided if the owner takes care of the vehicle. The same holds true for computers. If there’s a way that the user can avoid the inconvenience of future problems, share that knowledge with them.
I recommend my mechanic to anyone I overhear complaining about the last time their car had to be serviced. There may be a guy out there with more qualifications than Jim, but his work is solid, and his customer service is second-to-none. When I’m in a situation where I’m out of my depth, I appreciate working with a professional who is concerned about the quality of my experience. Your users will, too.
Supporting (installing) financial software: My most difficult install
Over the years, other than providing basic computer technology support, I’ve had little responsibility for the financial software used by the company. Of course, I’d help the bookkeeper get the initial installation process going, and I helped her set up an adequate backup system (both on-site and off-site), but otherwise, I remained pretty much out of the financial software picture. (Privacy, confidentiality, and all that stuff, I suppose.)
However, the newest version of our financial software has me jumping through more hoops than I’ve ever had to endure. For one thing, while all past versions of the software could be installed on a stand-alone workstation, this one is for a server installation only; it can’t be installed on a domain controller, so I had to provide a dedicated server just for the application (not that I’d want to install it on my domain controller anyway), which meant we had to provide an additional computer and buy another Server OS with the appropriate CALs. It uses SQL database and Microsoft .NET Framework, neither of which are really within my area of expertise; and the software company doesn’t provide a DVD for the installation, but rather makes it available by Internet download only — a total of six files (two of which are large documentation files), whose sizes total a whopping 800MB, taking a long time to download.
The four downloaded installation files had to be executed in a particular order, which is understandable, I suppose, but I’m pretty sure they could have been integrated somehow to be run in the proper order by a simple installation routine. Nonetheless, executing the first installation file generated a CRC error about 30 minutes into its installation process (something about not matching the setup’s .cab file). We determined that the file became corrupted during download, so I had to download that one again (well over 100 MB and more download time). The second try was successful, but it took about 45 minutes to finish.
The second file started to install, but it stopped to inform me that I first had to install the required Microsoft .NET Framework (version 1.1). That was easy enough to find and download from Microsoft’s support site, and I decided it would be a good idea to download and install the accompanying SP1 while I was at it. That was about a two-hour detour by the time it was all said and done (and installed). After running the second installation file for the second time, it finally did finish after more than an hour.
The third installation file generated the same CRC error as the first one. Of course, I had to download that one again as well. The only difference was the file size and the time it took to download — twice the size and twice the time of the first file. Oh, there was another difference — this one crashed as well! After putting in a call to the software’s tech support folks, they directed me to a different FTP site from which I could download the file. The file on the initial site might have some problems, they said. (I think that might fall into the DUH! category.)
Was the third try with the third file a charm? It would have to wait until the next day. It was still downloading when I went home for the day. However, on my way home, it occurred to me that this might not be the installation files at all. While these are large files, it shouldn’t take that long to download over a business-class broadband connection. Before I proceed any further, I believe some testing of my Internet connection, modem, and firewall router is in order. The new financial software is a real pain, but the download time might be another issue entirely.
Funny, I was talking about one problem, and segued right into another.
Anyway, what are some of your challenging installations?
However, the newest version of our financial software has me jumping through more hoops than I’ve ever had to endure. For one thing, while all past versions of the software could be installed on a stand-alone workstation, this one is for a server installation only; it can’t be installed on a domain controller, so I had to provide a dedicated server just for the application (not that I’d want to install it on my domain controller anyway), which meant we had to provide an additional computer and buy another Server OS with the appropriate CALs. It uses SQL database and Microsoft .NET Framework, neither of which are really within my area of expertise; and the software company doesn’t provide a DVD for the installation, but rather makes it available by Internet download only — a total of six files (two of which are large documentation files), whose sizes total a whopping 800MB, taking a long time to download.
The four downloaded installation files had to be executed in a particular order, which is understandable, I suppose, but I’m pretty sure they could have been integrated somehow to be run in the proper order by a simple installation routine. Nonetheless, executing the first installation file generated a CRC error about 30 minutes into its installation process (something about not matching the setup’s .cab file). We determined that the file became corrupted during download, so I had to download that one again (well over 100 MB and more download time). The second try was successful, but it took about 45 minutes to finish.
The second file started to install, but it stopped to inform me that I first had to install the required Microsoft .NET Framework (version 1.1). That was easy enough to find and download from Microsoft’s support site, and I decided it would be a good idea to download and install the accompanying SP1 while I was at it. That was about a two-hour detour by the time it was all said and done (and installed). After running the second installation file for the second time, it finally did finish after more than an hour.
The third installation file generated the same CRC error as the first one. Of course, I had to download that one again as well. The only difference was the file size and the time it took to download — twice the size and twice the time of the first file. Oh, there was another difference — this one crashed as well! After putting in a call to the software’s tech support folks, they directed me to a different FTP site from which I could download the file. The file on the initial site might have some problems, they said. (I think that might fall into the DUH! category.)
Was the third try with the third file a charm? It would have to wait until the next day. It was still downloading when I went home for the day. However, on my way home, it occurred to me that this might not be the installation files at all. While these are large files, it shouldn’t take that long to download over a business-class broadband connection. Before I proceed any further, I believe some testing of my Internet connection, modem, and firewall router is in order. The new financial software is a real pain, but the download time might be another issue entirely.
Funny, I was talking about one problem, and segued right into another.
Anyway, what are some of your challenging installations?
Lines in the sand: Three requests support techs should turn down
One problem with running a service-oriented help desk is that people keep coming to you for help.
OK, that’s meant mostly as a joke. Mostly. In my experience I’ve found that creating strong relationships with one’s clients will lead to more service calls. It has something to do with inhibition and intimidation. If customers have a positive experience with a tech, they’ll feel reassured about the support process, and this will make them more inclined to ask for assistance in the future.
Creating comfortable clients is ideal for a freelance or contract technician, who gets paid by the call or by the hour. Every service request is money in one’s pocket. Comfortable clients can be less ideal for a standing in-house support team, though. Users’ inhibitions can become so low that they start asking the help desk to provide support that’s outside appropriate boundaries. This is especially likely in environments that don’t impose any checks on the urge to file a support request, like fees, departmental charge-backs, or ticket accounting.
Responsible IT departments should have published policies about what they’ll support. Even if those policies are out there, though, that won’t keep techs from getting requests for assistance that are beyond the help desk’s authority. Being aware of the types of inappropriate—and sometimes informal—support requests will let you anticipate them and will let you prepare your techs to handle such things, if and when they appear.
Project work or IT engineering tasks. The role of the help desk is, first and foremost, to provide incident-based support to the client. Many places, including my own office, economize by having support techs also work within project teams developing new services. Help desk issues should always trump project work, though. If an IT project or engineering task is important enough that it can’t be set aside in favor of addressing emergent support requests, then it’s important enough that the project’s manager should have dedicated personnel working on it, rather than counting on the help desk techs having slack time.
Requests not related to work. Whether it’s answering questions about problematic home computers or fielding requests to set up MP3 players on company-owned machines, there’s no reason for help desk techs to spend work time answering non-business requests. Let me be clear, I’m not an unfeeling robot. I’ll chat for a minute or two with colleagues about problems they may be having with machines at home, or I’ll provide shopping advice. That’s the extent of it, though. Our support policy excludes privately owned hardware and clearly outlines what’s supported on company-owned machines. That’s where the responsibility of our techs ends, and I’ve had to explain this to a number of users.
Shop talk during social events or off hours. There’s an old cliché that insists that doctors are always being solicited for professional advice at cocktail parties and the like. I don’t know about whether that’s actually true for M.D’.s or not, but it’s certainly true for IT pros. I’ve been at many an office social event, only to have a colleague bring up a problem that they’ve been having. Support pros deserve the opportunity to unplug from work responsibilities now and again. I don’t hesitate to let my users know when I’m “off the clock.”
Those are the three types of inappropriate inquiries I see most often as an office support tech. If you have any others to offer, let me know in the comments.
OK, that’s meant mostly as a joke. Mostly. In my experience I’ve found that creating strong relationships with one’s clients will lead to more service calls. It has something to do with inhibition and intimidation. If customers have a positive experience with a tech, they’ll feel reassured about the support process, and this will make them more inclined to ask for assistance in the future.
Creating comfortable clients is ideal for a freelance or contract technician, who gets paid by the call or by the hour. Every service request is money in one’s pocket. Comfortable clients can be less ideal for a standing in-house support team, though. Users’ inhibitions can become so low that they start asking the help desk to provide support that’s outside appropriate boundaries. This is especially likely in environments that don’t impose any checks on the urge to file a support request, like fees, departmental charge-backs, or ticket accounting.
Responsible IT departments should have published policies about what they’ll support. Even if those policies are out there, though, that won’t keep techs from getting requests for assistance that are beyond the help desk’s authority. Being aware of the types of inappropriate—and sometimes informal—support requests will let you anticipate them and will let you prepare your techs to handle such things, if and when they appear.
Project work or IT engineering tasks. The role of the help desk is, first and foremost, to provide incident-based support to the client. Many places, including my own office, economize by having support techs also work within project teams developing new services. Help desk issues should always trump project work, though. If an IT project or engineering task is important enough that it can’t be set aside in favor of addressing emergent support requests, then it’s important enough that the project’s manager should have dedicated personnel working on it, rather than counting on the help desk techs having slack time.
Requests not related to work. Whether it’s answering questions about problematic home computers or fielding requests to set up MP3 players on company-owned machines, there’s no reason for help desk techs to spend work time answering non-business requests. Let me be clear, I’m not an unfeeling robot. I’ll chat for a minute or two with colleagues about problems they may be having with machines at home, or I’ll provide shopping advice. That’s the extent of it, though. Our support policy excludes privately owned hardware and clearly outlines what’s supported on company-owned machines. That’s where the responsibility of our techs ends, and I’ve had to explain this to a number of users.
Shop talk during social events or off hours. There’s an old cliché that insists that doctors are always being solicited for professional advice at cocktail parties and the like. I don’t know about whether that’s actually true for M.D’.s or not, but it’s certainly true for IT pros. I’ve been at many an office social event, only to have a colleague bring up a problem that they’ve been having. Support pros deserve the opportunity to unplug from work responsibilities now and again. I don’t hesitate to let my users know when I’m “off the clock.”
Those are the three types of inappropriate inquiries I see most often as an office support tech. If you have any others to offer, let me know in the comments.
Subscribe to:
Posts (Atom)