Thee Principle of Successful Support
October 25, 2008 by ashokshahdeo |
First, though, I want to go over some general principles that I think are essential to successfully handling challenging Support cases. With these principles out on the table, explaining how to deal with “futures” questions becomes much easier.
I think general principles are much more useful than specific examples. If you get a general principle, you can apply it in a variety of situations, including brand-new situations that nobody’s ever seen before. If you are just following a rulebook, then when you are faced with a new situation which isn’t covered in the rulebook which, BTW, happens every day in this line of work you’re stuck and don’t know what to do.
So the three key principles I want to cover are:-
*Only speak the absolute truth to customers
* Never promise what is outside of your control
* you are the voice of Company- and Company must speak with one voice
First Principle: Only speak the absolute truth to customers.
Whenever you make a statement of fact to a customer you want to be absolutely, positively, 100% certain that what you are saying is the truth.
This is simple to say, but it’s much harder to practice it than you might think. We are all of us in the habit of presenting as true things that we’re only 90% sure are correct, or that we haven’t bothered to verify, or that might have changed since the last we fact-checked them. This is only human. Unfortunately, it is also a tendency that will get you in trouble in Support.
I strongly recommend that you cultivate an attitude of precise accuracy. Here’s an example from the Robert Heinlein novel “Stranger in a Strange Land”. The main character asks one of his assistants to describe the color of a house in the distance. She responds, “It’s white on this side”. Without being able to see the far side of the house, she wouldn’t make any statement about it. (Ref: “Fair Witness”) This is a difficult habit to develop, but it’s one that will help you out a lot.
Here’s my rule of thumb: whenever I make a statement of fact to a customer, I ask myself: “Would I be willing to make a 100 Thousand RS bet that this statement is correct?” (If you’re richer than I am, you can raise that amount to 200 Thousand RS – or whatever amount would cause you significant pain if you lost the bet.) If my answer to that question isn’t a resounding “yes”, then I don’t present that statement as a fact to the customer.
So, what do I do when I don’t get the resounding “yes”? There are two basic strategies:
Verify your facts so that you are sure
1. Qualify your answer in some way
2. How do you do this?
To verify facts, you can take one of two strategies: you can experiment with the actual software, or you can consult with a trusted authority. IMHO, verifying using the actual software is best: even the most trusted authority can be wrong. And if you do check with an authority – such as Google, or the Company FAQ, or even me – when you are done with your checking you should ask yourself again – would I make that 100 Thousand RS bet?
While I will – and often do – make statements of fact to customers, I often find myself qualifying statements of fact. Instead of making a direct declarative statement, I’ll preface it with “I believe” or “I’m pretty sure that” or “I suggest that you try” or “My current thinking is” or any other wording that gives me an out if I happen to be wrong.
As a rule of thumb, I make a point of verifying anything that I can reasonably verify, given my time and resource constraints, and I will qualify the rest. (If I’m presenting a hypothesis or theory, I’ll explicitly qualify it as a theory that I’m pursuing!)
As a beneficial side effect, this habit will dramatically increase your credibility with customers. If you never ever say that something is true unless you’re positive that it is true, when you make a statement of fact your customer will sense your confidence, and be much more likely to believe you, even when you tell them something that they don’t like or don’t want to hear.
Second Principle: Never promise what is outside of your control.
In some ways, this principle is a corollary of the first one. In the same way that you don’t tell a customer something is currently true unless you’re sure that it’s true, you don’t tell a customer that something will be true unless you’re sure that you personally can and will make it true.
When using this principle, consider that the actions and outcomes of Development and Support Operations are all outside of your control. So, for example, you cannot promise that a bug will be fixed by a certain date. Even Development can’t promise that – the best that they can promise is that they will work on a fix – but the bug might be too elusive to find or too big to fix by the promised date. Similarly, you can’t promise that an existing bug fix will be present in a rollup that hasn’t been released yet – that fix might be pulled from the rollup at the last minute.
Even looking at your own actions, you can really only promise what you will do – not what the outcome will be. This is a key concept when it comes to dealing with customers. For example, I will promise that I will install a customer’s test case – but I will never promise that you will reproduce their problem. See the critical difference here? Installing (or attempting to install) the test case is within my control – but there are a thousand reasons (all outside of my control) why I might not be able to actually reproduce the problem.
I deal with the challenges of this principle in three ways:
I will promise my own effort, but not the outcome
1. I never make a promise that depends on any way on anyone else
2. I will qualify any commitment as needed to keep it from being an absolute promise
3. I think the best way to explain this principle is with some examples.
Here are some examples of commitments I will make:
I will look into your problem
* I will attempt to install your test case (Extra-credit question: why don’t I say that I will install their test case?)
* I will keep you informed of the progress of this issue
* I will file a bug
* I will investigate your question and get back to you
* Here are some examples of commitments that I won’t make:
You will have a bug fix in the next patch set
* The next patch set will ship on March 1
* I will have a workaround for you on Tuesday
* Your sales rep will call you back within 24 hours
* Here is how I would rephrase those commitments into ones that I am comfortable making:
You will have a bug fix in the next patch set becomes one of:
I will file a severity-1 bug for this issue.
* Development has said that they will work on this bug and try to develop a patch
* I have verified that the fix from Development resolves your test case
* A fix for this bug is currently scheduled for the next patch set
* The next patch set is currently scheduled to ship on March
*I will work with your test case and try to develop a workaround by Tuesday at the latest, or sooner if I come up with a workaround before.
I will contact your sales rep and ask her to get back to you as soon as possible.
Third Principle: You are the voice of The Company – which must speak with one voice
there are really two parts to this principle.
The first part is that you are the voice of Company. Always remember that customers will take just about everything you say as an official – or at least semi-official – statement from the company as a whole. In the same way that you would take a statement from the customer assistance department of your ISP or phone company as the official policy of that company, our customers will regard what you have to say with the same authority.
The second part is that you as a company must give customers a clear and consistent message. Have you ever dealt with a large company – such as the phone company or your ISP – and gotten different answers when you talked to different people? If you haven’t, I can assure you that it’s a very frustrating experience, and makes the company in question look Very Bad.
Even though there may be differences of opinion or even outright disagreements internally within the company, you in Support – as key factors in the customer experience – must still present a unified face to our customers.
There are a number of bad things that can happen if a company does not speak with one voice. Most notably, it damages the credibility of both company and you personally as a Support Engineer. The other thing that can happen is that it can encourage customers to go “answer shopping”, where they ask the same question of several areas of the company until they get the answer they want. They can then go to their sales rep and say “so-and-so said…”, and then the situation only gets worse from there.
Speaking with One Voice can get tricky in that you have to take into account messages being sent by the Sales and Marketing teams. These messages are usually pretty important to the success of the company, and you contradict them at your peril.
What to do? My advice is to always:
Know what the current sales and marketing messages are
* When communicating with customers, do your best not to contradict the current marketing messages
* If you feel that you absolutely must contradict a sales message, consult with your manager before doing so. (That way, your manager can work with the Sales team to align the marketing message with the Support message, so that Sales, Marketing and Support are all saying the same things.)
* Note too, that there are times when the principle of Speaking With One Voice will come into direct conflict with the principle of Only Speaking the Absolute Truth. These situations are always challenging.
There are a couple of key techniques that you can use if you sense that a customer is “answer shopping”, or is trying to get you to contradict a sales or marketing message.
Refer them to someone else (if it’s not a Support-appropriate question)
* Claim you don’t know (also if it’s not a Support-appropriate question)
* Answer a different question
* Note that you will most likely get into this situation in a phone conversation. Customers are much less likely to challenge you or repeatedly ask the same question via email. That’s good, because both of these techniques work best in a phone conversation, and are less effective via email.
1) Its always easy to refer sales-type questions to the customer’s sales rep. For example, Support is not expected to know pricing information or to provide our VARs with sales materials. Questions about the business side, or about the customer’s responsibilities under their sales contract, should also be referred to the sales rep. If the customer has an existing relationship with Product Management, then you can refer them to PM as appropriate, as well.
IMPORTANT NOTE: I NEVER give out the name of anyone not in the Support organization. It’s the customer’s job to know who their sales rep is; if a customer is strategic enough to have a relationship with PM then they’ll already have the contact information, and under NO circumstances will I ever mention anyone in Engineering by name. (A big part of our job is to be a buffer between customers and Development, and – for the sake of both sides – I never fail to come between the two.)
2) Questions about the size of the company, the future expansion plans of Support, the number of successful installations of the company, products, or the size of our channel, are nobody’s business but our own. I’ve found that a simple “gosh, I really don’t know the answer to that” is a much more diplomatic answer than “Why do you want to know?” or “I’m not supposed to tell you”. You may have to repeat it a couple of times, but it will usually stick.
3) For those of us (like myself) who are very literal-minded, answering a different question than the one asked can be difficult. However, it’s often the most effective strategy!. If a customer asks you about how many Drupal customers we have, and you respond by talking about the exciting features that Drupal has to offer, they usually get so distracted that they don’t quite realize that you haven’t really answered what they asked