It's Not What You Think You Know

There's a sense of inertia in the tech industry that becomes more and more concrete as you rise in the levels of IT hierarchy.  The more technical the person you're talking to, the less flexible they are to change - even if it's changing something to the CORRECT setup.  The old adage of "it's always worked for me before; it should work for me now" should NEVER apply to the technical field, considering the changes that occur daily to every area of support.

This applies doubly for those who are calling in for support on an issue - and even moreso for support on a program or service provided by an entirely different company.  No matter how you might have had a service jury-rigged in the past, there's no way to tell whether those settings will still hold.

And most importantly: when it's determined that you're doing something the wrong way, stop asking how to get it to keep working the wrong way!

Me: Thank you for calling [Company Name]; my name is FerroMancer.  May I ask who I'm speaking with?

Cx: This is Cx with [Another Company].

Me: How can I help you, sir?

Cx: We moved our equipment - clients and servers - to another location, and now we're having trouble connecting through your program.

Not a problem, the program needs to be reconfigured to work on the new location.  Of course, the best way to do this is...

Me: If you uninstall and reinstall the client application from the install point on the server, you'll create the proper pathing to get the client working...

Cx: It was working before, and it's not working now - we should be able to change the settings to get it to work.

Strike 1 - When a tech gives you advice on the program he supports, take it.  

Strike 2 - Don't try to get a failing program to start working again if you can replace it with a working program.

Strike 3 - It was working before, and you changed everything.  What worked before won't necessarily work now.  

Me: OK, what do you have for the physical database name?

Cx: It's showing the server route - "\\DD\COMPSERV\COMPSYS.DB"

Me: OK, that's part of the problem; the program connects to the engine on the server first, so the path that's indicated should be the path as if you were already connected to the server.  What drive is the COMPSERV folder located on on the server?

Cx: I have it mapped to "S".  It's always been mapped there.

Me: No; what drive is it on on the server?

Cx: But I'm on the client.

Me: Right, but you're connecting to the engine before you ask about the path.  What drive on the server?

Cx: Let me check...it's on the F drive.

Me: OK, then you want the path to be: "F:\COMPSERV\COMPSYS.DB"

Cx: It's always worked before, with the other path.

Me: It shouldn't have.  It needs the path in relation to the server itself.  Change the path to "F:\COMPSERV\COMPSYS.DB".

Cx: OK....it's not working.

Me: Did it change the path?

Cx: Yeah, now it's showing "DD\F:\COMPSERV\COMPSYS.DB".

Me: Ah...the system does that sometimes.  Windows takes whatever path it has set for a drive and applies it across the board.  We definitely don't want that, it's in the wrong format anyway.  We need to set it to "F:\COMPSERV\COMPSYS.DB"

Cx: But it was working before.

Me: With the way our program works, this is the way it should be set.

Cx: Why was it working with the other info before?

OK, now this is starting to piss me off.  How am I supposed to know how you managed to MacGuyver your system into working in a way it's not supposed to?  I have no idea.  But I'm telling you; THIS is how it should work, THIS is how you should connect, THIS is the protocol you should be using - TAKE the information and USE it!

Me: It might have had something to do with the network setup or the mapped drives, I'm not sure.  These are the correct settings, though.  Now, are the client and the server on the same subnet?

Cx: They're on a different domain.

Me: From you?  OK, but are they on the same subnet?

Cx: They're on a different domain.

Me: What do you mean?

Cx: I'm remoting in to them.

Me: Oh, so you're not in front of them right now.

Cx: Right.

OK, not a big thing, remote connections are a good way for admins to troubleshoot these days.  However...

Cx: Yeah; I have to remote connect to the client computer, and then remote to the server FROM the client I've remoted to.

THAT is just messed up.  Not only are you going to have a horribly slow remote session (and he was), you've got it set up so that your user can get direct server access.

Me: OK, on the server, go to Start, then Programs, then Comp Solutions, then Administration.

Cx: It's not there.

Me: ...are you sure you're not looking on the client workstation's desktop?

Cx: Nope, I'm on the server.

Congratulations.  You seem to have moved your servers around in such a way that you have entirely lost your administrative tools and server components, even though the base files and folders are still there.  You lose at Tech.

This conversation doesn't even get into the 'discussion' that we had about the proper protocol settings, the IP parameters, client access, or any of the other half-dozen problems that we experienced that could have been resolved by 1) listening to me and just trying to reinstall the app from the server and 2) forgetting how he HAD it working and focusing on how it SHOULD work.  Granted, with the loss of server components, he would have had a deeper problem anyway, but we would have found that out after 5 minutes instead of 20.

The moral of the story is: when you call in for support, you're admitting you don't know everything.  Listen to the person that you're getting help from.

More coworker hijinks.

So, over the last year, I've gotten really used to some of our Second level agents dumping calls. They ignore the people who have to approve their tickets and cold transfer (just dump the customer to the line) instead of warm transferring (talking to whoever you are transferring too before initiating the final transfer) Some have gotten slick and don't give customer their tracking number (which we can look up in third level :P). This often leads to a bewildered customer scratching their head, and one of us being pretty cheesed off that we basically have to dig for the ticket. A good chunk of the time the ticket contains little to no information, many times with a single sentence like "customer is havening trouble wih teh wireless we gave them". We look upon these as works of literary genius! (here's a bucket for the sarcasm). Sometimes even when we get a warm transfer, it's for a bogus reason. We tell the second level agent that it's not our department, and they sometimes like to sit and argue it with us. Here's one from today.

Me: Thank you for holding for ISP support. My name is Jacapo, how may I help you today?
T2A: Hey this is T2A from tier 2, I have a customer who can't set up sub users on their email account.
Me: Ok... Normally that's handled by you guys. Whats the problem? Are they getting a server error? is it not allowing them into the master account?
T2A: The customer just doesn't have their master account password and they need help setting up the sub accounts.
Me: Right. (as nicely as I can) That's your job, you need to try to reset the password through the password tool or walk the customer through it on the self help.
T2A: Tried that customer doesn't remember their security question answer.
Me: *pulls up tracker, sees there is no security question set* Right. I'm showing that they haven't set up a security question yet. You need to finish troubleshooting with the customer.
T2A: Well lead tech says it goes to you.
Me: No. It doesn't. All email trouble is handled by you, unless there is a server error.
T2A: But lead tech says it goes to you.
Me: Nope, sure doesn't. I am not taking the call, I cannot assist the customer. Please finish your troubleshooting.
T2A: Our support flow says it goes to you!
Me: Really? Cause I have access to your support flow, and no, it doesn't. Take the call back and finish your troubleshooting. Please.
T2A: Maybe you don't understand what your job is. This goes to you!
Me: Wait. What? What did you say? I know pretty darn well what my job is. I helped create and define my current job with the 12 other guys sitting around me. I did your job when it was first brought here. So I do know my job. Quite well in fact. That's why I get to sit in the big boy chair. Now I'm not going to make a huge deal out of this, but you need to take the call back, and finish your troubleshooting.
T2A: But lead tech says it goes to you! It has to go to you! I can't un send the ticket.
Me: No, but I can kick the ticket back to you, and who was the lead tech that told you this? I have them all on aim. I'll ask them right now.
T2A: umm... *silence*
Me: Look. I don't expect you to know everything, but you need to take this call back, finish with the customer, and stop trying to pin the email call on another department.
T2A: Thanks for nothing!!! *hangs up*.

I kick the ticket back down to him, and I decide I'll check on it in another 15 minutes, make sure he closed it and want not. I come back and check on the ticket 15 minutes later, the ticket had been assigned to First level support. So, I kick the ticket back to him, and precede to inform his supervisor. You can call me an ass but I hate dealing with agents like that.

Call avoidance is the number one factor in dissatisfied customer (I only care about the people who really need the support though. ;P) Failure to understand your job is a bad thing. And honestly. If I'm telling you I'm not taking your transfer. Ask why. If you don't agree with what I'm saying. You have a supervisor. He'll push it up here if it needs to. Otherwise, just learn what is and isn't your job. If you don't know. Find someone and ask. But seriously. Why argue? I'm not changing my mind, it sets an unrealistic expectation for the customers and honestly, if I take the call, I'm just telling you its OK to not do your job.

This is just a quick example. More detailed accounts will follow.

Been a bit, but I'm back

Been busy the last few weeks, so haven't really had time to update. But I'm back, you may all stop weeping ;) 

So, We've talked about a lot of types of calls, I personally think that the bad ones from the coworkers are a little more aggravating then the customers. 

Here's a little background. A lot of our modems have a standby mode. This is usually initiated by the simple pressing of a button, normally clearly labeled standby. Currently, we offer three modems that are capable of entering this mode. Now, standby mode means that the modem, for lack of a better explanation, "locks" the modem. No traffic out and no traffic in. People use this mode when they are leaving for trips and vacations and want a little extra protection to keep their network secure while no one is using it. Sometimes parents even use it to kill the internet to keep their kids offline when they don't want them to be (granted this only works when the modem is say, in the parents office behind a locked door where the kids can't get to it =P ). Now, we have three tiers of troubleshooting. Tier 1, Tier 2, Tier 3. 

Tier 1: Billing and rates, as well as very very basic internet troubleshooting. They are required to reboot modems and check to make sure the modem has a connection to our network and they also check for outages when applicable. If the modem is online and the customer can't surf the net, they are to transfer the customer to Tier 2. 

Tier 2: Pure troubleshooting of pc's, email, and all other products provided by our company. They reboot modems, routers and computers, and when applicable bypass routers to restore connectivity. They also know to check for standby on all modems where standby is an option. If the router is provided by our company, or if the problem likely exists on our network with the customer getting online, they pass the customer up to Tier 3. 

Tier 3: This is where I work. We handle all field tech calls, all business class calls, and generally field questions from all departments and fix anything given to us. We are the guys who get involved when no one else can fix it. We also deal with bad transfers from other departments. Bad transfers are caused by multiple factors. Most common is just lack of troubleshooting, or a lack of following the support guidelines at the other tiers. 

Now we do have a new group, called overflow. These are Tier 2 agents, given billing access, to help Tier 1 when Tier 1 has a service queue. We really do try to keep hold times at a minimum for our customers. 

Here's one I got from one of our overflow agents. 

Me: Thank you for holding for ISP support, my name is Jacapo, how can I help you today?

Tier 2 agent: Hey Jacapo, this is T2A from the overflow group, I have a customer who can't get online with our wireless, hardwired or wireless, wondering if you can take a look at it. 

Me: Sure, let me just pull up the ticket, what's the ticket number?

T2A: *provides me with the ticket number*

Me: *pulls it up, sees it's one of our modems that has a standby button. Time has taught me to ask if they have checked, even if I know the agent and know they are good at it. Hell once in a great while I even forget to check. No harm no foul. * Ok T2A, I see they have a modem with the standby mode on it, have you checked for standby on the modem?

T2A: Yeap, sure did. 

Me: *realizing that each one has a different light pattern* Are you sure the ONLINE light is lit and solid on the modem?

T2A: Absolutely, it's definately not in standby. 

Me: Ok then, transfer the customer through I'll take care of it. 

T2A: Thanks. Coming through in 3, 2, 1 *transfer*

Me: Thank you for holding. My name is Jacapo, I'll be giving you a hand from here on out. I understand neither of your computers is able to get online. Is that correct?

Cx: Yeap, neither can get online. 

Me: When did it start?

Cx: About three days ago. 

Me: Did the previous agent have you check the lights on the front of the modem?

Cx: Ummm... no, I can check now if you want though. 

Me: That would be much appreciated. Can you check to make sure that the ONLINE light is lit on the front of your modem?

Cx: Sure, let me just go to the other room *footsteps on hardwood floor while the customer moves between rooms* Ok. I'm here, and lets see... Nope online light is not lit. 

Me: Ok then easy fix. Push the button on the front of the modem, it should be on the right hand side, just press it once, the online light should come back lit up and solid. 

Cx: * I hear the click of the button* Ok. The lights back on now, what do I do next?

Me: You just go online sir, go ahead and give it a shot while I'm on the phone, both computers. 

Cx: Alright. *moves to the other room again, pulls up Internet Explorer on both computers* Hot damn! You mean it was that simple?

Me: Yeah, happens all the time kids and pets seem to love that button,  you can tape a bottle cap over it to keep it from being pressed accidentally if you want, but if you can't get online, just check to see if that light is on. If its not, just press the button. If the lights on and you can't get online, you can give us a call. 

Cx: Awesome! Why didn't the other guy do that? I spent an hour on the phone with him. 

Me: No clue sir, but I'll make sure he knows to check next time. Anything else I can help you with?

Cx: Nope, Thanks, you have yourself a great night.

*call ends*

So, I don't mind if the person misses it and transfers, no bid deal. but when I ask specifically if you've checked, its a courtesy. You need to, if you don't and your call is monitored, you fail the call, that loses you your bonus, and knocks your internal ranking down for shifts and such. If I ask you if you checked and you say no, and go back to the call, you won't fail it. But why did he feel the need to lie to me about it? Did he lie to me about it? I've had tons of transfers from this agent, I'd say 50% of them are bad, so I'm guessing he's lying. I don't know. But I did submit a note to his supervisor so he can be coached on it. It's just aggravating. I know they have metrics to meet and such. But I started as a Tier 1, back when they had to do more then they do now, and had the SAME metrics for call time and such. I worked Tier 2 and did all the troubleshooting and dealt with all the snotty customers with the "you have to be nice to them grin" I was able to meet metrics. So why dump a call right? dunno, but it pisses me off when my coworkers do it. *shrug*