> ## Content Index
> Fetch the complete content index at: https://www.screenbetween.us/llms.txt
> Use this file to discover other available public pages before exploring further.

# Good customer support isn't always about being nice, it's more than that.
- URL: https://www.screenbetween.us/good-customer-support-isnt-always-about-being-nice-its-more-than-that/
- Published: 2026-10-03T22:17:43.000Z
- Updated: 2026-10-04T02:57:58.000Z
- Description: Being nice to customers is great, but it’s also the bare minimum. Here’s what more than a decade in support has taught me about what actually makes customer support good.
- Author: Sarah
- Tags: customer support

As someone who has worked in customer support for over a decade, I've answered thousands of questions, dealt with my fair share of incredibly pissed off people, and made plenty of mistakes, but it has given me a lot of insight as to what actually makes a support interaction *good.* 

Honestly, I don't think it's as complicated as companies sometimes make it seem. 

Good support isn't just about having the perfect saved reply, responding in under five minutes, stuffing an apology into everything or making the customer leave thinking you're the nicest person they've ever talked to. It's more than that. It's about understanding what led them to write in in the first place, respecting their time, and giving them an answer they can actually use... and teaching them something along the way. 

Basically, good customer support isn't just about being nice. Being nice is just the bare minimum.

### Being nice is not the job.

There's definitely a version of support we've all been conditioned to expect as the "norm" – it's almost always *friendly*, and in numerous cases, *apologetic.* There might be a bit of personality thrown in the responses we receive, such as an emoji, or a few exclamation points, OR, it might be complete AI bullshit. 

Regardless, as a consumer we all have some form of outcome or reply expectation when it comes to writing to the support email address of a company, or jumping on a phone call (*which I'd argue is a worse channel of support than email, but I'll save that for another post*). 

That said, often times the replies we get are genuinely nice, but still end up being completely useless.

Don't get me wrong, you should absolutely be nice to your customers. You should also be respectful, patient, and empathetic. I think this is already implied, and definitely what I expect when I have to be the "customer" in my daily life. I'd qualify this as the default – BUT, being nice isn't the job. **Helping the person is.** 

Just because you might have a way with words doesn't mean that you actually answered the question. Neither does apologizing three times before asking someone to repeat the information they already supplied you in their first response. You can legit write the WARMEST, friendliest response imaginable, but if the customer closes it thinking, "Ok, but what do I do now?", clearly you've not provided good support. 

Providing good support requires skill. You need to be able to figure out what the customer is actually asking, even when they might not know the right terminology to explain it (*believe me, I live this daily*). It means paying close attention to what they've already tried, and genuinely investigating before sending them off to do something else–giving them an answer they can actually use and implement. 

Sometimes the answer might be reassuring (e.g. yes – this is a known issue and we're working on it), and sometimes it might be short and direct, and the answer might just be a flat out "no."

The goal is for the customer to walk away from the interaction thinking "OK, I know what to do now/next" rather than send them down a rabbit hole because you're trying to cut down the queue and get them out of the way.

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/CEA7A4A7-1C46-4BB0-A24C-34D583263FAC.png)

### Customers usually don't want to be talking to you

I don't think people wake up in the morning thinking, "YES, I can't wait to write into a company's customer support today!" Support conversations happen because something has already gone wrong. The act of sending the message is something "extra" the customer has to do, because something fundamentally was broken, or your company's documentation wasn't easy enough for them to follow. 

And by the time the customer's message reaches you, they've likely already tried several different things to solve the issue on their own unsuccessfully. It's important to keep that top of mind. 

Maybe the person who reached out already spent 20 minutes trying to find the setting they're looking for – maybe they spent time googling the error message, searching through your company's documentation, or even asking AI for help. This is a LOT of work on their part, for what might be a simple solution. Maybe they are up against a deadline, or their company's revenue relies heavily on something that just isn't working the way it should. 

You just never know what level of frustration the customer may have been in, before they decided to contact support. Again, it's important to keep that top of mind when a customer might come off as short, aggressive, or less polite then you might prefer – especially when they write to you in all CAPS letters. 

Now this doesn't mean a Support team needs to tolerate abuse, there's certainly a line that shouldn't be crossed, but acknowledging and managing their frustration is part of the job. 

One of the biggest mistakes a person can make in support-land is responding to a customer's tone, instead of responding to the problem that created it. The fastest way to change the tone/direction of a message isn't just sending an apology or being overly empathetic, but instead, communicating that you've understood why they wrote in in the first place. 

I think it's really important to dial in on what they wrote in about, and figure out what they're trying to accomplish. Don't make them jump through a bunch of hoops. Also, whenever you can, remove the work from their side (*within reason of course – some things can spiral out of control... #iykyk*). 

> TL;DR: Don't make contacting support become yet another problem that they have to solve. 

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/D90D12F1-AC4E-4A0F-AAC9-5958A12A1068.png)

### Read what they already told you

If a customer interrupted their daily life to tell you something in their first message you to you, you better read it, fully. 

I get that sounds ~~super~~ painfully obvious, but if you've ever contacted support yourself you've probably experienced some form of sending: "I've already tried XYZ", to hopefully skip unnecessary back-and-forth. Then, when you head to your inbox excited for a reply from the company you contacted, you're met with "Thanks for reaching out! Have you tried XYZ?" – and "XYZ" is exactly what you already said you tried. **It's annoying.** 

Nothing will make a customer wonder whether they're talking to an actual human faster. TRUST. This goes beyond troubleshooting steps, too. 

Most customers will provide you with all kinds of useful information if you actually pay attention to what they're trying to accomplish, what they think should happen, and what happened instead... as well as what they've already tried, when the problem started, and sometimes, the exact thing you need to identify the problem. 

Don't make them give you that information twice – again, **it's annoying.**

The same goes for conversation history. 

If the customer's already talked to someone else on your team, read *that* conversation before you respond. If they've already tried the same troubleshooting steps for the last three days in a row, they shouldn't have to start from the beginning each time the ticket changes hands. Knowing context matters.

It's also worth noting that the customer won't always use the right terminology you're familiar with. That's usually fine, but knowing your product well enough to translate *"that little dot thing at the top right isn't working"* into whatever your company would refer to this as is part of your job.

In general, the customer shouldn't need to understand your product as well as you do, in order to get help using it (*you should know that shit inside and out*).

Additionally, before you reply, you should always ask yourself: *Am I asking this person for something they've already given me?*

If the answer to that is yes, you need to go back and read the ticket again. 

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/AD410FB2-25C7-436A-89D4-1FBD724555A8.png)

### Empathy isn't a sentence

The most overused sentence in customer support has got to be some version of:

*"I completely understand how frustrating this must be."*

Do you, though? Really? I swear this sentence enrages me as a customer when I have to write into support for any company.

Especially if the next thing you do is ignore half of what I've told you, send me a canned response that doesn't answer my question, then give me five other things to try. I can't see how this communicates your understanding of my frustration.

Empathy in support isn't something you need to prove by including the right sentences in your response to the customer. It's more so what you show it through what you do next.

If somebody's already spent an hour troubleshooting a specific issue, don't casually send them a 5-step list of "to-do's" without acknowledging what they've already done. If they've contacted you four separate times about the same problem, don't treat their issue like it's the first time you've heard about it. Also, if something is clearly your company's or platform's fault, **don't be scared to own it.**

Sometimes saying "Yeah, this issue is completely on us" is more meaningful than a message about how much you understand their frustration, because that obviously won't help change the direction of the conversation.

Sometimes you don't even need an empathy statement at all. If someone tells you something isn't working, and you respond with a clear reason about what's happening, fix what you're able to, and set expectations around what you're doing next (*or what they can do if a workaround exists*), you're demonstrating that you understand why they contacted you in the first place. THAT is empathy.

It's respecting someone's time and paying attention to the details. It's also taking ownership when it's appropriate. It's not making someone jump through a million troubleshooting steps just because that's the internal process, or a quick way to move on to the next ticket.

More importantly, whenever possible... just solve the damn problem.

Empathy isn't something you say to a customer, but more so something they should be able to actually see in the way you helped them. 

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/C473EB8F-0C95-4A2E-BAFC-E040EB076234.png)

### A complete answer always beats a fast answer

Every support team loves their metrics. First response times, average response times, tickets closed, replies sent, etc. There are a million different ways to measure how quickly a team gets through the queue and their effectiveness.

While the speed at which you reply does matter — nobody wants to send a support request and wait five days before a rep actually responds. Somewhere along the way, I think it's easy to start treating a 'fast' response the same as a good response, and **it's not.**

If you were to respond to me in ten minutes, ask a question you could've answered yourself with a few more minutes of investigation, and then I have to wait another hour or so for your next reply (*or a day, if the queue is busy*) — was that actually faster? No.

Now we're turning what could have been one complete response into four messages back and forth, and I'm *still* waiting for an answer. It's not a great experience.

I'd rather spend a bit more time investigating the problem, looking through our documentation, similar issues, TESTING MYSELF, and gathering whatever other information I can before responding. If I can come back with a more complete answer, or at least a more meaningful 'next step', that holds more value in my opinion than being able to shove off a reply in under 5 minutes.

This matters even more when the queue is busy, or you're short staffed. The better the answer, and the more likely it is to solve their problem, the less likely they'll be to write back again and build up the queue.

Don't get me wrong, I don't think this means that every support request needs a full novel of an answer. I think a complete answer could honestly be a few sentences long, but it needs to anticipate obvious next questions so the customer can move forward without the urge to hit "reply" and ask more.

Speed is 100% useful, but resolution is better. As a whole, you should be optimizing for resolution, not replies.

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/433C9F1B-983B-42B9-8A4B-AC8F020431F9.png)

### Sometimes good support means saying "no"

I'm going to let you in on a little secret 🤫 ... **you can tell a customer no.**

Seriously. This is definitely allowed.

Somewhere along the way in this field, customer support became associated with this idea that the customer should always leave happy, and I don't think that's realistic. YES, we want to please the customer, but sometimes a feature doesn't exist, or what they are asking for just isn't technically possible. Sometimes, the answer is just going to be **no.**

I think where people get tripped up is when they're afraid to say no, and they spend too much time dancing around an answer instead.

Being direct isn't the same thing as being rude. I think giving someone a clear answer is more respectful than making them try and figure out what you're *actually* trying to say. You can say no and still be helpful.

For example, *"No, we don't currently support that"* — then explain the **why.** If there's a workaround, you can give that to the customer, too. If there's another feature that accomplishes what they are after, you can point them towards it. If you genuinely don't have another option for them, it's okay to say that — and maybe action a feature request on their behalf if it's worthwhile to do so.

What you shouldn't do is invent false hope when there isn't any.

For example, don't tell someone something is on the "roadmap" unless you actually know that it is. Don't imply something is coming soon because you don't want to disappoint them. A customer may not like your answer, but that's different from giving them a bad support experience.

In general, the best support you can provide is a clear answer, an explanation when one actually exists, and whatever realistic options they have.

Clarity should NEVER be seen as rude. Sometimes it's much better than giving false hope.

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/4AC41766-2B93-439B-882A-672D53789D02.png)

### Know when you don't know

I think it would be absolutely insane to think that a customer support professional would have the answers to *everything.*

I don't care how long you've worked in support, how well you know the product, or how many thousands of tickets you've answered — eventually, somebody will write in and ask you a question you don't know the answer to, and your immediate reaction will be, *"I have absolutely no fucking idea, guy."*

That's OKAY.

What's not okay is pretending you know the answer when you really don't.

There's some sort of weird pressure in customer support to always have an answer. You should be the expert, right? The customer came to you for help, so admitting you have no fucking clue can feel like you're failing at your job, but you're not. I promise you. I've been working in this industry for over a decade, and I can tell you from experience I don't know everything — but I'll sure as shit try and find the answer for you, or ask the right people to get one.

I'd rather tell a customer, "I'm not really sure what's going on here, so let me dig into this a little more," rather than give them a confident answer I pulled out of my ass.

> Knowing when you don't know something is a skill.

It means knowing when you need to test something yourself, review documentation, or ask somebody else on your team — or even escalate to engineering if you've reached the limit of what you're able to do yourself.

Also, I think there's an important difference between *escalating* and *dumping a ticket on someone else*.

You should still do the work you can first and gather as much context as possible. You should be testing what you can to rule things out, so that when the next person touches the ticket, they aren't starting from ground zero.

The goal in support isn't to know **every. single. answer.**

It's knowing how to recognize when you **don't know** the answer, and then knowing how to find it.

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/74FE7063-3D20-4F50-84C5-AE5AA079AB67.png)

### Talk like a real person

In case nobody told you, you know you're allowed to sound like a real person when you work in customer support, right?

You don't need to transform into a corporate robot the second you start your reply.

*"We sincerely apologize for any inconvenience this may have caused. We understand your frustration and appreciate your patience while our team works diligently to resolve this matter"* ... ew.

Nobody in real life talks like that.

Imagine saying that sentence out loud to another person in front of you. You would sound like an asshat.

There's obviously a level of professionalism that comes with talking to customers, working in any industry, but it doesn't have to mean 'be a robot'. You can use contractions, you can say "hey there", "yeah", and occasionally make a joke if the tone feels right. You can even use emoji if that's part of your company culture and the conversation you're having with that customer (✋ *guilty as charged*).

The best advice I have on this is: **read the fucking room.**

If a customer is joking with you, it's probably OK to joke back. If they're clearly frustrated because their website has been down for two hours, maybe now isn't the time to hit them with a 😂.

Talking like a person means explaining like a person.

Also, working in support, you're probably privy to a lot of terminology the customer isn't used to, but they shouldn't need a dictionary to understand your response. If you can explain something complicated in plain English without making the customer feel dumb — that's a skill, and probably one of the most important ones to have working in this field.

The customer already knows they are talking to a company. You don't need to remind them of that. Let them know they're talking to a human, too.

![](https://storage.ghost.io/c/6f/44/6f4432a1-6529-4a88-be51-2023601993b6/content/images/2026/10/C2B126C5-28FB-490F-A30F-61DAA733C4C3.png)

### The job is removing friction, and educating

At the end of the day, I think the actual job of customer support is pretty simple: remove the friction and educate.

If a customer writes in, something got in the customer's way. They couldn't figure something out, or something broke... maybe the documentation they have didn't make sense, or the product didn't behave the way the customer expected it to.

Your job is to get that thing out of their way, or guide them to the solution.

I think there's another part of support that doesn't get talked about enough: educating the customer while you're answering their questions.

There's a huge difference between fixing something *for* someone and helping them understand *what* happened, leading them to self-help.

If I can fix their problem in 30 seconds, great. BUT, if there's something else along the way that will help them understand why it happened, how the feature works, or how to avoid running into the same problem again, you can bet your ass I'm going to tell them.

Not because I want to brag about how much I know, but because I don't want them to have to contact me again about the same fucking thing tomorrow.

Educating someone doesn't mean throwing a documentation link at them and saying, "Here, read this." Sometimes it's a few more sentences about why I'm sharing the link, a screenshot or screen recording, or me explaining *why* I'm asking them to change a setting instead of just telling them to change it. Sometimes it's sharing documentation *after* I've answered their question so that they have a point of reference for later.

Good support should leave a customer in a better position than they were when they initially reached out.

Maybe their problem is resolved now. Maybe it can't be fixed, and they understand why. Maybe you gave them a workaround. Maybe they learned something about the product that'll prevent them from needing support the next time.

That's the part of support I think that gets lost, when we reduce the job down to just answering tickets. We're not just here to make the queue number go down — we're here to make using the product easier.

... and if I've done my job well, hopefully the next time they run into something similar, **they won't need me at all.**