The 10 Rules of Software Support
12
on March 8, 2010
I’ve commented before that support is the one side of the business I have trouble letting go of and letting others take full responsibility for. It’s just so important that we get it right as it’s essential to encouraging those taking our free trial to become paying customers and to keep existing customers happy (and therefore continue to recommend us).
Whilst we have a procedure document detailing how support requests should be dealt with, I thought it might also be useful to distill this into to 10 golden rules. I’m publishing them here so that customers and trialists know what they have the right to expect from the support team.
Perhaps if you’re starting a business where there’s an element of support then you could take and adapt these for your own uses too.
1) Be Responsive – Keep the Customer Informed
We’re well known for being very quick to answer support emails, whatever the time of day or day of the week. We need to keep it that way. If when you first look at a support request you can’t answer it right away -perhaps because you need to do some investigation or you need to speak to someone – let the customer know. It’s not ideal that you can’t give them a solution straight away, but at least they know they’re not being ignored.
2) Be Honest
Don’t try to fob off a customer. If they’ve found a bug or we’ve cocked up, acknowledge it and deal with it. Trying to pull the wool over their eyes wont work and breaks Rule #3.
3) Show Respect
Yes, we sometimes get asked what seem like a silly question. But if we’re not making the process intuitive enough or the solution easy enough to find, that’s our fault – not the customers. So don’t patronise customers.
Occasionally we might get someone be rude or hostile on a support ticket. Help them and they’ll calm down – and usually apologise.
4) Don’t Doubt What the Customer Tells You
I know that what the customer is saying has happened is technically impossible, but that doesn’t mean they don’t have a problem. No one is going to send us a support ticket and lie for the sake of it. Don’t assume it’s a PEBCAK issue. Work with the customer to get to the root of the issue.
5) Answer ALL Questions
It’s so frustrating when you email a support desk with 3 questions and their reply answers 2 of the questions and totally ignores the 3rd.
Yes, we’re busy. But not taking the time to deal with things properly in the first place is going to make us even busier. Check and double check you’ve answered all questions asked of you before you send the reply.
6) Be Sure about the Question and the Answer
Don’t guess. If you don’t understand what you’re being asked then ask for clarification. An answer to a question they didn’t ask helps no one.
Don’t guess the answer either. If you’re not 100% sure that the information you’re giving is accurate then check with someone or test your solution.
7) Be Clear in your Response
If you’re telling someone they need to activate the laser guided missile function to resolve their problem, tell them HOW to activate it. It’s better to not assume anything and give a comprehensive answer than to be vague.
8) Keep Your Promises
If you tell a user you’ll let them know when a feature is available or that you’ll get back to them tomorrow after checking with someone – make damn sure you do it.
9) Be Human
Your mother didn’t give you the name “Support”, so don’t sign off as “Support”. Use your real name, be friendly and own the problem. People prefer to deal with real people rather than someone that sounds like a computer.
10) ?
I’m leaving 10 open for you, the reader, to suggest. Based on your experience of our support desk and other support systems, what really frustrates you? Use the comment form below to submit Rule #10.
I’ll update this post in a week or so with one of the suggestions
12 Responses to The 10 Rules of Software Support
-
10.
Know when you should (and shouldn’t) give the answer.If you aren’t qualified to give the answer, tell the customer. This is much better than coming across as though you don’t know your job.
If the customer is asking you something that isn’t your responsibility, politely tell them, but remember rules 3 and 6; respect the customer and make sure you have understood exactly what they are asking you.
Be as helpful as can reasonably be expected. If you know who the customer does need to speak to, make the suggestion.
-
10. Give time and incentives to tech development staff to enable them to do a good job on support. Make it a rule that 20% of their working week is allocated to it (project plans never have more than 80% availability). Put it in their objectives. Ask them for examples of where they think they did an especially good job. Feed those examples back through the company learning system.
-
10. If you have to answer a question twice, you’re probably going to have to answer it thrice.
As Martin says above – learn as much as you can from each request for help – and try to prevent the same problem recurring.
I know of a support desk in a major (international) organisation where the 1st and 2nd line “analysts” are measured based on the number of support tickets they close each month – this actually contributes to a culture whereby it is counter-productive (in terms of personal targets and bonus evaluations) to work on reducing the number of calls logged with the support desk.
I was a bit shocked to learn about this!
-
Matt, I don’t think any target driven system works without careful observation from the management. Ultimately you are relying on the integrity of staff to outweigh the resultant reward/punishment from meeting (or failing to meet) targets. Sadly someone who cuts corners will do well at meeting targets, at the expense of someone who fills in the essential (but untargeted) gaps in between.
I work for a company which does place the emphasis on tickets solved, rather than logged. I think it works almost as well as a target-based system can do.
In this case, it is based on Zendesk, which means the technician/analyst/consultant must be prepared for the customer to see what has been logged. Ultimately this prevents over-logging of issues, as the customers will not stand for frivolous ticket emails for issues they did not report.If there are 200 problems in a day, they should all be logged. This can be tracked by management and the route cause addressed.
It is the duty of support (in my opinion) to find problems, fix them (or provide workarounds), then if possible, provide feedback (to the relevant colleagues) to prevent them happening again,
It is not down to support to direct the company policy and as such, support should not be given a hard time for continuing to find a large number of problems.
If the incentive is to not log issues, key problems will be missed.No one technician can be held accountable for the number of issues logged, unless they caused the initial faults. In a support environment, this is rare, so it should not be a negative performance indicator if someone finds lots of problems (as long as they are all dealt with properly and resolved).
A technician who is given a large number of problems and resolves them all in a week is clearly doing their job. -
10. Give time and incentives to tech development staff to enable them to do a good job on support. Make it a rule that 20% of their working week is allocated to it (project plans never have moee than 80% availability). Put it in their objectives. Ask them for examples of where they think they did an especially good job. Feed those examples back through the company learning system.;
-
10, remember that your customer is not a techie and does not know or care how your software works. It’s just a tool to them – so understand that they will not always know what detail to give you when explaining an issue. You have to question carefully.
-
Know what you are doing and know all the tricks and issues. Be a problem fixing ninja. This should be rule No.1.
The number of times I have talked to tech support people who didn’t have the basics worked out is astonishing.
If you are new, make darn sure you know what the top 100 issues and problems are and how to resolve them. Keep records of what the problem was and how you fixed it AND SHARE THEM WITH ALL YOUR COLLEAGUES. Help each other become great at support.
For example, I once had enormous problems installing a router that my telco company provided me with. The computer could not see the router. Reason was that there are so many wireless networks around here, they are conflicting. The router is supposed to automatically select a channel with no conflict. But it didn’t. Took me several hours of my life to work out. Tech support: total fail. Once I had solved the problem, I thought: “These guys have installed over 1m routers in people’s homes. There is NO way that this problem has not occurred before. So why the heck do they not know about it? Useless.”
Know what you are doing is No.1 rule for tech support. If you are nice that is great, but if can’t fix a customer’s problem, then you are still of little use. :)
-
@Simon Mayer – I absolutely, wholeheartedly agree with you – my beef with the particular case in point I was exemplifying is that the technicians are literally measured on problem closures (e.g they are told off if they don’t log/close X problems a month).
There is no system in place to follow up on the problems logged – I should perhaps have been clearer that this was my issue with the situation!
It’s the follow-through (as with so many things) which will tell apart adequate support from great support.
PS. I’m happy to say that KF support team follow through very well! ;)
-
Measuring tech performance on number of ticket closures alone is not only flawed but a very old method that has been superseded by adding a couple of simple things to the support systems:
1. a star rating, given by customers ‘on each reply’ by support. The ability to allow this on each reply rather than one per ticket is useful when you have more than one tech person replying to the issue.
2. A satisfaction survey sent once the ticket is closed.
Hope that helps.
-
I can’t help thinking that Duane is in contravention of rule 8 with this post.
What’s the official rule 10? I’d like to know what Duane thinks of the suggestions.
Leave a Reply
Authors
See what all the fuss is about
10) Learn from the customer.
Think about how you could improve the software in the future, so people have less need to call for support.