5 Product Support Best Practices That Actually Help Customers

Throughout my adult life, I’ve worked for a few major companies, providing various types of product support (services, hardware, and software). In that time, I’ve come to ground myself in a specific way of doing things that often leads to better interactions for both the customer and me.

When it comes to working a help desk or providing customer support, there are a lot of common suggestions you’ll hear. Be polite. Show empathy. Acknowledge their frustration. Always apologize for the trouble.

And of course, reply quickly.

What I’m going to discuss are aspects of customer support that are often overlooked, especially for help desks and technical support roles. Many support teams are too focused on closing out tickets quickly so they can hit certain metrics. While those can be important factors, focusing only on that can lead to unpleasant experiences for the customer.

Is this a complete list of best practices for product support? No, of course not. But with a couple of decades under my belt working with help desks and supporting products and services, I can say these are core elements for anyone doing product support or working at any kind of help desk.

Write like a human being

People hate talking to a machine, especially when it sounds like one. Rigid sentences with high-level wording and technical jargon, piped out like a certification test, can often trigger a confused, if not annoyed, reaction from most people.

You must remember that regular people are on the other end of your response. Your replies shouldn’t be complicated, even if the subject matter is.

When I would write support ticket replies, I would keep things conversational, much like the way I write my blog posts. I would deliberately avoid packing a sentence with big words (like deliberately) or technical jargon without an explanation of what it means.

Saying something like, “I ran a speed test on your site, and it looks like your images are pretty heavy” is easier to understand than “The speed test results indicate low compression on your images, causing a high reading for LCP (Largest Contentful Paint).“

Regular people have no idea what LCP means, even when you expand the acronym.

You can still get this information across to people; you just need to do it in a way that doesn’t require them to be a master technician.

I once supervised a computer salesman who had a habit of going on about computer specs to people whose eyes would glaze over when he spoke. When he noticed their confusion, he would just throw out more buzzwords and technical terms that flew over their heads higher than the Artemis II. RAM, Hard Drive, CPU…to regular people, these mean nothing. You have to explain these things in easier terms.

Hard drives, for instance. Those are essentially like the trunk of your car. The bigger the trunk, the more stuff you can carry in your car. The bigger your hard drive, the more stuff you can install or save to your computer.

Using analogies and simpler language can go a long way to making something palatable to people who aren’t power users or technicians.

After all, the people contacting you are your customers. They don’t work here. You do. Don’t expect them to know everything you know. If they did, they probably wouldn’t be asking for your help.

Canned replies can be effective, but tailor them often

Prewritten responses can be great when you need to send the same type of information frequently. For instance, if customers often ask for instructions on how to reset their account password, you’ll want a snippet of saved text you can copy/paste into your reply. This keeps you from having to type those same instructions over and over again.

Where things go wrong is when you’re sending a canned reply with irrelevant information.

Let’s consider this example:

You have a detailed canned response that explains your product. It includes information on how the product is used, its best features, links to documentation, and even your refund policy.

A customer comes in and asks you if your product does X. You send them that response. The customer ignores it and goes away.

Question: Why did they do that?

Answer: Because they asked you about a specific use case, and you gave them a book report that mostly has nothing to do with their question.

A canned response like the one I described is great if someone comes in saying, “Hey, I don’t know what your product is or if it will help me. Can you tell me about it?”

However, in this instance, where they only wanted to know about a specific function, this canned response becomes a wall of irrelevant text. And to the customer, it looks like you’re not paying attention to them, which can severely damage their view of your ability to help.

Your replies, even when canned, should be focused on relevant information. Out of the box, that reply is far from focused, but it can still be used.

You just need to edit it first.

Canned responses should be treated as a starter reply that you chisel into, stripping away parts you don’t need, and adding or editing as necessary. If someone comes in asking about your refund policy, instead of sending that whole canned reply, you’ll cut out the parts that are irrelevant before you send.

That said, it’s also a good idea to create shorter canned replies that focus on very specific, common questions, like your hours of operation or your refund policy. However, you also need canned replies that are only partial and expect more information.

For example, you should have an opener that looks something like

This makes it easy to start a conversation and tailor your response immediately.

When I’m doing product support, I create canned responses that sound as if I’m replying to a real person. As I mentioned in my previous point, I try not to overcomplicate things, and I use language everyone can understand.

I often treat my canned responses as a starter template or as a part of a larger response. Depending on the question, I might need to take three or four canned responses and piece them together. It just depends on the situation.

In the end, what I send to the customer is a reply that answers their questions without bogging them down with extra, unrelated information. You can always include more details as necessary, but don’t send someone a complete manual for their car engine if they’re just asking how to check the oil.

Use Better Documentation

Sometimes you’ll need to use outside documentation to assist the customer. For instance, let’s say the problem you’re trying to address is an SMTP error message from Microsoft. To find out what the error message means, you can consult Microsoft’s Email nondelivery reports and SMTP errors in Exchange Online.

But here’s the thing: do not give that to the user.

Why? Just look at it. It’s a gargantuan list of every possible SMTP error code you could run into with Microsoft.

And that means the vast majority of that guide is completely useless to the customer. They aren’t encountering all those errors at the same time, so why would you send that to them?

Instead, look up their error message and give them the relevant information in your response. Then, explain to them how it applies. This can go a long way toward helping correct their issue while simultaneously keeping the situation under control.

In some cases, it will be better to pass a documentation link to the user. However, it depends on the situation and the documentation. I try to find the best and easiest to understand sources I can. I don’t want to send the person off looking at a wall of complicated jargon or unrelated information.

If you can, link them directly to the relevant section of the guide. For instance, if they’re trying to install WP Rocket and Wordfence keeps blocking them, you can give them this link, which takes them to the related part of the guide:

https://docs.wp-rocket.me/article/126-using-wordfence-with-wp-rocket#firewall-blocks-installing-wp-rocket

However, if it’s not possible to link to a section, give the customer the full URL and tell them which section to look for (ex. “The part that says ‘Firewall blocks installing WP Rocket’ near the bottom of the page.”) This way, they know exactly where to look and can ignore the rest.

Stop blame shifting and take ownership of the problem

A big issue I’ve seen at several companies, not just from the support side but also as the customer, is blame shifting.

Blame shifting is the act of dismissing a support request as ‘out of scope’ or ‘someone else’s problem’ without providing the evidence to back it up. It happens when a provider prioritizes clearing a ticket over solving a problem, forcing the customer to go back and forth between vendors who refuse to take ownership.

I used to see this kind of thing a lot in the hosting industry. It usually happened like this:

Why did this happen? Well, as it turned out, the guys at the plugin support team didn’t actually look into the problem. That’s why they couldn’t explain why they thought it was a hosting issue.

If your customer is facing a problem that isn’t being caused by your product, don’t just brush them off on someone else. Explain to them what you checked and why you think the problem is coming from something else. Even if it’s just an educated guess, it’s better than dumping the customer without any explanation.

“Mr. Customer, I tried sending a test email through your contact form. I also tried sending one through the email test feature in your SMTP plugin. Both of those worked, and I can see the emails hitting your email log.

I think the reason Plugin XYZ isn’t sending emails or showing them in your log is due to a settings issue in Plugin XYZ. If it’s not that, another plugin on your site is probably causing a conflict with it and keeping Plugin XYZ emails from reaching your SMTP plugin. Basically, something is affecting that specific plugin.

If you reach out to their support team and let them know what I tested and found, they should be able to look into this further for you and help get those emails going.”

That tells the customer that you actually looked into the problem. It shows them what you tested, and gives them the information they need to let the other vendor know what was tested and found. It can help everyone involved to make sure this customer is taken care of.

This can easily be the difference between an angry customer who cancels and hammers you on TrustPilot and social media, and a happy customer who sings your praises and keeps doing business with you.

Taking the initiative

I’ve seen this kind of thing happen a lot across many industries, and sometimes it’s easier to avoid if you take the initiative to step in for the customer. I’ll give you another example.

Many years ago, I worked for an internet service provider. A customer called in asking when their service would be set up. I checked their account and found out the install had been canceled by us, and their charge refunded. When I told the customer, they were quite frustrated because this had happened multiple times before. They call about service, get signed up, call back later to find out when it will be installed, learn it was canceled, and are sent to the accounts department again to get signed up.

And they expected the same to happen again. It didn’t.

I told them I’d look into it and call them back. After we hung up, I called the accounts department to find out what was happening. It had something to do with the department that handles our field services, so I hung up with accounts and called the field services department. Long story short, after some back-and-forth among multiple people and departments and follow-up calls over the next couple of weeks, their service was on the way to being set up.

The customer was overjoyed because the situation was finally being resolved.

However, it should never have gotten that far. Things do happen, that’s true, but someone in the multiple rounds of sign-up – cancel – sign-up-again should have noticed this and done something about it. Everyone who touched the account could see this cycle of events play out, and based on it, all they ever did was transfer this customer to get them to sign up again. There was no accountability or ownership of this customer’s issue. It created an awful customer experience, and the only reason the customer kept trying was that we were the only ISP in their area.

I have experienced similar examples in other industries. If the customer is ready to give up entirely, reach out to the other department or vendor yourself. I’ve done that many times to help speed things up. The customer doesn’t have to continue bouncing around as a middleman, and as a bonus, you look like the hero who saves them from further aggravation.

Besides, sometimes it’s easier since you can communicate details with the vendor that the customer can’t.

Always look for a path forward

Sometimes, you can’t provide a direct solution. That happens. Whatever you’re supporting can’t do everything. In cases like that, you have two choices:

A) Tell the customer you can’t help and leave it at that

B) Try to point them in the right direction.

I learned this from my first job, back when I was still in high school. If a customer was looking for something we didn’t sell and the store owner knew where they could find it, he would tell them. As he told me, it builds a better rapport, and the customer will remember you for it.

I provide web hosting for SMBs, musicians, blogs, artists, authors, personal sites, and similar. If someone comes to me and wants to host a large enterprise-level application like Walmart.com or something, I have to refuse. That requires a much larger infrastructure.

But I don’t just leave them in a lurch.

I explain what my hosting is for so they understand why I can’t help. I also send them toward a potential good fit if I know of one (AWS, for instance). If you can give them multiple avenues, that’s even better.

One of the companies I worked for provided a service that did not fit a large portion of the potential customer base. They wanted to use us, but their needs would immediately violate our acceptable use policy. Rather than tell them no, we can’t provide service and leave it at that, I recommended alternatives. I even gave them a list. This isn’t some sort of heresy, as some might see it. The person literally can’t use us, so we lose nothing by pointing them toward a service that will help.

And you know what? The people I did that with appreciate it. I encouraged others in our organization to do the same. We frequently received positive feedback for doing that because we were still providing help.

In several cases, the same customers we had to turn away, came back with other projects that fit our AUP guidelines. If we had just told them “no, we can’t provide service,” that would be the end of it. We’d never see them again. But because they now know what our service is for and how our support operates, they came back and gave us business that fit our policies. That kind of thing can have a huge impact.

Hopefully, this information will help you or your team write better support replies. Your goal shouldn’t be just how fast you can complete a support request. You should be focused on providing the best product support through excellent customer service. Better help desk support means happier people on both sides of the interaction. It can also improve the reputation for your service or business, and give customers a powerful reason to stick around.