Support Technicians: Stop Apologizing.
As a general rule in life, you should not apologize for things that are not your fault. Years (decades?) of the half-true mantra of “the customer is always right” have infected the customer service industry to the point where we are now apologizing for things that are not our fault, and using apologies as a sort of mortar for the conversational bricks in technical support replies.
When to Apologize
Now, allow me to provide some nuance: there are times when it’s appropriate to apologize (and at times even necessary. Here’s the short list of those times, off the top of my head.
- When you give incorrect advice or guidance.
- When you fail to reply in a timely manner (or within the timeframe you promise your customers)
- When a bug or issue was unavoidable by the customer.
If I told you to reboot your router, and then later discovered that telling folks to reboot their router actually made all problems worse, It’s both appropriate and expected to apologize. That apology should be short and to the point:
My mistake: I told you to reboot the router and then later discovered that it actually breaks this other thing when you reboot the router. Please accept my apology! Here’s what you should do to resolve your issue at this point…
When you fail to reply within the correct timeframe:
This falls firmly in the “things that are my fault” column. You should apologize when you personally don’t hold up your end of a bargain, and first response time is an agreement.
Hey Paul! Sorry this ticket didn’t get a reply within our promised 2-4 business hour window. That’s my fault. Here’s how to resolve your issue as quickly as possible…
When a bug or issue was unavoidable by the customer:
This one is a little slippery to pin down, and where lots of folks go wrong. I don’t mean “they experienced a bug” as a reason to apologize. Bugs happen, and in +90% of cases they are avoidable in production environments. Especially in the world of WordPress and distributed software installed on servers where the product developer has no control over the end environment, it’s *not my fault* when a conflict happens, and to spend time apologizing sets the wrong expectation for how this stuff all works.
I don’t mean it in a legal sense (though it may be applicable there as well) but in a practical sense: If I’m apologizing for a bug, it gives the user the impression that I have the power to fix it. In the WordPress world, the entire point is the decentralization of power and authority over the publishing and site ownership process. I can’t fix bugs on your site even if I wanted to. It’s your site.
So while I definitely want to empathize with and demonstrate that empathy to users who are frustrated with bugs or conflicts on their site, I want to be very careful to not add frustration to frustration by giving the impression that I can solve a problem that’s not mine to solve.
Showing empathy is easier without the apology.
So how do I show empathy without apologizing? Easy: put into words what the customer is feeling. Here’s a scenario, a bad response, and a proper (apology-free) response.
Imagine Jill, a site owner for an ecommerce website, sending out an email to their list of 5,000 contacts announcing a sale, with a link to a page on the site that takes payment for the product, and adds the user to a list for further updates. Now imagine just after sending the message, she notices a bug that’s preventing folks from being able to access the site at all.
Her support ticket is brief, frustrated, and doesn’t give enough context for the problem. She even sprinkles in some profanity.
I’m so sorry for this frustration! We try very hard to prevent things like this from happening, and even invested recently in a whole Quality Assurance team. Sorry to see that that hasn’t helped you. Here’s what we need in order to be able to help…
All of the words in the bad response before “Here’s what we need in order to…” are a waste of time and space, where instead of moving the customer toward resolution they are spending time essentially virtue signaling how bad we feel for them.
It’s analogous to an ER doctor taking time to hug you instead of helping to stop the bleeding.
If your goal is resolution of the customer’s problem, don’t spend precious response time patting them on the head. The best way to show that you understand urgent issues is to respond calmly, quickly, and with real steps toward solving the problem.
I’m so glad you reached out here. There are few worse feelings than knowing you sent thousands of visitors to a page that’s not working. I’ve been in similar positions and we’ll definitely get your issue sorted out as quickly as possible! First, and most importantly, let’s…
This response does a few things that are important: First, it doesn’t just skip ahead to the steps to resolve the problem. Skipping ahead would risk giving the impression that the technician either does not understand the seriousness of the situation or that they don’t care. Next, it demonstrates that the top priority is to get to the bottom of the issue and resolve it. There will be time later to diagnose why the problem happened. The first thing Jill needs is a fix going forward.
It feels like you are being insincere when you brush past someone’s frustration without an apology, so if you’re anything like me you’ll need to retrain yourself. In many cultures (including mine) apologizing is a cultural thing, we do it without thinking. If your goal is resolving issues, skip the apology.