The GiveWP Tone Guide

No shade on my former employer, but it appears that they've functionally taken offline the Tone Guide that Matt Cromwell and I worked so hard on all those years ago, which lives on in my book, but nowhere else on the internet, so I am moving the original document here as a reference.

We are our customer’s wise friend, not a corporate policy enforcer or policy defender. We want our customers to succeed, and we are the guide to help them when they need it. Our customer is James Bond, we are Q: equipping them with the tools, resources, and knowledge to win the day*. To that end, our tone is marked by these qualities (with the helpful acronym CREW):

• Confident, not Apologetic
• Results Oriented, not Argumentative
• Educational, not Haughty or Overly Technical
• Welcoming, not Thankful

The best support technicians know their biases and tendencies. For example, if a technician is prone to argument, they should take special care to make things results-oriented. It’s helpful to do a postmortem of all negative rating interactions to see which part of the tone guide broke down in the process. Almost all negative ratings (even the unfair ones where they rate the technician negatively because of a lack of feature) can be traced to a breakdown of one of the four points in CREW.

💡 Pro Tip: Slow Down. There’s no substitute for proofreading when it comes to tone. It’s a best practice to take the extra 30 seconds to re-read drafts checking for each of these items before sending the message, asking the question “is this CREW?” and modifying the message before sending it.

Confident, not Apologetic.

We are proud of our product and company and don’t apologize for things that are not our fault. We empathize with our customers and don’t waste time defending our products or ourselves, but we never apologize for things beyond the scope of our (team’s) control.

Things to apologize for:

• “So sorry for my slow response to this issue. The fastest way to resolve the problem is _”

Things you shouldn’t apologize for:

• “I’m sorry for the theme conflict you are experiencing.” Instead: “We work very hard to ensure that our products are compatible with the vast majority of the themes out there. It looks like our product is not playing nicely with your particular theme. Here are the steps to resolve this:”
• “I’m sorry for this bug” Instead: “This issue has been urgently escalated and our developers are working as I type this to release a patch. I’ll let you know as soon as I hear anything from them.”

Results Oriented, not Argumentative

Many of the folks who reach out to support are frustrated, having attempted to solve a technical problem for potentially hours before reaching out. In their ticket or response they can resort to attacking us, lashing out at the product or team, or getting distracted by inconsequential details that don’t move the issue toward resolution.

We do not respond to their frustration with a defense of our actions, our team, or the current reality.

Instead, we seek to find the source of their frustration, and resolve it.

For example, let’s say a customer replies to you saying “Your team is incompetent”.

• Ineffective response: “Actually we’re quite competent. I have a degree in Something, have spent the last however many years in customer support, and thousands of people are thrilled to use our products daily”
• Effective Response “I’m happy to get to the bottom of this with you. Other users who have had this problem resolved it following these steps:”

Functionally, we simply ignore the insult, and then prove them wrong by resolving the problem.

We never stand for sustained mistreatment of our team by customers, but can understand and empathize with frustration. While we won’t work with customers who are repeatedly abusive towards our support team, it is important to us to step into their shoes and be on their side to resolve the problem.

Most of the time resolving the problem results in a change in tone from the customer. When it does not, those situations are escalated to the Head of Support.

Educational, not Haughty or Overly Technical

We are experts in WordPress from a technical standpoint. We understand hooks, functions, PHP, and JavaScript, and are able to resolve problems. There is a temptation when talking to customers to show them how much we know by using jargon, insider-speak, and overly technical language.

Far from making the customer feel better, overly technical jargon makes them feel incompetent and ignorant. If our job is to be the Q to their James Bond, we have to always set them up to understand the things we are showing them.

For example; let’s say a user had a Javascript error that was making things difficult for our plugin.

• Ineffective Response: “The problem is a script loading in the header that’s throwing a jQuery error preventing the rest of the form from loading”
• Effective Response “A file that is loaded by Example plugin is not playing nicely with one of our files, and that conflict is preventing the form from loading correctly. Here’s how I recommend confirming and resolving the issue…”

It’s helpful to imagine scenarios where you are in similar situations. One example is the doctor’s office. Imagine going to a medical doctor for an issue with your daughter’s development.

• Ineffective Response: “The issue here is acute craniosynostosis of the posterior temporal suture”

This response, littered with medical jargon, serves no purpose other than to demonstrate to the listener that the speaker has a large vocabulary, and possibly a firm grasp on a medical condition. In a strange twist, the more technical language actually proves less about the competence of the doctor than simple and understandable language would.

• Effective Response: “You know how the skull has gaps (soft spots) in it when you are born, that you can feel? The issue for your child is that one of those gaps, specifically one of the ones on the back of her head, closed prematurely. Here’s how we go about fixing that…”

If you can’t explain it to a ten-year-old, go back and rewrite it.

💡 NOTE: Avoid being patronizing to developers and agency folks who reach out. If they reference the developer console and provide a specific line of code where they are having a problem, treat them with respect, and educate them specifically about our products.

Welcoming, not Thankful

Thankfulness, especially as an opening, is functionally white noise to the customer. Like an automated greeting that says “Your call is important to us…” the line “Thanks for contacting support” is ignored at best, or ridiculed at worst.

Instead, we are excited and welcoming. Taking the few extra seconds to find some common ground with a customer and personalize the welcome is a difference between a customer being on the defensive (because they are prepared to meet the policy enforcer) and being delighted that they have found their wise friend to help them win the day.

For example, how you set the tone with your first sentence in your first reply makes a big impact.

• Ineffective Opener “Thanks for contacting our support”
• Effective Opener “It’s so great to help raise awareness for Autism and special needs children. I’ve seen this technical issue you’re experiencing before, and look forward to getting you back to doing what matters: helping the kids.”

💡 NOTE: Don’t fake it. If you are not excited about their organization, skip straight to “You’ve come to the right place: we’ll get this technical issue sorted for you in no time.” Lead with being welcoming, even if you can’t lead with excitement for their site.

When people go to tech support, they brace themselves for being made to feel stupid. Our job is to welcome them, and explain that we’ve been here before.

*hat-tip Donald Miller’s StoryBrand for the “make the customer the hero” insight.