6. Our Blocked List

6. Our Blocked LIst

We have some words and phrases that you should avoid because we want to ensure that our merchants feel valued and never like we think they're asking stupid or bad questions. Buffer has some great thoughts on this:

...if customers take time out of their lives to ask us a question, thus teaching us about areas of confusion in our app, we'd love if they never have any occasion to feel stupid, or wrong, or corrected.

Here's a list of words and phrases you should avoid:

  • Actually / In Fact: This tends to come across like you're being condescending. "Actually, you can do this under 'Settings.'"

    We can do better – we're not correcting, we're teaching: "Sure thing, you can do this under 'Settings' :)".

  • But: Whatever you say before "but" doesn't matter. "I really appreciate you writing in, but unfortunately we don’t have this feature available." All the customer hears here is "we can't do it". Instead, let's make both of those phrases clear: "I really appreciate you writing in! I'm afraid we don't have this feature available."
  • To be honest: You should already be honest. If you're just starting now, the customer doesn't trust you.
  • Just: This one depends on context, but "You just have to log in," makes it sound like everything should be easy. For some merchants, it's not, and we shouldn't make them feel bad about it. "You can log in," or "Could you please log in?" work better.
  • Ticket: This makes merchants feel like cattle in a line. They're not tickets because they're people. We have conversations."I'm going to loop my colleague in on this conversation so I can get the best answer for you." Try to get in the habit of striking the word "ticket" from your vocabulary, even when communicating internally to the company via GitHub comments, slack messages, whatever.

And here are some words / phrases you should limit:

  • I hope this helps: This shuts the conversation down and doesn't ensure we've solved the problem. We don't hope it helps, we want to ensure it did. While it can be used as part of a closing, it should not be the entire closing. (There are times you may want to shut the conversation down intentionally, but that's the rare exception, not the rule.)

    Instead, we ask if we can help with anything else, or for confirmation everything is resolved. This keeps the conversation open and welcomes more questions instead of shutting it down.

    No: "I hope this helps! Cheers, Beka"
    Okay: "I hope this helps! Can I help out with any other questions? Cheers, Beka"
    Yes: "Could you please let me know if this resolves the issue for you? Cheers! Beka"

  • Unfortunately: Sometimes this is needed when we're sorry we can't do something, but we shouldn't say it more than once or twice in an email (and in general, should try to be solution-oriented instead). Get rid of it where you can: "Unfortunately this isn't currently available with our app / plugin." Instead: "This isn't available with our app / plugin yet, but we're already working on it!" or "I'm afraid this isn't part of what our [software] offers; we don't currently have this on our roadmap, but I'll be sure to keep you in the loop if this changes."