Almost Great Service
-
The other day my son came into the office and told me he was having a problem with his XBOX. Apparently there were flashing red lights on it and he wasn't pleased. Especially since Mr. David Reed of Microsoft had just brought him a copy of Crackdown (thanks Dave!). He'd tried what he could think of, so we got on XBOX.com and went through the support options. After letting it cool down for a day, then following a couple other steps, we ended up calling customer service.
They responded quickly, and we went through some information and they determined I needed to send it back, much to the dismay of my son. The young lady gathered my information, including my phone number up front in case we were disconnected, and then said she was going to process the return and send me a box here at the end, could I just hold on while she submitted the claim.
I said sure and suddenly was disconnected. I don't think she meant to hang up on me, but I wasn't sure of the status. Since she'd gotten my phone number, I went back to writing and editing, expecting a call back. Thirty minutes later, as I was reminded by my son, she hadn't called, so I dialed back in, got someone else, went through giving my information and the support person said the claim hadn't been submitted. So he did and we went on without delay. But why take my phone number if you're not going to use it?
So what does my XBOX claim have to do with SQL Server and DBAs? Well it's not really my XBOX, Santa brought it for my son
, but I have to deal with it. This is similar to things that have happened to me in software support, but also when calling anyone for support, including corporate PC or server people. How often has someone said they would work on something, or started checking things, they know who you are, and then you don't hear from them again?How often have you done that to someone?
My wife tells me many issues and conflicts could be avoided with a bit more communication. I admit I'm not the best at that at home, but I do try to remember that at work. Responding to an email to say "I'm busy, but I'll get to it", calling someone back if you get cut off or just to update status is a good practice. People like to know what's going on.
Especially if you're working on a 2 hour restore. Even though you know it won't go faster, take a moment and reassure others that things are proceeding.
Or that they're not. Either way it's a good habit to get into.
-
I am having a similar issue at this very moment with a third-party software vendor.
Apart from the needs for *constant* patches to the bugs in their software (no... not Microsoft
), the standard of their documentation is haphazard, inconsistent and wastes my time having to decipher it first before being able to apply patches.If they were able to do the job right and do it consistently to begin with, the whole customer-relations thing would proceed so much easier and leave a technical person with a better attitude towards the company (ie: by not being inclined to tell them that they're hopeless and being more forgiving when patches don't solve all of the problems).
True customer service really is a skill that very few people have mastered. Of course - those that *are* good at it don't make it out of the call centre because they're too good at their jobs.
A lack of planning on your part does not constitute an emergency on mine.
-
I had a related problem with a web page.
Some background. At one of my former clients I developed an SSIS package that pulled information entered into a customer service form from a SQL Server on the IIS box to a SQL Server inside of the firewall. I created email to send the information to the appropriate departments to handle the email.
After the site was live for about a month, I filled in a simple customer service request. I included my phone number as well as my cell number. A week later I got an email from a department saying I needed to call a number to deal with some problem. I was confused, why did they not call me, since they had two numbers.
In talking to other people in MIS, I learned that others had personal experience with this lack of intelligent customer service.
I'm glad to say this company is no longer my client.
Russel Loski, MCSE Business Intelligence, Data Platform
-
Even if it's just "You're in the queue and your turn will come up in X days", communicating about the situation saves a lot of bad feelings. It's called expectations management.
-
I have had same experiences with M$ more than once... and in an Corporate environment
* Noel -
I understand the problems you had with the support staff and not getting a callback. I experienced a similar situation with an XBox Live support person. He said, "We are having some server issues, please try again in two hours." So I tried again in two hours, same problem. I called support again only to discover that their business hours are from 7 AM till 10 PM. So basically the guy lied to me knowing that if I did call back in two hours, he wasn't going to be there. So I had to wait till the next day. Luckily I got a much friendlier person. Asked if there was any down time the previous day and she said no. She was then able to help me resolve my problem.
The point I'd like to make about that story and yours, is that we should have gotten the person's full name of whom we were talking to. That way, if we are unsatisfied, we can report them.
The second part of your editorial about giving feedback, I don't agree with. Nothing annoys me more than constantly having someone ask, "Are you done yet? Are you done yet? Are you done yet?" Especially when it's an unexpected problem that I've never seen before.
If I don't know what the problem is, how am I supposed to tell someone how long it will take to fix?
If I ask a co-worker to do something, I will give them a reasonable amount of time before I bug them again about the status. For example, last Wednesday I asked our DBA to wrap up some database changes that involves renaming some indexes and dropping some tables. Does it take 40 hours to accomplish this? No. But with everything else he may have going on, I plan on giving him a week to do it when ever he gets around to it before I bug him again.
And no, I don't expect an email every day from him telling me that he hasn't gotten around to it yet. I know he hasn't done it yet because the tables are still there.
What if 10 people asked him to do 10 different things today. Does he take the first one, start working on it, reply back to that person saying that he's working on it, and compose 9 other emails to the 9 other people saying that he will get to them later. Then the next day, he works on problem two, but still has to send out 8 emails to the remaining people telling them he hasn't gotten to their problems yet. And so on.
To me that just sounds like a big waste of time.
-
Part of the problem with MS was most likely that the person got another call as soon as you lost connection. At least that is my understanding from last time I talked to them. He had to analyze some stack dumps I sent him, and I asked if he could just call me back when done instead of keeping me on the phone, he replied "no, as soon as I hang up I will get another call". Basically sounded like they have no way of saying they are busy short of logging out of the system. Didn't use to be this way at their SQL support, at least not when I worked there (granted that has been 10 years).
-
Anders, didn't think about that, but I'd assume that someone would not take another call and finish this one. Especially as we'd spent time going through things.
I do think it's good to have status, though not necessarily every day. It's good to give a time estimate for work and if you'd going to miss it, let someone know. If I'm waiting on support, it's nice to know I haven't been forgotten. Cisco used to send an automated email everyday for open cases with an escalation link if I thought I wasn't getting the proper attention. I never used it and usually would hear from the support group every 2-3 days just to let me know they haven't forgotten.
-
On the other hand, if you want consistently POOR service from a section of an industry as opposed to just one company, I can always raise my bugbear of those who, by and large, DO NOT practice simple business etiquette nor understand the basics of business communications: IT Recruitment Agencies.
Apart from an absolute minority, most rank up there with car salesmen & politicians for false promises and general ignorance.
A lack of planning on your part does not constitute an emergency on mine.
-
Don't let poor service go undetected by the vendor, nor give poor service to your clients - internal or external. My mantra to my clients and employers that if I didn't do right, not telling me doesn't help anyone. I can't get better if I don't know what isn't working. You don't have to rip into someone, just let them know that you expect better and what you felt should've happened. Don't be lazy and just sluff it off with a "whatever". You'll get great satisfaction when they do get better knowing you helped the vendor YOU CHOSE get there.
From a systems architect's point of view, build in escalation automation (i.e. script that runs every 10 minutes - update issues set status = 'follow up' where datdiff... you get the point). Allow the technology to work hard for you, not vice versa (but avoid the dreaded "canned response" automation, make sure a HUMAN has to take action on a follow up where appropriate).
That said, good customer service is an attitude, not a skill. Skills only augment the attitdue. Some of the best customer service I've ever receive were from people that didn't know themselves what the issue was, but knew 1.) who did and 2.) cared about me enough to follow through to make sure the issue was resolved (Cisco Reference noted).
And lastly, if you are a support professional, you MUST care about your client. Their success is your success. If you fail them, in either support (where after a while they don't trust you'll help them, and hence stop coming to you) or in technology (where you just can't deliver what they came to you for, beit for their unreasonable expectations or your failure to find the answer or someone that can), they will not succeed, and hence neither will you. We are here as DBA's, support professionals, SysAdmins, and other titles, but are all bound to this. Our customers' needs keep us employed. It's your choice to rise to the challenge and support them.
But that's just my two cents. (Can I have my two cents now?)
-
Well said Narizz28!
-
I had a similar experience, with Microsoft. Thankfully, the rep had taken care of properly logging the issue we were discussing and we did not have to repeat everything. How difficult can it be to have a guideline that says call the person back if your call drops
, but I have to deal with it. This is similar to things that have happened to me in software support, but also when calling anyone for support, including corporate PC or server people. How often has someone said they would work on something, or started checking things, they know who you are, and then you don't hear from them again?Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply