How Providing Customer Support is Like Defusing a Bomb

I recently read How To Be Calm Under Pressure: 3 Secrets From A Bomb Disposal Expert (via Swiss Miss) and immediately connected its 3 secrets with 3 guiding principles for providing customer support. I recommend you read the full article, but here’s a recap of the 3 secrets along with my observations about how they connect to support:

  1. Do a threat assessment. While you may not be defusing a literal bomb, a customer in distress can make you feel like you are. Don’t panic. Assess the customer’s problem and try to think of a similar problem you have handled in the past. This makes the problem less intimidating and gives you a place to start troubleshooting or resolving it.
  2. Emphasize the positive and what you can control. Is the customer facing a bug? Did they experience a serious problem with your product? Focus on positive aspects of the situation and actions you have the power to take for the customer. That could mean providing workarounds that you know about, making small fixes you know will help, or even bigger solutions like proactively offering the customer a refund if something went really wrong.
  3. Focus on the next step. Don’t try to solve the entire problem in one shot. Focus instead on just the next step you need to take. Did you just uncover a giant bug in the product? Set that aside for a moment and focus on this one customer and how to help them first. Not sure what went wrong or how to help the customer? Focus on talking through the problem so you understand it fully. In other words, think about just that one thing you need to do next, to avoid getting overwhelmed.

These general guidelines have helped me handle any number of stressful situations with apparent ease, including the pressure of being on the front lines of customer support. I hope they serve you well!

Advertisements

The Josephus Problem: How math teaches us to solve problems

When I was in school, I always thought math word problems were a little funny. I understood that the point was for me to apply math to solve real-world problems, but the problems never felt real. However, these days I truly appreciate all of the ways that math taught me how to think about, break down, and work through problems.

Numberphile has a wonderful example of how to approach problem-solving with the Josephus problem:

These are the same skills you can use to solve a problem in support, as well:

  • Gather data about the problem
  • Look for patterns
  • Make a conjecture
  • Test your conjecture

As noted in the video, it’s also incredibly important to tackle small, discrete parts of the problem and work from there to the larger solution. If you stare at a big problem, it can look impossible to solve. But if you can prove theories about small parts of the problem, the larger solution can become clear.

Thank you to all of my teachers and others who encouraged me to learn and practice these skills — although I don’t do much pure math these days, I use these skills every day!

Using Mental Models for Troubleshooting

When a user reports an issue they’re having with the product you support, how do you know what to do next? How do you identify the source of the issue? How do you know where to start investigating?

I’ve mulled over these questions countless times as I tried to explain to coworkers how I troubleshoot. When someone describes an issue, it always seems like the possible causes just pop into my head, unbidden. But of course that isn’t it at all — I have gotten better at troubleshooting our products over time, and that didn’t happen by chance.

When I read Jim Grey’s post How to Hire an Entry-Level Tester, his key traits for testers meshed with how I understand troubleshooting and this trait stood out:

Create mental models:  Building a mental model of a system, even if it’s incomplete or partially inaccurate, helps a tester orient themselves to a problem and generate ideas on how to work through it.

When I look at a problem, I fit it into my mental model of the product and use that model to start investigating. On my team, I’ve started to explicitly discuss mental models, how to build and expand them, and how to use them to get better at supporting and troubleshooting our products. Rather than trying to summarize the things we’ve talked about on my team, I’ll share the introduction to mental models I wrote recently, as part of a troubleshooting training I’m developing for WordPress.com support.


Mental Models

mental model is “an explanation of someone’s thought process about how something works in the real world” (Wikipedia). In other words, a mental model is how you understand or represent a real thing in a more simplified or abstract way.

Mental Model of a Bicycle

To get a better sense of mental models, let’s look at an example: Bicycles. Not everyone understands every part of a bicycle, but even if you just ride a bicycle now and then you probably have a concept of what it is and — at least to some extent — how it works. That is your mental model.

A user’s mental model

As a bicycle user, your mental model might be very simple — all you need to know are the parts you interact with or a general sense of what makes a bicycle different from, say, a tricycle or a car. In this simple mental model, you’ll see that the bicycle includes a frame, handlebars, a seat, and two wheels:

bicycle-simple
Continue reading “Using Mental Models for Troubleshooting”

Report a Bug — Start a Conversation

Today at Automattic, I gave a presentation called Life Cycle of a Bug Report. Ostensibly, it was about the elements of an effective bug report and what happens to a bug report after it is opened. Ultimately, though, it was about how Happiness Engineers fit in to the rest of Automattic (or, more generally, how a support team fits in to the rest of a company), and how reporting bugs and other feedback can lead to better communication between support and product teams.

Here’s how customer support can sometimes look:

Dev-User-HE-Brokenloop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems.

Ideally, however, there is a complete feedback loop:

Dev-User-HE-Loop.png

  1. The product team launches a product to the users.
  2. The users use the product, and when they have questions they reach out for support.
  3. Folks in support help users solve their immediate problems and communicate bugs, pain points, and other feedback to the product team.

In that complete loop, the people who spend the most time talking with users can advocate for those users and help set priorities for addressing pain points. Support folks also get an opportunity to connect more with the people who spend the most time creating and improving the product, to better understand existing priorities and resources.

When I write a bug report, I’m not just dumping a problem on someone else’s lap or giving someone a hard time for the product they created. I am pointing out a source of pain for the product’s users and starting a conversation about how to address it, in the context of everything else a product team is working on. In the process, I develop stronger relationships with our product teams and, as a result, can provide better, more informed support to our users.