![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
the-s-guy.livejournal.com posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
techrecoveryTo start you off, here's fifteen frenetic and fantastic finalists. Add your own revelations!
- Reboots. Users who object to a reboot (or sound like they might, or lie about having rebooted) are usually quite happy to reboot "again" if you tell them you need them to read off the words which come up (BIOS crap) during the process.
- Cable checks. Users will lie about having checked their cable is plugged in, but they'll be happy to unplug a cable, blow in the socket or on the pins, and plug the cable back in.
- Questions. Never, EVER ask a question which can be answered with Yes or No. Users will randomly pick the one which screws up your subsequent troubleshooting the most. Instead, ask them to describe EXACTLY what is on the screen.
- "Nothing" is not an acceptable answer for what is on the screen. "What color of nothing?" can get the information flowing again. More generally, "What color/flavor/type/shape of X?" can get dead-end answers back on the info train.
- Make the user provide the information. If you data-dump at them and end with "...Yes or No?", they will panic and pick something random. Never, ever data-dump a caller unless you really do want them in total Dummy Mode. Don't give them the background of why something is broken or what might be causing it.
- Unless you have additional troubleshooting you want to walk through, or are happy to chat about trivia with a caller, it's often easier to put them on hold if it's going to take you more than ten seconds to call up more information from somewhere. A quick "OK, one moment while I double-check this information for you" can be all you need.
- Don't use phrases that imply that the caller has a choice about what you're going to do, unless it truly is a customer choice instead of a technical process. This can be hard to spot in your own speech, especially if you're also concentrating on the results of running some tests, but you can listen for it in other techs' sentences and if you're allowed to record your calls for later quality checking. You are In Charge, you Know What You Are Doing, and it can really help if your choice of sentence structures reflect this.
- Likewise, do not dump a whole bunch of instructions on a user unless you know for a fact they are writing it down and will not get it wrong. Walk them through each step one at a time. You can sometimes suspend this guideline if the caller is another tech, but be very sure of this first.
- Abrupt call closures can be a godsend. If you know a call is going to go badly, or it already is, keep aware of the meta-context and be able to switch a conversation abruptly to "Well, I'm sorry we can't help you with that. Was there anything else? Thank you for calling," and hang up. There is no value in allowing a dead-end conversation to keep using up valuable tech time.
- Ticket templates are a two-edged sword. Any more than a handful swiftly turns into a nightmare of trying to keep track of and choose the precise correct one for any given situation. However, a very small number of templates for very common situations and/or ones with enormous boilerplate-to-signal ratios can help you immensely. If your ticketing software allows pasting of text, keep a half-dozen or so on hand in a text file.
- Corporate password resets are better done by users' direct management, for a number of reasons.
1) There are usually more managers than technicians in a large organisation;
2) Direct supervisors and managers are often easier to get hold of quickly, particularly on a Monday morning;
3) Outsourcing password resets can have a huge impact on the amount of collective time wasted on hold on Mondays (and sometimes Tuesdays), and time is money;
4) Having password resets done by someone who can physically verify a user's identity face to face is much better security; and
5) Users are less likely to casually forget their passwords every week if they have to go face their manager instead of phone some anonymous technician. Particularly if they've been using the hold time as an excuse for not working on Monday mornings, or if they've been blaming their own poor performance on "those IT guys still haven't fixed my computer".
-- Seriously, if it's not a policy of your large corporate employer, it should be.
- Good call control and efficient ticket processing can be worth five times your entire salary.
- Notepad (or any other simple text editor) is perfect for when you need to start typing something but the application or utility you need to type into hasn't finished loading or bringing up its next page. Keep a blank Notepad window open permanently and use it as a spooling buffer. It cuts down on average handle time and avoids big gaps in the conversation which can lead to a loss of call control.
- If you answer a call and there is no-one else on the other end of the line within three seconds, hang up. I got it down to about one-point-four seconds after training myself to listen for certain telltale triggers regarding if there was anyone there or not. It's a rule which can be relaxed a bit if there is no-one else waiting in the phone queue, but otherwise, ZAP.
- A default corporate support policy for newly released production software may seem esoteric, but it can save you from weeks or months of your workplace being a living nightmare.
- Reboots. Users who object to a reboot (or sound like they might, or lie about having rebooted) are usually quite happy to reboot "again" if you tell them you need them to read off the words which come up (BIOS crap) during the process.
- Cable checks. Users will lie about having checked their cable is plugged in, but they'll be happy to unplug a cable, blow in the socket or on the pins, and plug the cable back in.
- Questions. Never, EVER ask a question which can be answered with Yes or No. Users will randomly pick the one which screws up your subsequent troubleshooting the most. Instead, ask them to describe EXACTLY what is on the screen.
- "Nothing" is not an acceptable answer for what is on the screen. "What color of nothing?" can get the information flowing again. More generally, "What color/flavor/type/shape of X?" can get dead-end answers back on the info train.
- Make the user provide the information. If you data-dump at them and end with "...Yes or No?", they will panic and pick something random. Never, ever data-dump a caller unless you really do want them in total Dummy Mode. Don't give them the background of why something is broken or what might be causing it.
- Unless you have additional troubleshooting you want to walk through, or are happy to chat about trivia with a caller, it's often easier to put them on hold if it's going to take you more than ten seconds to call up more information from somewhere. A quick "OK, one moment while I double-check this information for you" can be all you need.
- Don't use phrases that imply that the caller has a choice about what you're going to do, unless it truly is a customer choice instead of a technical process. This can be hard to spot in your own speech, especially if you're also concentrating on the results of running some tests, but you can listen for it in other techs' sentences and if you're allowed to record your calls for later quality checking. You are In Charge, you Know What You Are Doing, and it can really help if your choice of sentence structures reflect this.
- Likewise, do not dump a whole bunch of instructions on a user unless you know for a fact they are writing it down and will not get it wrong. Walk them through each step one at a time. You can sometimes suspend this guideline if the caller is another tech, but be very sure of this first.
- Abrupt call closures can be a godsend. If you know a call is going to go badly, or it already is, keep aware of the meta-context and be able to switch a conversation abruptly to "Well, I'm sorry we can't help you with that. Was there anything else? Thank you for calling," and hang up. There is no value in allowing a dead-end conversation to keep using up valuable tech time.
- Ticket templates are a two-edged sword. Any more than a handful swiftly turns into a nightmare of trying to keep track of and choose the precise correct one for any given situation. However, a very small number of templates for very common situations and/or ones with enormous boilerplate-to-signal ratios can help you immensely. If your ticketing software allows pasting of text, keep a half-dozen or so on hand in a text file.
- Corporate password resets are better done by users' direct management, for a number of reasons.
1) There are usually more managers than technicians in a large organisation;
2) Direct supervisors and managers are often easier to get hold of quickly, particularly on a Monday morning;
3) Outsourcing password resets can have a huge impact on the amount of collective time wasted on hold on Mondays (and sometimes Tuesdays), and time is money;
4) Having password resets done by someone who can physically verify a user's identity face to face is much better security; and
5) Users are less likely to casually forget their passwords every week if they have to go face their manager instead of phone some anonymous technician. Particularly if they've been using the hold time as an excuse for not working on Monday mornings, or if they've been blaming their own poor performance on "those IT guys still haven't fixed my computer".
-- Seriously, if it's not a policy of your large corporate employer, it should be.
- Good call control and efficient ticket processing can be worth five times your entire salary.
- Notepad (or any other simple text editor) is perfect for when you need to start typing something but the application or utility you need to type into hasn't finished loading or bringing up its next page. Keep a blank Notepad window open permanently and use it as a spooling buffer. It cuts down on average handle time and avoids big gaps in the conversation which can lead to a loss of call control.
- If you answer a call and there is no-one else on the other end of the line within three seconds, hang up. I got it down to about one-point-four seconds after training myself to listen for certain telltale triggers regarding if there was anyone there or not. It's a rule which can be relaxed a bit if there is no-one else waiting in the phone queue, but otherwise, ZAP.
- A default corporate support policy for newly released production software may seem esoteric, but it can save you from weeks or months of your workplace being a living nightmare.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2010-02-22 06:05 pm (UTC)If you're remoting in and don't want the user to use the mouse, tell them to turn it upside-down. Many users will be amused enough at this request to comply.
no subject
Date: 2010-02-22 06:10 pm (UTC)no subject
Date: 2010-02-22 06:12 pm (UTC)no subject
Date: 2010-02-22 06:13 pm (UTC)no subject
Date: 2010-02-22 06:14 pm (UTC)no subject
Date: 2010-02-22 06:14 pm (UTC)A tech's primary information source should always be the computer itself. Failing that, making the caller read out exactly what's on the screen with no personal input of their own.
no subject
Date: 2010-02-22 06:15 pm (UTC)I imagine it cuts down on the "Hey, you should do my job for me, hyuck" comments, too.
no subject
Date: 2010-02-22 06:17 pm (UTC)no subject
Date: 2010-02-22 06:19 pm (UTC)no subject
Date: 2010-02-22 06:21 pm (UTC)no subject
Date: 2010-02-22 06:29 pm (UTC)no subject
Date: 2010-02-22 06:34 pm (UTC)no subject
Date: 2010-02-22 06:40 pm (UTC)I don't mind doing the very occasional password reset when a user calls up and their supervisor is off sick and their manager is at lunch and all the other managers in their area are in a day-long workshop, or it's 6am in their timezone and no-one else is on site. We're so used to being an emergency last-resort safety net that anyway that it's no biggie. It's only when there are five bazillion password reset requests a day that it gets stupidly inefficient to have them clog the same channel as general tech support calls.
no subject
Date: 2010-02-22 06:43 pm (UTC)no subject
Date: 2010-02-22 06:44 pm (UTC)no subject
Date: 2010-02-22 06:48 pm (UTC).LOG
no subject
Date: 2010-02-22 11:28 pm (UTC)This has gotten me into trouble.
I however have not been told off for disconnecting hold music. Seriously, 10 second wait does NOT require you to stick me on hold... and pray tell how will you know I've answered the phone if you've got the freaking hold music on. *transfer to Mr D. Tone*
no subject
Date: 2010-02-22 11:42 pm (UTC)no subject
Date: 2010-02-23 12:38 am (UTC)As an example, a few days ago I had Mr Exasperated calling wanting to know why Admin hadn't sent him his new product key which he'd paid for by posting in a cheque two weeks ago. I said the system wasn't showing his payment as cleared yet, and he got upset at the fact that they've been customers for 10 years and we 'still don't trust them' despite the fact that they've never missed a payment and it's a piffling amount anyway.
My first thought was 'if you've been paying by quarterly cheque for ten years why is it a surprise that it takes 2 weeks to process? Why not just send the damn thing a week earlier if it matters to you that much? It's not like the software actually stops working until a month after the expiry date.
I said I didn't know what all Admin's policies were but that I didn't know we even accepted cheques at all any more, and that I was fairly sure that new customers only got the option of direct debit or lump-sum payment by card/bank transfer: thing 1 that he thinks he's getting that's special. I also offered to check his account every morning until it said it was cleared and call him and give him his product key over the phone - doesn't that just make him feel like the most special snowflake ever? From my POV it's a note on a post-it and *something* to do in the pre-9:30 dead zone. We do a lot of callbacks early morning and late afternoon, mostly for queue management - if it's busy and there's no second-line tech available straight away, the cust will be offered a callback. Means we can spread our workload more evenly, the customers spend less time getting increasingly annoyed by being made to listen to Dolly Parton, and the tricky issues go to people who're already pretty sure they know how to resolve them.
I hate being idle. Customers always seem to think we're going to be busier than we are - probably because we're do that evening out. From the customer's POV that callback was me offering to run around after *him* when I *should* be taking incoming calls and helping people who have Real Problems - as soon as I offered, he was nice as pie, and refused the callback saying he didn't work every day so he'd call himself in 2 or 3 days.
no subject
Date: 2010-02-23 12:41 am (UTC)Me: *standard greeting*
Phone: nothing
Me: Hello?
Phone: Nothing
Me: HELLO? OK, I think we may have a phone fault so I'm sorry if you can hear me but I can't hear you so I think you're going to have to try again. *CLICK*
Let's see, what would I add...
Date: 2010-02-23 01:12 am (UTC)Customer dyslexia doesn't really need correcting if you understand them, and unless you're really green you will. It really doesn't matter if they think their printer brand is Lemmex, their browser is Mozarella Firebox or that you just took them into the System Conflagration Manager. You know what they mean, and correcting them is just going to make them moody and defensive.
The initial greeting should inspire confidence. Rehearse it well and say the same thing every time so you don't fall over your words. Be aware of your tone of voice and be sure to speak clearly. If you've got that down it'll just flow without you having to think about it so you're sounding calm and confident about resolving their issue (which does influence the customer) even if your machine has just bluescreened. You can write their details on a bit of paper and put it in later and the customer should be none the wiser. The trainee I had this morning hadn't thought in advance what he was going to say when taking his first call, so forgot to say good morning, gave his name twice, and forgot to ask for the customer's name - I ended up having to take the call from him because the customer just wouldn't follow his instructions.
One for app-support: If the customer has an issue you've never seen before, you have no idea how to fix it, and you've checked with your colleagues that neither have they, assuming it's a genuine bug and your devs are going to fix it - eventually - try thanking the customer for bringing it to your attention, and, if it's going to be a few weeks (usually is) call them back every so often when it's quiet and get them to check a few random things in the control panel or msconfig as "QA have asked for more information as they're still trying to reproduce the error here." It makes it look like there's someone who is dedicated to this one issue, and also makes sure that it hasn't solved itself in the meantime.
If what the customer is saying is up on the screen is something bizarre and unexpected, while it's often safe to assume the customer is being an idiot or wilfully difficult, it's also entirely possible they've just been shafted in a new and interesting way by their IT department/children. Or that they've found a fascinating new bug. But while you should be open to these possibilities, stupid/difficult is still the most likely.
Whatever you want them to find, describe something immediately below/to the left of it not the thing itself, they will almost always be able to see the thing you want and not the one you actually pointed them at.
no subject
Date: 2010-02-23 01:31 am (UTC)Remote assistance is almost as useful- it generally lets one party as a time control the keyboard/mouse.
In any case, also have them *on the phone* whilst doing this- a little kindness in that regard goes a real long distance.
no subject
Date: 2010-02-23 01:37 am (UTC)According to the stats our ticketing system at $work has, password resets for one department in particular are consistantly the #1 ticket generator. Fortunatly for us, their managers *have* to open the request due to a policy in place. (that, and they can queue up multiples while they have us on the phone and in one of the systems which has an odd quirk of not letting anyone else login whilst diddling with the user passwords...)
While this might seem like a perfect place for better user training, I'd like to point out that the average end user in this department has to remember no less then 4 or 5 different applications, all of which have their own username/password combo. (And I'm going to shoot down those folks who will immediately whine "well why don't you implement a single sign on system?!!?" with the tried and true 'been there, done that, sucked balls and was a compleat waste of money and time for our systems...' )
no subject
Date: 2010-02-23 01:38 am (UTC)I have been known to put my phone on speaker and mute when I call into a vendor for support, because I really do have better things to do with the wait time. (like typing up a log in notepad on what I'm about to talk to said vendor about...)
Re: Let's see, what would I add...
Date: 2010-02-23 03:43 am (UTC)Customer dyslexia doesn't really need correcting if you understand them, and unless you're really green you will. It really doesn't matter if they think their printer brand is Lemmex, their browser is Mozarella Firebox or that you just took them into the System Conflagration Manager. You know what they mean, and correcting them is just going to make them moody and defensive.
YES, THIS ONE, YES. I am sick of listening to the people around me get fucking snarky with 90 year old, half-blind grandparents who don't know what a 'rooter' is, or that it's Linksys, not Lanksee. You know what they mean, goddamnit it, you are scaring them so bad they now they will not call in until they fuck something up so horribly that it requires a truck roll, and possibly a tearful, frustrated hour long call before that.
no subject
Date: 2010-02-23 03:45 am (UTC)If you are dealing with a user/customer who has more than one of an item and you work on it? In any way?
RECORD THE FUCKING SERIAL NUMBER.
"Reset DCT" is NOT a valid ticket. Especially if the issue persists, and the customer can't remember what the tech did, or had them do, or what one they worked on. Not gonna cut it. [I hate having to get someone to lift up their stupid terminal to read off the SN, because it just aggravates the hell out of them and is unnecessary. They think we have all this information written down, because we should.]
no subject
Date: 2010-02-23 03:47 am (UTC)no subject
Date: 2010-02-23 05:48 am (UTC)no subject
Date: 2010-02-23 05:59 am (UTC)Re: Let's see, what would I add...
Date: 2010-02-23 06:01 am (UTC)no subject
Date: 2010-02-23 07:11 am (UTC)no subject
Date: 2010-02-23 02:58 pm (UTC)This is also for 2000/XP and possibly Vista and Windows 7 obviously.
We use it at work when we can; it's a useful tool for getting information from systems in protected areas that require escort and whatnot.
no subject
Date: 2010-02-23 02:59 pm (UTC)no subject
Date: 2010-02-23 03:02 pm (UTC)no subject
Date: 2010-02-23 03:05 pm (UTC);)
no subject
Date: 2010-02-23 04:57 pm (UTC)If you have doubts about how well a cable is plugged in, it needs to be unplugged and replugged, because it's totally possible that it will APPEAR to be plugged in well, that "just wiggling it" won't help any, but that unplugging it and replugging it will seat it solidly where it was not solidly seated before.
no subject
Date: 2010-02-23 05:04 pm (UTC)Hell, incoming calls generally mean MONEY for me - I'm a consultant and a lot of my clients are on an a la carte basis, not a retained basis - but even so, that's a hang-up.
If it was a call that was actually going to make you money, they'll call back. If it wasn't a call that was actually going to make you money, then that's just that much LESS reason you'd want to hang around listening to their other conversation.
Plus, it's just a damn good idea to keep them in the mindset that dealing with you is important. NOT getting clients in that mindset leads to you having to stand around literally for hours in their workplace because nobody wants to stop working for 10 seconds to let you fix the thing that they're loudly bitching about the entire time you're... not fixing it, because they won't stop for 10 seconds.
(The other school of thought is to cheerfully stand around for as long as they want to keep you thumb-twiddling, and just charge your hourly rate and be happy about it, but I find that it's better in the long run to get them in the frame of mind that your time is valuable. Otherwise, they're eventually just going to think "that guy's time isn't valuable anyway, and here is some other guy who wants less money to stand around not being valuable, so why wouldn't I switch?")
no subject
Date: 2010-02-23 06:06 pm (UTC)Re: Let's see, what would I add...
Date: 2010-02-23 08:02 pm (UTC)Although, I do frequently hear other techs keep asking the exact same question, over and over, hoping to get a different answer. It's like they want to have a problem with the customer, I swear.
no subject
Date: 2010-02-23 09:47 pm (UTC)A Godsend for my "boilerplate" text has been a utility called Texter (http://lifehacker.com/software/texter/lifehacker-code-texter-windows-238306.php).
It was put out by Lifehacker, or at least that's where I found it.
I haven't done the research to determine if it's portable or not, and yes it's an install instead of just a text document, but I've had positive results thus far.
Yes, but it can bite you
Date: 2010-02-23 11:40 pm (UTC)In general this is good advice, but there is such a thing as being too smooth. I have a basso "radio voice," developed when I worked as a DJ umpty years ago, and never lost. As an L1 phone tech, I'd start a call "Thank you for calling {$COMPANY}, {$BoilerplateScript}. This is Sam, how may I help you?" and at least once a day I'd get several seconds of dead silence, followed by "Oh! I thought you were a recording."
Re: Yes, but it can bite you
Date: 2010-02-23 11:55 pm (UTC)no subject
Date: 2010-02-24 04:40 am (UTC)I've always found amusing/frightening/annoying the ones who start to read what's on the screen, verbatim, but for some strange reason always slip to "blah, blah, blah" instead of reading off the information that will *actually* help.
'The error message reads "there was a problem connecting to the server blah blah blah. error code blah blah. username blah blah."'
On password resets
Date: 2010-03-12 03:16 am (UTC)Also, on a side note, after havening a little Star Wars marathon for myself (III and IV this evening), I seem to read all the posts in the voice of C-3PO.