What’s the official rule 10? I’d like to know what Duane thinks of the suggestions.

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.

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! 😉

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. 🙂

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.

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!

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.

Think about how you could improve the software in the future, so people have less need to call for support.