4 Rules of Improv and How They Relate to Customer Support

One of the many memorable bits in Tina Fey's book Bossypants is a section featuring several "Rules for Improvisation". In it, she details four guiding principles that help make a good improv comedian.

When re-reading the list, which is also proudly posted at the famous Second City Theater in Chicago, I couldn't help but be struck by how the principles also have relevance to how we help users in customer support. Though maybe that shouldn't be surprising, as in support we're often handed a situation and asked to react to what develops, much like a sketch comic.

Let's take a look at Fey's four rules and see how they apply to customer support:

Rule 1: Say Yes

The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, "Freeze, I have a gun," and you say, "That’s not a gun. It’s your finger. You’re pointing your finger at me," our improvised scene has ground to a halt. But if I say, "Freeze, I have a gun!" and you say, "The gun I gave you for Christmas! You bastard!" then we have started a scene because we have AGREED that my finger is in fact a Christmas gun.

First things first, Saying Yes does not mean to never tell a user "no." You need to be able to say no to a user, otherwise by trying to satisfy every potential user you end up underwhelming all of your users. Instead, Saying Yes means acknowledging what the other person is trying to communicate to you. You may tell them "no," or "not now," or move your product in another direction, but our replies need to show off that we understood their sentiment, frustration, and specific need.

So what does Saying Yes look like in practice? It means making extra sure you're getting the entirety of a user's message when you think you've gotten the gist and are already formulating your reply (or reaching for the canned reply) before reading to the end of that message.

It means when you get feedback, fighting the defensive urge to dismiss the request as the user's ignorance or misunderstanding, or even lack of fit for your product. That urge can be sneaky too. It can manifest itself as a reply that's more concerned with why the user was wrong, rather than showing them that you understood their pain to begin with. There's absolutely a place for the former, but it should always come after the latter has been expressed.

Rule 2: Say Yes AND

The second rule of improvisation is not only to say yes, but YES, AND. You are supposed to agree and then add something of your own. If I start a scene with "I can’t believe it’s so hot in here," and you just say, "Yeah…" we’re kind of at a standstill. But if I say, "I can’t believe it’s so hot in here," and you say, "What did you expect? We’re in hell." Or if I say, "I can’t believe it’s so hot in here," and you say, "Yes, this can’t be good for the wax figures." Or if I say, "I can’t believe it’s so hot in here," and you say, "I told you we shouldn’t have crawled into this dog’s mouth," now we’re getting somewhere.

While Saying Yes is about empathizing with the plight of users, Saying Yes AND is about getting users closer to solutions. Yes AND means answering the question AND going one step further. It's about guiding the user to the next step in the process, or maybe pointing out a potential pitfall that may be around the corner once they're able to move forward.

Like Fey says, if you just respond with "yeah…", things aren't moving forward because the onus is back on the user to figure things out. This extends support interactions further when they inevitably ask about those next steps, a worse experience for them and more work for support staff.

One of the best ways to go that extra step is in linking to documentation on those next steps to get a user to the end goal. Not only does it serve as a call to action so the user can get started on that right away, but it promotes self-service so that a user might discover future answers without needing to contact you.

However, Yes AND is also about making yourself available, inviting the user to continue the conversation if they have further trouble, or to reach out again if they have a different issue. Along with giving users a call to action or next step, doing so adds up to a powerful combination of empowering the user while not making them feel like they're being pawned off to static documentation.

Rule 3: Make Statements

The next rule is MAKE STATEMENTS. This is a positive way of saying "Don’t ask questions all the time." If we’re in a scene and I say, "Who are you? Where are we? What are we doing here? What’s in that box?" I’m putting pressure on you to come up with all the answers.

In other words: Whatever the problem, be part of the solution. Don’t just sit around raising questions and pointing out obstacles. We’ve all worked with that person. That person is a drag. It’s usually the same person around the office who says things like "There’s no calories in it if you eat it standing up!" and "I felt menaced when Terry raised her voice."

Making Statements builds off similar logic for why we Say Yes AND. In customer support we often carefully choose our words to avoid absolute answers, lest our word guarantees blow up in our faces at a later time if our fix didn't work, or if there was some confusion about wording that leads to a different interpretation.

This isn't inherently bad, but Rule 3 reminds us that as the people responding to our users, we are the experts in the eyes of our users. If we hem and haw and give noncommittal answers, then who could possibly know the real truth? If you aren't as explicit as possible with your responses, it erodes trust in your support experience, and really your product as a whole So if you know the answer, say that clearly.

If you don't know, say that, too, but also go the Say Yes AND route of telling the user you'll find the answer or point to where they can find it themselves. Take these words that are used to "hedge" in replies:

• Probably

• Should

• Could

• Potentially

• Possibly

The more of these types of words show up in a single answer, the worse the message you're communicating to the user.

Rule 4: There Are No Mistakes

THERE ARE NO MISTAKES, only opportunities. If I start a scene as what I think is very clearly a cop riding a bicycle, but you think I am a hamster in a hamster wheel, guess what? Now I’m a hamster in a hamster wheel. I’m not going to stop everything to explain that it was really supposed to be a bike. Who knows? Maybe I’ll end up being a police hamster who’s been put on "hamster wheel" duty because I’m "too much of a loose cannon" in the field. In improv there are no mistakes, only beautiful happy accidents. And many of the world’s greatest discoveries have been by accident. I mean, look at the Reese’s Peanut Butter Cup or Botox.

Much like Rule 1, what this is not saying is "you can't make mistakes." Quite the opposite, in fact. Our humanity curses us to a lack of perfection. The product will fail, mistakes will be made, we'll give people the wrong answers. Like Fey mentions though, this is also our greatest opportunity to make an impression on a user.

While the average company will try to paper over their mistakes with stilted and insincere responses, you can set yourself apart with your authenticity. Say you're sorry like you would to a friend that's there in the room with you, and give them a next step if at all possible (notice how this also encompasses Rules 1 and 2?).

Our instinct when we make mistakes is to minimize them as much as possible, and that shows in how the average company responds to those situations. After all, users would be angry if they knew we just screwed up, or lose trust in our reliability if we outright admitted our shortcomings. Right?

In practice though, this tends to work out just the opposite. Customers have been conditioned for years to expect non-apology apologies, and that only serves to further upset them as they feel they aren't being heard or treated as if they don't matter (hey, Rule 1!).

This leads to users that are irritated because of what they expect is coming in a response, and is the source of that great opportunity. By demonstrating that you feel their pain point in your replies, users often flip to the other side entirely. We've seen numerous users write in with irritation about their Zapier experience become some of our biggest cheerleaders after our response demonstrated a concern for their individual needs. Our mistakes end up as big wins, and that's why "there are no mistakes."