“It doesn’t work right” — how many times has that been the problem description you’ve received?
Here’s an excellent suggestion of what to submit when asking for help. This is taken from the page for the Yahoo group “smf_addin: EXCEL Stock Market Functions Add-in” which supports smf_addin, an Excel addin that pulls in various financial data (see: http://finance.groups.yahoo.com/group/smf_addin/).
If you’re reporting a problem, remember that I’m not a mind reader — “It doesn’t work right” is not a helpful description of a problem. Please try to include relevant information, such as:
– The specific function(s) or template(s) you are having problems with.
– The parameter(s) you are using with the function(s).
– The version of EXCEL you use.
– The operating system you’re running EXCEL under.
– The steps you took to try to resolve the problem.
– The ticker symbols or URLs that are being used.
– The results you expect to get and what you actually get.
Software sales are one of the most devious and underhanded business enterprises known to man. Used car salesman blush and take notes when witnessing a software sales transaction going down.
I’ve been the mop up guy on alot of these transactions. You know what I mean: the customer thought he was buying a system that did A, B, C and D and the salesman didn’t bother to say that B cost extra, C could only be accomplished with an expensive modification and well, D might be available when the new version is released. When the customer finally finds out what’s what, I’m the guy getting the call.
Buying a house or a car is complicated but at their core, a house provides shelter and a car gets you where you need to go. You can usually make a decent guess as to how well the house or car are going to meet those needs. An older house or a used car are more likely to stumble on the way to fulfilling your requirements and you plan accordingly.
There is no straight path from having a software-related need to having your software fulfill that need. For one thing your needs can get very complicated very quickly. Say you want to keep track of your inventory. Sounds easy, right? But what type of inventory do you have? Do your inventory items come in multiple sizes or colors? Does it have components that can be mixed and matched at order time? Does your inventory include items that you both sell and use in the manufacture of other items? How do you plan to enter your inventory: type it in, RFID, scan from labels? Where do you store your inventory: a single warehouse, multiple warehouses, on customer shelves?
You see where this is going. That “I need to keep track of my inventory” becomes a thicket of sometimes complicated questions. Large companies who’ve been in the software marketplace before (and frequently) and who have sophisticated, experienced personnel who can weed through these questions can get satisfaction when bidding out a piece of software. Most companies can’t, and the smaller you are or the more infrequent your previous software purchases have been or the more of a hurry you’re in — well, that software salesman just smiles more and more when he sees you coming.
I’ll have more to say on this in a future blog.
Yeah, I’m bagging on users. Sorry. Most users are actually great and just want to get get on with their lives (which means they have alot in common with us helpdesk jockeys). There are a few, though, that REALLY try our patience:
1. The Know It All. This person calls for help and then proceeds to tell you where you’re wrong. They just KNOW this software package can perform that function. They KNOW their computer should be able to answer their phone. Why are you telling me it can’t scratch my back, I know it can. If they were so smart… well, you know what I mean.
2. The Meek. They may inherit the earth but hopefully after all IT materials have been removed. They are afraid to touch the computer for fear of breaking it. Guess what: it’s already been broken, that’s why you’re calling. How much more damage can you do? And quit apologizing! Stuff happens, and if it didn’t I’d be out of a job.
3. Too Busy. These people are too busy to waste time on the phone with you. They just DON’T HAVE TIME. Can you work on this and call them back when it’s fixed? And you fix it over the weekend? Can you hold while I take this call? I have to get to a meeting; can you start back on this later? How long is this going to take? Can you call my assistant with the answer? Is it fixed YET?
4. The Luddite. Luddites hate technology. The mere act of talking on the phone with you is causing their flesh to crawl, much less that you’re trying to fix their goshdarned new-fangled computer gizmo. They don’t want the computer fixed as much as they want it destroyed.
5. The Clueless. They really have no business being on a computer, or whoever trained them had no business being a trainer. These are the “any key” types, the ones who literally never shut off their computer because they don’t know how. My sense is that most of these people are either blond or executives. And I’m not sure about that blond part.
Everyone knows the old saw “those who can, do; those who can’t, teach.”
Here’s the helpdesk version: “Those who can, work on the helpdesk. Those who can’t, call those who can.”
The Salary Lemma: “Those who can (and who work on the helpdesk) make a lot less than those who can’t.”
Am I right, people?
Remote access is used pretty frequently these days. With it a support person, operating from his/her own office, can take control of the user’s workstation and not only see what the problem is but try out solutions. This can be done while talking to the user on the phone or in the background, while the user does other (non-computer) work or is in a meeting.
If your help desk doesn’t have remote access capability, stomp around and kick your feet until your department gets it. You’ll be doing everyone — not least, yourself! — a favor. (When you’re on a call where the user can’t handle remote access, stomp around and kick your feet for them, too.)
Here are a few tips for using remote access.
- Security is important for the users peace of mind. Make sure your remote access set up forces the user to “invite” you onto his/her workstation and gives the user a clear indication that you’re no longer tapped in.
- If the user is using a modem, get the user’s cell phone number. This is especially important for users who operate from small businesses or their home.
Before signing onto the user’s workstation do the following:
- Before starting the sign in process clarify over the phone that you will be taking control of and have full access to the user’s workstation. Make sure the user gives his assent before proceeding.
- Make sure the user has closed as many applications as possible. Remote access can consume a lot of the workstation’s overhead — especially on smaller, older machines. Closing unnecessary applications reduces the chance that your connection will be disrupted.
- Make sure the user knows to remove anything personal or “embarrassing” from their desktop. The number of truly weird wallpapers and desktop shortcuts to (shall we say) less than professional websites or files out there is astounding, and not only do you not want to see them (or maybe you do, but that wouldn’t be professional, either!) but your user might not even be aware just how public they are to someone logging onto their workstation.
Once you’ve signed in:
- It can get pretty confusing when both you and the user want to “take control.” Let the user know when they’re in control and when you intend to take control.
- If appropriate have the user demonstrate what she was doing when the problem occurred. Let the user control this part of the session.
- It’s best if the user can walk through the complete demonstration before you ask any questions. Stopping the user mid-way to ask “why are you doing this” is confusing and could lead the user down a side path.
- If the user cannot replicate the problem, circle back to make sure everything is as it was when the initial problem occurred. Were there other applications open at the time? Was the user working on a different application when the problem app crashed?
- If the problem involves displaying personal or confidential data that the user is reluctant to access while you’re online, see if the problem can be replicated by using other, “safer” data.
- It’s rare to get a close up view of how a user is using your system: take advantage by looking for opportunites to show the user shortcuts, tips or tricks that may make the process they’re demonstrating easier. For example, if the user seems to be laboriously picking their way through a long table of records to get to the “problem” record, demonstrate how to sort or filter the table. Users REALLY appreciate these suggestions and they have so few chances to learn them!
While fixing the problem:
- It’s always a bad idea to ask for a users passwords. If you know you’re going to need access to a feature that is password protected, make sure the user is available to type it in. If the user needs to leave her office while you’re working, re-schedule the help session rather than ask for passwords.
- It’s fine if the user wants to put the phone on mute while you work. Putting you on hold, though, is a waste of everyone’s time. It never fails: once they put you on hold you need to ask them a question. (That cell phone number can come in handy in these cases, too!)
- Let the user walk through the process that caused the problem so they can verify it’s been fixed.
- Close everything you’ve opened, including files, spreadsheets, documents, web sites and applications.
- Log off the user’s workstation before you get off the phone.
Send a comment with your favorite remote access tips and tricks and I’ll add them to this post. Good luck!
Let’s size up where we’re at in “Phone? What Phone? A Support Desk True Story”.
- On the plus side, the lady’s problem is fixed and she can get back to work. She knows that re-connecting the phone line had something to do with it but she might still be up in the air about why that is.
- She might be a little embarrassed on two counts: first, that her modem-phone connection — which she didn’t know she had in the first place — became unplugged and second because she didn’t know her application depended on using the phone.
- She might be a little irritated at the application or the support desk for putting her in this embarrassing position.
- After the fact the support desk person got a good laugh at this woman’s expense; if some of that came out during the phone call it no doubt added to the embarrassment and irritation levels.
It’s altogether possible that this woman got off the phone, went back to work and never gave it a second thought. But since the support desk person keeps this story around for amusement it’s reasonable to assume that it has some lasting affect on the woman, too.
Here’s a sort of worst case scenario for what that affect might be. This woman’s world just got rocked. She’s gone from having a computer with a program she runs to do her job to having a computer that may be just the tip of a massive data and software iceberg (for all she knows, anyway). Not only does she use a phone to connect to the outside world, it turns out her computer does, too. This little workstation that perhaps her niece took out of the box and hooked up for her (it only took an hour!) is now part of some bigger enterprise of who knows what proportions.
In hindsight it’s obvious that there was more to this whole system then her seemingly self-contained home workstation — afterall, how did her computer get all that rapidly changing data? On the other hand, she never had to worry about that.
When you make a phone call all you do is pick up the receiver and dial the number. You never need to worry about the complex switching machinery involved or the multiple routes the call can take to get to its destination, or the contractual relationships between your phone company, the intermediaries routing the call and the phone company at the other end of the line. If you ever thought about it you’d know there’s something big and involved behind every phone call — but you never think about it. Imgaine if you DID have to think about it every time the phone rang. It’d get on your nerves!
True story. User calls support desk because her application isn’t working. The application in question allows the user to access hundreds of thousands of … well, let’s just say records in a database. The content of this database changes minute by minute as other users add and update records. The user is an independent business person who operates out of a home office and needs those records to do her job.
The user relates that when she turned on the application that morning she couldn’t see any “records.” In fact, she couldn’t even sign into the database. Because nearly all users of this particular system use a phone modem the support desk person eventually gets around to asking the user if her phone was plugged into the computer.
The user finds this an odd question: as far as she knows the computer was never plugged into the phone and she has no idea why it would need to be. “Humor me,” the support desk person asks “and see if the phone is connected to the computer.” After protesting that the phone can’t possibly have anything to do with it, a minute or two later the user comes back on the phone to say that no, the phone line is not connected to the computer (there’s an “I told you so” hidden in her comments), although there IS a phone jack laying on the ground behind it. The support person walks her through the connection process and asks the user to restart her computer.
You can guess the rest.
This story was told to me by the support person who got a good laugh out of it. How did this lady think her computer and application got access to those hundreds of thousands of rapidly changing records if not via the phone? I got a good laugh out of it, too, and have retold this story many times when the need arose to show just how dumb users can be.
But was the user dumb? How much could she have been expected to know? Did the support person handle this call correctly?
I’m going to give examine this “true story” in future blogs and see what we can learn.