so...made a call to business critical support this week

there's been a lot of chatter recently on the yahoo groups concerning microsoft's business-critical support.

it's been particularly amusing to your friendly neighborhood happyfunboy how some folks like to get way too bogged down with certain minutae, and endlessly debate whether the word the should in fact be the word a in certain terms of service.

sheesh!

now i don't know what the rest of the visitors here at the funcave have to do every day, but i certainly don't have the time to waste like that.

so...for those of you who have never called the business-critical support line, or who have never heard of it, or who aren't sure what i'm even talking about, here's a little present from me to you:


happyfunboy's super awesome guide to calling microsoft business critical support without looking like an idiot


step 1: make sure the problem really is business critical

sorry...but all users being unable to open their favorite mouse-training application is not a business-critical issue. however, all users being unable to open the company's primary line-of-business application, because that application's server has multiple services that are not starting and it will not login to the desktop, all after a Microsoft patch was installed...is a business-critical issue.


step 2: try to troubleshoot as much as you can, and gather the most specific info you can before calling

don't call the business-critical support line and say something moronic like uhhhh...the server's just down, but it needs to be working so people don't realize i'm an idiot and should be fired. do a little bit of work, so you can instead describe the issue specifically, such as:

no users are able to get into their primary line-of-business application, which runs in terminal services, since they cannot login successfully to a terminal session. they are presented with a login prompt, but are immediately logged back out when they try to login. the server console presents a login prompt, but the same behavior is observed, both with domain accounts and local accounts. the machine is running windows 2000 server with service pack 4. connecting to server using administrative tools from another server is possible. the error log shows multiple services not auto-starting at boot, all showing path errors or missing file errors. all these errors follow entries showing a critical patch was installed. checking those services shows a filepath on c:, but services that are starting show an e: path. disk management shows the drive letter e: assigned to the boot partition. another 2000 server in the environment shows no problems whatsoever.

quite a difference, huh?


step 3: be in front of the server, then call...not the other way around

honestly, step 2 should automatically take care of this, because you'd prolly have to be in front (or remoting somehow) but you'd be surprised how many folks think that "pre-emptively" calling somehow makes them awesome. all you are doing is potentially clogging up the line for folks who have been diligent enough to complete step 2. so don't be a greedy jackass, and wait to call when you are in the proper place to actually be efficient.


step 4: be calm

actually, this prolly should be step 1, since...really...you need to be calm in front of your customers/superiors/whoever is paying you to do the work. because if you are acting all nervous and freaking out, then they are not only going to get way freaked out about the problem...they are going to get the impression that you are someone who causes their problems to be magnified, not someone who makes their problems go away. if you want to stay employed, you want to be seen as the latter.


step 5: call the right number, and listen to the voice prompts to get to the right area quickly

ok...this is perhaps a bit basic, but you'd be amazed at how many uber-geniuses can't seem to operate something as simple as a telephone keypad. hey...if you can't keep it together long enough to navigate a couple of button presses on your phone...you definitely are in no shape to be doing any advanced troubleshooting on a sick server, especially if the steps involve regedit in any way, shape, or form. revisit step 4 again if need be.


step 6: be courteous

you're gonna be asking this person to help save your ass, so the least you can do is treat them like a fellow human being, not some robot who should telepathically be able to know exactly what you are talking about without you having to expend any effort. if there's a bit of a lull, and you're waiting on something to complete, talk to them like anyone with whom you might strike up a conversation. like...so where are you located at? how's your weather out there? if you know of any major current events going on near them, you could mention that. basically, it doesn't really matter...it's simply a way for you to let them know that a.) you realize they are a fellow human being, and b.) you respect them for that, and c.) you're not a raving lunatic idiot.

you might be amazed at the amazing level of service you will get.

also, if you miss it when they first say it...ask them their name...and write it down. talk to them using their name. it is a sign of respect.


step 7: be patient

it may take a bit of time for them to fully grasp the issue. as in...more than 30 seconds. don't be a jerk. you obviously can't fix the issue by yourself.


step 8: don't assume they are always correct

ok...this is a switching of the gears a bit, perhaps. but, honestly...you yourself should be the uber-expert on the exact environment you are working in.

if you're not...well, you're basically a slackass. good luck with that, because i have no sympathy for you, and don't really care if you get canned or not.

no one else knows the full and exact details of your environment that you do. so it is perfectly ok to question something if it could possibly make things worse for you.


step 9: make sure you know the exact affect of any change they ask you to make

that includes whether a change is permanent or not. and...if it sounds like something they are asking you to do is not germane to the issue you are seeing, call them on it.

this is actually something you should always do with any tech support line. but it's even more critical when...well, your problem is business-critical.


step 10: stay on the phone until the issue is resolved

business-critical support will stay with you until the issue is resolved, so stay on the line.


step 11: be realistic

validate any resolution is solid. test other functions. check for other lingering effects. but don't try to stack on totally unrelated issues. if you call because a patch farked your server, and then try to untangle the pitiful shape your dns infrastructure is in with the same engineer, you prolly won't get very far. these folks are experts because they know a very specific area inside and out, forwards and backwards. chances are, they will be of no help whatsoever. and...odds are...the other issues wouldn't pass the "business-critical" litmus test on their own.


step 12: be gracious and grateful

when they save your bacon, thank them. profusely. tell them they rock, or kick ass, or whatever you like. mainly...thank them. folks who save your bacon can never be thanked too much by you. also...if you are sent a follow-up survey about your experience, fill it out. and thank them all over again in your responses. praise them profusely. because if you do...they will be rewarded for doing a good job. which keeps them motivated. and perhaps they will save your bacon again at a later date.

that's it...nothing difficult really.

for the record...the issue mentioned above actually happened to one of my clients on friday.

when i got onsite, it took:

10 minutes to assess the situation
5 minutes to call the number and get connected to an engineer
5 minutes for the engineer to research the info
5 minutes to walk me through the fix using regedit.

one reboot later, and the issue was resolved.

you should have seen how the eyes of the folks there nearly popped out of their heads. because of the business they are in...this particularly client is not easily impressed when it comes to tech support.

however...they were impressed. and it immediately demonstrated to them the value of our being a microsoft partner.

so...if you really need it...use business-critical support.

it's real, they're awesome, and a very valuable resource.

just don't be an idiot and try to abuse it.

then it might get taken away from all of us.

that would make me a very angrymadboy...

and nobody wants that!