Support is a really neglected part of a lot of development jobs. You want to just keep writing code and making releases. It’s easy to get into the code and forget that the users are the reason you get paid to write it! If you find you’re doing your best and solving problems, but don’t seem to get the credit or positive results to show it, this might help you. Also, the title is “How to not fail at support” – because this is not about solving the problem or techniques for doing the fix – this is about how to not lose the encounter even when you solve the problem.
All Code has Bugs
You’re going to have them. Nothing is perfect. Your plan for any software has to include support or you’re gonna have a bad day.
Why people get angry at you when you are trying to help them
People need help and when people need help they are vulnerable. They are trying to do something and it is important to their ability to succeed at their job. If they don’t need it to succeed at their job, they won’t bother you about it. If they do need help, they want it as soon as possible and they want to get back to doing their work.
H.A.R.E.M solves the problem
The best way method I’ve found to keep sane and make sure every user is happy with support is to follow the H.A.R.E.M method. There is no silver bullet for software development, but there is definitely a silver bullet for handling human beings who need support without them getting angry about it. I didn’t come up with this, but I evangelize it like crazy.
It sounds stupid simple, because it is. Doing it is harder than understanding it.
- Hear the request
- Acknowledge the request
- Restate the request
- Estimate how long until you will get back to them.
- Meet or beat your estimate.
That’s it! It handles the customer service part perfectly. Do this and all you have to do is go find that race condition that disappears when a debugger is running!
Hear the Request
You need to have someone actually monitoring incoming support requests. This is harder than it sounds. Not hearing the request is a terrible problem – because they’ve reported an issue and no one is actually working on it.
If you don’t have a clear, easy dedicated, and monitored pipe for users to tell you about their problems, you need to fix that immediately. When someone doesn’t know where to go for help or when they go for support and no one looks at the queue, you have a big problem. Your users will hate you, and you’ll deserve it. If you’ve ever called for help and it hasn’t arrived, you understand the feeling of betrayal and hopelessness that you are associating with your labor.
Poor software with excellent support is a better deal for users than good software with no support. We know, because they actually use poor software with excellent support more.
Think through the experience of asking for help. You are trying to get help. It’s bad enough so that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. If you don’t know where to go to reliably get help, you will feel despair and anger.
Acknowledge the request
If someone tries to get support but they feel like they are shouting into the darkness, that’s the same as if they aren’t getting support. One of the big reasons people call instead of entering a ticket is that people don’t know if the ticket is getting looked at. If someone is calling, they know that a person has heard them.
Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear nothing. You will feel anxiety until you know that someone has heard you. You’ll “check in on them.” You’ll call to follow-up. You’ll do anything to make sure that someone is actually going to work on your problem.
When you acknowledge the request – you just say “I heard you and I’m working on the problem.” That is such a soothing thing to hear. Someone knows the house is on fire and help is coming!
This is super important!
- Users can chill out and go work on other things until you solve the problem
- If people know that submitting an email or ticket online gets acknowledged, then they can do that without tying up someone on the phone.
A script
“Hi Allie, I saw your ticket and we’re re-imprinting Asimov’s three rules on the floor robot’s positronic brain.”
“Hi Bob, I saw your message. I’ve unlocked your account for you and you can reset your password at the help portal. Happy to help, let me know if you’ve got any more issues with it.”
“Hi Carla, I saw your request. You’ve hit the hard drive limits under our policy. Â I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”
Restate the request
Support requests are difficult. Don’t work on the wrong one. I’ve spent hours troubleshooting the wrong problem because I didn’t understand what they were trying to tell me. This waste is a waste of your time and the poor person who is waiting for you to fix their problem. They don’t care about the time you just spent and how hard you worked. No one benefits.
Always. Restate. The. Requests.
It sounds stupid. It sounds awkward. Do it anyway. It’s a “check for understanding“. In conversation you can just say “I want to make sure I’ve got this right, so let me restate what you’ve told me.” That language usually helps them understand why you insist on saying back to them what they said to you.
Think yourself through the experience of asking for help. You are trying to get help. It’s bad enough that you can’t fix it yourself – so you are helpless. You want to get help – to ask for support. You ask for the support and hear that someone will help. Relief.. Then they tell you the house isn’t on fire – but you are seeing the flames! Or they say they’ve fixed the water leak, but you are seeing a waterfall in your bedroom. Are they insane or incompetent or lazy or lying? You will feel angry, frustrated or betrayed.
A script
“Hi Allie, I saw your request – I just to make sure I understand. You’re saying the floor robots are ignoring Asimov’s 3rd Law – that they are killing themselves out of boredom?”
“OH MY. Sorry, you’re saying that they are ignoring Asimov’s 1st Law and killing everyone on the floor out of boredom! I’ll send Will Smith over immediately. Please shelter somewhere safe.”
“Hi Carla, I saw your request to increase your hard drive size – you’re telling me that you have to use a program that only works with large files on your primary drive. You’ve hit the hard drive limits under our policy. Â I’m attaching a quick guide to how to slim your hard drive footprint that other folks have found helpful. If that doesn’t work we can send a note to your manager and the CTO to see if they will approve an exception.”
Estimate how long until you will get back to them.
A key metric for user satisfaction is “First Call Resolution”. FCR makes people happy. For phone calls that means getting solved during a conversation. For emails and tickets, that means someone resolves the issue within 1 hour of the request coming in and while in the first response to the request. Yay – those are automatic wins!
But there are plenty of issues that are bigger than a single call or take more time. This is where real rancor and unhappiness can develop even if you are solving problems and doing everything else right.
Tell people how long until you will get back to them. This isn’t a guarantee that you’ll have the problem fixed – just a message of how long they should expect until you can update them. This is very important because it gives them a chance to make decisions and be empowered. Just telling them this lets them be less helpless.
If you think this reporting issue will take 1 hour, and someone has to be on the phone with a client in the next 20 minutes, they can decide to calculate the numbers themselves or to postpone the call. Letting someone know enough to seek other solutions is good for them.
An estimate is basically a promise to the user: You can bug me if I don’t come back to you before this time. If that isn’t soon enough you can seek other solutions. If it is ok, just relax and work on something else until I call you – I’ve got this.
A script
“Hi Zelda, I’m not sure why the delivery drones are returning to the warehouse without releasing the payload. Just to be clear – the address is correct, the payment is fulfilled and they order hasn’t been cancelled, but the drone just goes to the address, circles, and comes back with the package? This is tricky. I know you are under a time crunch. I’ll start looking at this and I’ll get back to you by 2pm with either a solution or I’ll let you know how much longer it will take me.”
Meet or beat your estimate.
When you make an estimate, you’ve made a promise. Keep your promises.
Don’t break your promises. Do what you say. Be clear. Meet or beat your estimate. That’s why your estimate includes a statement saying you might come back with another estimate. Do that if you think it might take longer than your original estimate. Better to keep the user in the loop and up to date than to have them know that they can’t trust you.
A script
“Hi Zelda – Just calling to check in with you. This is trickier than we thought. The GPS system connected to the drones doesn’t show the address! That’s something we are working with a vendor to correct, but it won’t be fixed by 2pm. I’ve asked them to keep us up to date and I’ll chase them. I’ll get back to you by 4pm with either good news or I’ll get you a better estimate.”
Conclusion
The reason this works is simple: it’s humane, it respects the needs of the person asking for help and it treats them with good manners. It won’t solve problems for you – you’ve still got to do that, but it will get rid of feedback that your people feel abandoned by your support team or that they don’t want to bother reporting issues.