This should be a no-brainer, but you must be polite to customers at all times. Yes, sometimes they might be a bit too demanding or they may even be rude or sarcastic, but you’ve got to keep your cool and rise above that.
It’s your job to help them and make them feel positive about your product. So don’t antagonise them.
Using unfamiliar terms and jargon is only going to make matters worse. It will cause more delays, more frustration, and more support work for you.
Replying to customer support queries is a lot like writing a help page. You need to present information in terms that the customer understands. So pay attention to the language they are using and try to figure out their level of technical expertise. Then respond using simple, clear language.
It’s important to let the customer know you understand not only their problem, but how they feel about it. Remember, the people you are dealing with may be under a lot of pressure to complete their work. If they cannot do that because of a perceived problem with your product, they’re going to be frustrated.
Letting them know that you understand their perspective and that you will do your best to help is a good way to put them at ease. It’s also a good idea to try and give them a timescale for when you will be able to deal with the issue (if you can’t help immediately, for example, if you need to refer to a product developer).
Put yourself in their shoes and imagine what you would need.
This was my biggest mistake when I first started providing customer support. Now and again, a customer would report a problem, I’d agree that it didn’t seem right, and mention the “b” word. But sometimes it wasn’t a bug at all, it was intended design and, when explained in context, made perfect sense.
So if something looks wrong, and you don’t know the answer immediately, let them know you will investigate and get back to them. Without mentioning potential bugs or faults. That way, you avoid creating a negative impression about the product.
This was my biggest mistake when I first started providing customer support. Now and again, a customer would report a problem, I’d agree that it didn’t seem right, and mention the “b” word … yes, “bug”. But sometimes it wasn’t a bug at all, it was intended design and, when explained in context, made perfect sense.
So if something looks wrong, let them know you will investigate and get back to them. But don’t mention potential bugs or faults just yet. That way, you avoid creating a negative impression about the product.
At some point, you’re going to get a question where the answer is no. Now, there’s nothing wrong with saying no to a customer, but the trick is to say it in the right way. And, where possible, try suggesting an alternative.
For example, if a customer asks “Can I make local backups?” and the answer is no, you can answer “Sorry, you cannot make local backups. But there’s no need to, as we back up your data automatically every ten minutes. You can access any of your backups from the past 90 days.”
It’s just a case of putting a positive spin on everything (as much as you can). The aim is to say no, without disappointing the customer.
If you have an online help system, knowledgebase, or support videos, encourage customers to use those. Don’t go into detail in your answers if all the information they need is already available elsewhere, just tell them where to look.
Customers naturally go to where they can find the best answers with the least amount of effort. If your support content hasn’t been updated or isn’t detailed enough, it won’t meet your customer’s needs and so they will turn to support instead. Then, when they next have a problem, they’ll probably go to straight to support and that become the “normal” way of getting answers. You don’t want that.
Providing help content to deal with common problems is cheaper than providing customer support. So try to make your content as thorough and useful as possible and direct customers to that where possible.
The more you know about your product, the easier it will be to help customers. So spend some time using the product and, if possible, look at other agents’ responses to customer questions. You can learn a lot from reading support tickets!
It’s also important to learn about the areas of expertise in your organisation. At some point, you will get questions that are very technical and you’ll need to refer to the experts. Knowing the specialisms of your developers will make it much easier and quicker to direct questions to the right people.
If you’re using customer support software, like Zendesk, you can search for previous answers, which is great. But it’s not so easy if the title of a ticket was a little vague. To help avoid this problem, it is a good idea to add labels to the support tickets, so that the search has more to work with than just the title.
Add the keywords of the ticket as labels. For example, if you had a ticket about publishing to Zendesk, you might have a label for “Zendesk” and a label for “Publishing”.
This ties in to the last point about making answers easier to find in a customer support system. Always encourage your customers to raise a new ticket for each problem they face. This makes it so much easier when you are looking for answers to questions that have been raised before. If a ticket has a descriptive title and only covers one problem, you can understand what a ticket is about, without having to read it in detail. That’s not the case if you have a ticket that covers a range of issues.
I hope this post has given some useful advice on working in customer support. One last thing I’d like to add is that working in customer support is great for technical writers. It gives us direct contact with customers so that we can see what type of language they use and what problems they face. It’s a really effective way of doing customer research and it also helps to point out any weak areas in the documentation, such as areas that need more detail or are not as clear as they should be.
So if you’re a tech writer who has been asked to help with support, but have resisted, I say go for it. It really can help you with the documentation effort.
Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.