Posted on Friday, 10th March 2006 by sean
I’m a self professed Cisco bigot. I use the term “bigot” because that’s what the Nortel sales guy called me and the name stuck. I’ve also heard the term “customer evangelist” thrown around by marketing people — a customer who is happy with the company, and tells others about it.
Why do I willingly pay twice the price (granted, it’s not my money) for the same hardware? The answer is support.
I’ve called in a lot of cases in my 6+ years of Cisco use. In most cases it’s a bug I’ve tripped across and need to get help, sometimes it’s getting advice. You can call for anything and they’ll help you.
So today I found myself needing TAC’s help. Before I get into it, when you open a case you assign it one of 4 categories
4: product information
3: non critical configuration/troubleshooting assistance (this is the default)
2: network degraded
1: network down
After an upgrade last night, a couple of legs on our voice network was performing very poorly. (Technical people, we’re running PRIs between our phone switches into the router, which translates it into an ATM CBR PVC and it pops out as PRI on the other end into the PBX. It’s not an uncommon practice from what I can tell, but I still get funny looks when I describe it to people). After the upgrade the router was running at 90%+ CPU usage, and voice calls were dropping or experiencing poor quality. The upgrade was needed to get some features/fix bugs, so I’d rather not revert back to the old image.
So, I called TAC. I called them on the phone so that I could put this case at a severity 2. Unfortunately the guy who took my call forgot to change the priority, so after checking the case on the web and adding the usual information (show tech, a better description of the problem), I called back and requested the case be reassigned to sev 2. I’ve only ever called in one sev 2 before and that was some time ago. Most of the time I’m able to get the network working again and I need TAC after the fact, but this is one case where we were running degraded and needed to parachute in the big guns.
After the dispatcher got my contact information confirmed, he put me on hold to find someone to help me out. As it turns out, my case was initially misdirected, so the dispatcher brought someone from the ATM group on the phone to ask a couple of questions. (I’m horrible with names, so I only remember a couple of of the whole event). That guy had to go check on something so he ducked out of the call leaving me with the dispatcher.
So the dispatcher and I had a quick chat (I didn’t know TAC was in Salt Lake City, Utah) until the ATM guy came back with some advice on where to send my ticket. I was put on hold again while the dispatcher found someone else (Adam, IIRC), who asked a couple of specific questions, before putting me on hold again until he brought in David.
David had a few questions, and then took the case. We had a discussion about what was going on and he told me he had run into a similar problem a week or so ago and knew that the image I was running was known to run the CPU harder than other images. To confirm this, he logged in remotely to my router and poked around.
In most technical support organizations I’ve dealt with, having the support guy log into your own gear to diagnose is unheard of. With TAC, it’s a frequent occurence. I’ve had it done on several occasions, and these were regular sev 3 cases (I remember one case where the guy logged into a 3com box to get more information about the problem!). After he looked around a bit he suggested I downgrade a few levels to a specific version that he thought was best for our environment.
Here again is where TAC is different. “Change to version x.x.x and call me when you’re done” is a common thing to hear from tech support. But I couldn’t just reload the router in the middle of the day, since it was working for about half of our voice network, plus our data network. So David did some further looking around and asked if he could make some configuration changes to try and alleviate the problem, which he did. (That the changes didn’t do anything doesn’t matter… )
Rather than drone on, I’ll just say that we agreed that I’d upgrade that night and update the case. True to his word, the router’s CPU went back down to normal levels and the voice network was tested successfully.
Seth Godin talks about making a remarkable product — one that people want to make remarks or tell their friends about. I think TAC is such a product. Sure, they solved my problem. They solved it quickly (they usually do). But that’s not it. The fix itself was easy enough, what’s remarkable is the process we took to get there.
Everyone I talked to on that call (4 people in total, I believe) greeted me, asked me how I was doing, and was friendly. Whenever I open a case, I get an initial greeting (not a canned one, either) and an explanation of the next step. If something’s going on during the case and I have a question, even unrelated, I’ve always got my answer. The case isn’t closed until I give permission (unlike other companies I’ve dealt with…). After the case is closed, I get a bingo card, a quick survey asking about my satisfaction with the case.
Cisco is a company that puts satisfaction foremost. I once checked some of the boxes on my bingo card as “dissatisified” and the engineer called me to apologize. Our company recently went through an RFP process to get a new voice system. The other companies started off by putting charts of their earnings, their big clients, and other financial figures. Cisco opened with a graph of their customer satisfaction ratings, including their goal for the upcoming year.
I’m continually amazed whenever I talk to someone at Cisco, from the sales people to TAC. They’re all focused on customer service and making the customer happy. I’m lead to believe that a good part of the compensation of the technical staff has to do with customer satisfaction ratings of the group as a whole, not just individuals. This promotes sharing of knowledge, and makes everyone involved work to the same goal.
The support contract I bought to get this service is no different than any other enterprise. In fact, I was never even asked for contract information. I believe anyone calling in with a problem would get the same service I did.
After I got off the phone with David, I took a glance at the jobs site over at Cisco and looked for TAC positions. What struck me was that the TAC group was described as “Customer Advocacy”. Not “support”, it was “advocacy”.
As I said before, I’ve opened up my fair share of cases. With rare exception, I’ve always been happy. But this case was something remarkable — something worth making a remark about, as Mr. Godin would say.
I know a lot of people from Cisco read this site, maybe even some people I’ve dealt with in the past. So for everyone over there, Thanks.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Posted in General | Comments (3)
March 12th, 2006 at 10:51 pm
Hi,
The support and community behind Cisco is vast compared to the non existance of a Nortel community. Ironically they just don’t exist 
I am also looking to do a similiar project to what you are using. PRI-> IP
I have said the same thing in relation to Nortel
March 16th, 2006 at 6:34 pm
I have had my fair share of poor technical support from TAC, but I usually have little problem getting the case re-queued with a competent tech. When I do get one, they are usually super-knowledgable and like you say, have no hesitation to logging into your equipment remotely. I also like the fact that you’re given a direct line to the support person you’ve been dealing with. This helps keep things simple when you’re dealing with a complex issue as you don’t need to re-explain certain things to the next engineer you get on the phone.
I have had horrible experience with SonicWall’s support team. No matter what the issue, they always tell you to upgrade to the latest firmware before they even hear your problem.
April 6th, 2006 at 5:08 pm
I would say you definitely are a Cisco customer evangelist : )
Thanks for sharing the story.
Jackie Huba
Co-author, “Creating Customer Evangelists”