Shannon's Ten Rules of Customer Support

by Shannon Appelcline

April 9, 2003 – For pretty much the entirety of my professional career I have spent at least some time interacting directly with customers. At NASA I supported our scientists with their computer problems; at Sun I was actually working in a real support job, diagnosing and resolving networking problems; at Chaosium I answered customer questions via email and did online chats on a monthly basis; and here at Skotos I've at various times advised our customer support staff and done it myself. That's ten years of support experience, under a variety of hats.

That all goes to act as my credentials, because what I've got to say today basically amounts to Shannon Appelcline's dogma on how to do customer support right. Because, quite frankly, I feel like most support organizations do it wrong. If you're in support, if you manage support, or even if you think that someone else in support at your company might be interested, print this article off and get it to your support team. In my most humble opinion it'll make both you and your customers happier.

Here's my rules for customer support, in ten small, bite-sized chunks.

1. Set Expectations

To a large degree, I believe this is the heart of customer support, and thus a topic that I've discussed before. What I mean by this is that you need to make sure that customers always know what they can expect from your support organization.

To start off with, they should have a good expectation of how long it will take to get a response from you. If you don't respond to email on weekends, tell them that. Ditto if your average response time is two days, let them know. They might not be happy with the answer, but they'll probably be more happy than if your response time is totally unknown — because in that case their expectations could as easily be that you respond within minutes instead of days.

Beyond the question of response time you should clearly define all of your policies, so that there are never any surprises. Plan to kick someone off the forums if they swear? Let them know. Do you sometimes juggle wait lists for your strategy games? Announce it.

And that brings us to the second topic...

2. Announce, Announce, Announce

This one's really simple: if you know something's going to happen, tell your customers about it in advance. And, I don't mean the day before or the hour before, but preferably weeks before or even months. In some ways, this is again about setting expectations, because you're letting your players know what's up and coming. However, it's also common courtesy.

For example, we gave players a couple of months' notice when we decided we had to raise our prices last year, not just to get people used to idea, but also so that we could have an open forum for discussion. We offered the courtesy of advance notice of our policy change, and thus were able to hear real concerns that players had.

3. Clearly State the Consequences of Actions

This is one final variant of "setting expectations", but it's an important one to consider because it relates to discipline, which is a particularly sticky issue because it usually involves making people unhappy.

In short, if you are going to discipline someone, try and ensure that the consequences of forbidden actions are clearly stated before hand. A terms of service document is a good start to this, but utterly not sufficient because many people will skim that agreement.

Whenever customers engage in forbidden actions, it's optimal to give at least one warning, so that you can clearly say, "If you do A again, then result B will happen to you." This way, though there may still be animosity, there isn't a surprise, because you've correctly set expectations in this situation.

4. Never Take Back That Which You Gave (If Possible)

Sometimes you're going to mess up and give your customers something that you wish you hadn't. Perhaps this is a result of changing business model, or perhaps it's due to a bug in your code or some other mistake that you made. If it's at all, all possible, do not take that thing away. Doing so will probably anger your customers sufficient to offset any benefit you might see.

Instead, make the change for your new customers only. This way, unless your business is perpetually evergreen, with no customer turnover, you'll see your new benefit slowly phase in as new customers arrive and old customers leave.

And, I should clearly note, this isn't always possible. Many times you'll be able to abide by this stricture; for example, here at Skotos we decided to lower the number of character slots for most games down from three to two, and that was easy to "grandfather" to older players. If, on the other hand, we'd made a mistake and doubled the power of everyone's character in every game, we would probably have had to reverse that and take the flak.

5. The Customer is Sometimes Right

You've heard the saying that "The Customer is Always Right"? It's wrong. The true answer is that your customer will be right sometimes and will be wrong sometimes.

Your customer may be "wrong" because he doesn't understand facts that you do. For example, players often appear in Castle Marrach looking to kill things; they're wrong trying to make Marrach that game, because it isn't that game.

Likewise, your company's business model might not be understood. Your customer isn't right in asking for a $4.95 subscription model, if your core expenses per player are $6.00.

A close corollary to this is the fact that keeping every customer is not the goal. Yes, you want to keep all the customers you can, or else you won't stay in business, but some customers will make demands that are unreasonable for yourself, your business model, and your product; it's better to let those customers go than to warp your business, potentially making it difficult for you to move forward.

When thinking of this topic I'm always reminded of how one of our former employees told me with pride one day that he'd spent half the previous night talking down a player who'd become very angry at one of my articles and had threatened to leave the community as a result. It wasn't the first time this sort of elongated "please stay" discussion had happened. Looking back at the hundreds, probably thousands, of dollars of support time that we expended on this one customer, the reasoning behind this particular rule becomes fairly clear.

6. Do Not Overdeliver Value

Closely related is the fact that you don't want to overdeliver value to your customers, lest you place yourself in a position where your business is purely unprofitable.

At heart this means you should decide upon a central set of services which you're willing to provide to all your customers, and not go beyond that no matter how much some of your customers ask... because once you start giving a service to some of your customers, you have to give it to all of your customers unless you want to enter a land of favoritism where the squeaky wheel really does get the grease.

This also means that you need to tell players when you can no longer help them. When I was at Sun, for example, one of our rules was that we weren't supposed to help a customer unless they were technically competent regarding the topic that they were asking for help on. Telling a customer you couldn't help them for this reason was always a really hard thing to do, but if you don't you were likely to spend more time helping this single customer than they actually paid for in their entire yearly service contract... and you were also likely to make life much harder for the next support person the customer talked to, if they did follow the rules.

7. Listen to Your Customers

There's a flip side to this all: you don't know it all.

Even if your customers don't know the underpinnings of your product, they may very well understand its practical application better than you do, because they're the ones out there on the "front line" working with your product every day.

For example, I'm very familiar with all the code for Galactic Emperor: Hegemony, and I think a lot about the UI and the gameplay. But, I don't necessarily understand what the players think makes the game great. Thus I always try and chat with the players and get their opinions on new features and revisions. In some cases I've written up a whole new game system (e.g., an expert-rule-set-driven neutral planet AI), then never introduced it into regular play due to feedback, while in other cases I've taken a one-time system (e.g., space stations) and begun to use them in every game for the same reason.

There's a corollary to this one to, which might be made obvious from my example: you should use customer support feedback to improve your entire organization. For example, one common login problem I see at Skotos is a player getting stuck in a "loop" where they keep being asked to reenter their authentication information; this is commonly the result of cookies being disabled on the player's browser. So I recently had engineering put a check into the login process to verify that cookies are enabled, and hopefully this will help ensure that some of our players never have to mail customer support in the first place. I've similarly had engineers change error messages and even add systems because on customer feedback.

At Skotos we've always called our customer support department "customer experience", and that's mainly because of this rule. We believe that it's not just about answering questions, but also really understanding what the customer experience is, and improving it when possible.

8. Admit Your Mistakes

And finally on the topic of right and wrong, remember that you're now always right either — and when you're wrong, you should be upfront and admit it. It's much better for your customers to understand that you make mistakes too than for them to believe that bad decisions are made maliciously.

For example, a number of weeks ago the character slots in M59 got set down from 2 to 1 universally (violating rule #4, above). When I realized what I had happened, I first corrected the mistake, and then clearly told the userbase that it was a mistake, one that we had corrected at our first opportunity. The feedback was kind and understanding.

9. Prepare Yourself for Common Questions

By this I mean: write up canned responses for those questions that you expect to see the most frequently.

Now, I know some people are probably cringing at this, and that's because a lot of customer support organizations do use canned responses, but do so very badly. So, be careful. You should only use your canned responses when they're entirely appropriate — and you have to make sure your support staff is competent enough to know whether that's the case or not. You have to make sure the response gets our very quickly, and if it's not appropriate you have to be ready to follow up with a more interactive response at once. And, because canned responses have a bit of a bad rap, it's not that bad of idea to clearly state in your reply what info will be needed for that more interactive response, so that customers have the expectation that on a second round of email they'll talk to a real person. If you do all that, your reply will have real value where most canned responses don't.

So, why do it at all? Frankly, you can offer a better response if you prepare ahead of time. If you're trying to dash off an answer to an individual question, it'll probably only get a couple of minutes of your time, but if you're preparing a response that you'll use again and again you can easily spend an hour on the answer, and every single customer will benefit from the additional thought that went it into.

I know that back when our staff was answering the "why doesn't the Castle Marrach client load" questions by hand, the answers were inconsistent, and often didn't cover a lot of the special cases that people might run into. Now, we have a prepared answer which highlights the top five problems and also clearly lists what OS and browser info we need if more discussion is required.

10. Good Will is Its Own Profit

Finally, a matter of philosophy. If you're offering customer support, you're probably some type of commercial organization. However, you should be very aware that dollars and cents aren't always the bottom line. If your helping a customer out costs the company a sale, you should think about that fact, but you should also be aware that losing that sale might be a good thing, if it generates good will. (But, also see my warning above about overdelivering value; it's a fine line.)

For example, every once in a while one of our customers has a problem with a credit card. It's stolen, or is over limit, or whatever. As often as not I gt ahead and give these players a new trial month, so that they can keep playing our games while their life gets sorted out. Technically this might costs Skotos $10 or $50 or $100 in a month, but really in making those customers happy I think we say a lot about what type of company we are, and thus give our players good memories of their customer support experience.

Which, I think, is a pretty rare experience the way most support organizations are run nowadays.

Recent Discussions on Trials, Triumphs & Trivialities: