Over time, I’ve started to think that there is a subtle difference between customer support and customer delight.
Customer support is about solving a problem. A customer reaches out because something isn’t working, they have a question, or they need help figuring something out. Our job is to understand the issue and help them get to a resolution.
Customer delight, at least the way I see it, goes a little further. It is about paying attention to the person behind the problem and making the experience of getting help feel as easy and reassuring as possible.
That doesn’t necessarily mean doing something extraordinary. Quite often, it is about noticing the small things and deciding to care a little more.
Sometimes, the customer tells you exactly how they are feeling
One thing I particularly like about the way our support forms are designed is that we don’t only ask customers to describe their problem.
We also ask them how they are feeling.
They can choose between Awesome, Curious, Confused, Worried, or Panicked. We also ask whether they would prefer a Geeky Reply or a Normal Reply.
At first glance, these might look like small, almost playful additions to a support form. But I think they give the person responding to the ticket some valuable context before the conversation even begins.
A customer who says they are curious is probably approaching the interaction very differently from someone who says they are panicked.
And that context matters.
I remember one particular customer who selected “Panicked” and, even from the short description in the subject and initial message, it was clear that he was frustrated and worried about what was happening.
There are times when you could simply look at the issue, provide the next troubleshooting step and move on to the next ticket.
But this felt like one of those situations where the customer needed someone to stay with the problem.
So I did.
We worked through the issue, investigated what was happening, and eventually got him a solution through a development version of the fix. But I didn’t consider the interaction finished there.
I followed up after the issue was fixed. Then I followed up again when the fix was officially released in an update.
The technical problem had been solved earlier. The customer’s experience, however, continued until he knew that the proper fix was available and that he wasn’t going to have to worry about the same problem again.
He was genuinely happy with how the situation was handled.
That interaction stayed with me because it reminded me that sometimes the most valuable thing you can give a customer isn’t an immediate solution. It is confidence that someone is actually taking ownership of their problem.
A correct answer isn’t always a great support experience
It is very easy to think of support as a sequence of questions and answers.
The customer asks something. We provide an answer. The ticket is resolved.
But a technically correct answer can still create a poor experience.
Maybe the response is difficult to understand. Maybe it uses terminology that makes perfect sense internally but means very little to the customer. Maybe the customer has already explained the problem and is asked to repeat everything again. Or perhaps they receive a link to documentation when what they really needed was someone to explain what to do next.
I’ve learned that communication is part of the solution.
If someone is confused, the answer should make things clearer, not add another layer of complexity. If someone is worried, reassurance and clarity can be just as important as the technical solution. And if someone is panicked, responding in exactly the same way you would respond to someone who is simply curious doesn’t make much sense.
This is one reason I like the idea of asking customers how they are feeling. It reminds the person on the other side of the conversation that there is a person on the other side of the ticket.
Ownership doesn’t always mean having the answer
There is another thing I’ve learned from working with customers: you don’t always have to know the answer immediately to provide a good experience.
Sometimes the issue needs to be investigated.
Sometimes you need help from another team.
Sometimes there is a bug that needs to be fixed.
Sometimes the requested feature simply isn’t available.
And sometimes the answer is going to take longer than either you or the customer would like.
What matters in those situations is what happens next.
If I don’t know the answer, I’d rather be honest about it and take responsibility for finding out than give a vague or overly confident response just to close the conversation.
The same applies when something needs to be fixed by someone else. The fact that I can’t personally make the code change doesn’t mean I can’t own the customer’s experience while that change is being worked on.
That was essentially what happened with the customer who was panicked.
The solution wasn’t something I could simply produce on the spot. But I could make sure that the issue kept moving, that the customer wasn’t left wondering what was happening, and that I followed up when there was meaningful progress.
For the customer, that difference can be huge.
Customers influence the experience too
There is another side to customer experience that doesn’t get talked about as much: the customer also influences the interaction.
Some customers are incredibly good advocates for the products they use. They understand that there are real people behind the support conversation. They provide useful information, explain what they are trying to achieve, and remain polite even when something isn’t working.
That can completely change the dynamic of a support interaction.
When someone approaches a problem constructively, it becomes much easier for the person helping them to go the extra mile. You want to dig a little deeper. You want to investigate another possibility. You want to see if there is something else you can do.
Not because polite customers somehow deserve better support than everyone else, but because a good interaction creates the conditions for better collaboration.
I’ve seen situations where a support agent could potentially have stopped at the obvious answer, but instead kept investigating because the conversation made it clear that the customer genuinely needed help getting to the right outcome.
That extra effort can sometimes make a bigger difference than the original answer.
It is a reminder that customer experience isn’t created by one side alone. It is a conversation between people.
Customer delight isn’t about saying yes to everything
There is also a misconception that delighting customers means always giving them what they ask for.
I don’t think that’s sustainable, and I don’t think it’s necessary.
Sometimes the answer is no.
Sometimes a limitation exists for a good reason. Sometimes a feature isn’t available. Sometimes the requested solution isn’t technically possible or isn’t the right approach.
The important thing is how that conversation is handled.
There is a big difference between telling someone, “We don’t support that,” and explaining why, understanding what they are actually trying to achieve, and suggesting an alternative if one exists.
The outcome might still be a no.
But the customer can leave the interaction knowing that someone understood what they were trying to do.
That matters.
The ticket being closed isn’t always the end
One of the things I have started paying more attention to is what happens after the immediate problem has been solved.
From an internal perspective, the ticket might be ready to close.
From the customer’s perspective, they might still be waiting to see whether the fix actually holds, whether the workaround is permanent, or whether the official update has been released.
That’s why I think follow-ups are so valuable.
A simple message asking whether everything is working as expected can change the experience considerably.
It says that the goal wasn’t simply to get the ticket out of the queue.
The goal was to get the customer back to where they wanted to be.
In the example I mentioned earlier, the problem was eventually resolved through a development version and later through an official release. Following up through that journey didn’t necessarily require a huge amount of effort, but it made the customer feel that the issue hadn’t simply disappeared into a support queue.
Someone was still paying attention.
So, what is customer delight?
The more I think about it, the less I believe customer delight is about grand gestures.
It isn’t necessarily a discount, a freebie, an elaborate email, or an unusually enthusiastic response.
More often, it is much simpler.
It is understanding that the person contacting you may have already spent an hour trying to solve something.
It is noticing that someone is worried and adjusting your response accordingly.
It is not making a customer repeat information unnecessarily.
It is being honest when you don’t know something.
It is taking ownership even when the solution requires someone else.
It is following up when you said you would.
And sometimes, it is simply staying with a problem a little longer than you technically have to.
These things sound small, but they are often the things people remember.
A customer may not remember exactly what you wrote six months from now. They may not remember which internal team fixed their problem or how many messages were exchanged.
But they are likely to remember whether getting help felt frustrating or reassuring.
Whether they felt like a ticket number or a person.
Whether someone simply answered their question or actually cared about getting them to the other side of the problem.
For me, that is the difference between customer support and customer delight.
Support solves the problem. Delight builds the trust that comes from knowing someone cared enough to see it through.