Category: Margins

A twice-monthly newsletter about the craft of customer support and how expertise is found in the margins of our work. Find out more.

Bug Expectations

When someone runs into a bug our natural inclination is to help them feel optimistic. We likely can’t personally fix the problem and we want to reassure them that their issue is important and will be fixed. This might create short-term happiness but it risks long-term frustration and disappointment.

It’s a lesson that’s often learned the hard way. You tell a customer that something will be fixed only for it to linger in the bug tracker and, 6 months later, cause that customer to be furious with you. It happens to all of us. I sent far too many replies like this early in my career:

Unfortunately this is due to a bug on our side. Don’t worry, though, I reported it to our development team and we’ll get it fixed soon. I’ll let you know when that happens and thanks for your patience!

So optimistic! But there are three problems in that type of response: it promises a solution, it suggests a timeline, and it fails to provide a workaround.

We just created a cascading series of problems for our future selves. We didn’t provide a workaround so the person we helped is now stuck and likely to ask for an update next week. We promised that we would fix the issue and put our development team on the hook for an expectation they had no hand in creating (and are likely unaware of). And we set a timeline and created a ticking clock in our customer’s mind.

Plus, if we don’t deliver we let the customer down twice: we have buggy software and we can’t follow through on our commitments. Let’s avoid that! Instead, it’s best to set less concrete expectations and follow three guidelines.

Figure out if there’s a workaround

The best bugs are those we can avoid by working around them. They still need fixing but avoidable bugs are simply less annoying (for both us and those we help). To find the right workaround, ask the person about their ultimate goal. If you listen closely to their goal (rather than the exact steps they want to take) you can often find an inconvenient-but-feasible solution. It may not be what they hoped for, but it gives them a way to move forward.

This also lightens our self-imposed pressure. Avoiding the bug is already a positive result! You can close the conversation with something like, “We’ll look into what’s happening here and I’m glad we got another option set up for you.”

Decide if you’ll keep the customer updated

Bugs that people experience every day merit periodic updates. Those customers, even if they memorize a workaround, will have a daily reminder of your product’s flaws. But that’s not every bug, and you certainly don’t have to keep every customer updated about every bug. A good question to ask yourself is whether this bug exists in an infrequent product flow or in a pattern of regular usage. Infrequent bugs mean there’s less value in ongoing updates, especially if you already helped them avoid the bug with a clear workaround. For those customers the bug may just be a one-time occurrence.

It’s best to have a consistent approach across the team so that customers get a similar experience once they run into a bug. One way to create that team-level consistency: audit the last 100 bug tickets you resolved, measure how long it took between initial report and resolution, and measure how many total replies your team sent out with status updates. If it’s taking months to resolve the typical bug those followup replies are likely wasting time for both your team and customers. Calibrate your approach to your customers and your product as the right answer depends on context.

Promise information, not solutions nor timelines

This can push against every tendency you have. The problem is that software development is a complex process in which even seemingly “simple” bugs can stump a team or sit in a backlog.

The only situation in which I feel comfortable providing a timeline is when the bug is already fixed and that release is already planned. In other scenarios there’s just too much that can go wrong.

The best approach is to set simple expectations. It’s better to promise future updates instead of specific next steps. As one example, you can write, “We don’t have a timeline right now but if that changes I’ll let you know.” and avoid writing, “I’ll let you know once our team has [investigated, fixed, or looked into] this bug.” People may be disappointed, but you’re at least not giving them false or risky hope.

One caveat: the above advice applies best if your product serves individuals. If the bug impacts a 6-figure enterprise account then you very likely must solve the bug and keep them updated. But work as a team and match expectations to what your development team can deliver.

People ultimately respond best to honesty. When they run into a bug in your product they’ll often feel fixing it should be your top priority. But we know that’s not always the case. It’s better to help them feel heard without setting them up for future disappointment.

Provide Certainty

One of the best things we can do in support is provide people with certainty. It gives the people we help confidence to reach their goal and increases the likelihood they’ll be successful using our service. To do this well we must pay particular attention to our language, as it’s all too easy for uncertainty to slip in. And uncertainty is not why people turn to support.

People contact support only after something’s gone wrong. They’re stuck, they fear they broke something, or they’re stressed in our unfamiliar world of bits and buttons. Our queues are not filled with messages from self-sufficient customers who have it all figured out. If only! Instead, we help motivated-but-lost people. People who are looking for certainty.

We often introduce uncertainty when we try to be conversational. In an effort to seem approachable we soften our language as if we were talking to someone in-person. This is when we dip into our bag of “should” and “usually.” Those are dangerous words for support writing.

“Usually” risks over-simplifying the matter. The problem is that usually people don’t have to contact us at all! So by the time somebody contacts us we are already into the realm of the unusual. It can also imply a sense of carelessness or a lack of due diligence. People pick up on that. When you tell someone that your suggestion “usually” fixes things they all too often think you’re just moving them along. In their mind, you’ve done the bare minimum to understand the issue and just want their problem to no longer be your responsibility.

Pay particular attention to “usually” when offering common suggestions. Take the example of clearing a browser’s cache; there are plenty of issues that this truly does fix. But it’s so common that it can feel like a guess or deflection. Instead of making the usual suggestion, tell them the best first step to take (bonus points if you also tell them why it’s a good idea to start there).

You can usually fix this by clearing your browser’s cache. To do this…

The best first step is to clear your browser’s cache. This will help us rule out any common but pesky issues that might be at play. To do this…

Every time we write “should” we need to be similarly wary and ask ourselves why we can’t just write “will.” When writing that something “should” work I picture the other person raising an eyebrow and asking, “Well…aren’t you the expert? Don’t you know?” They’re right! This kind of uncertainty is often an indicator that we’re hedging our bets or moving too quickly. We might be pattern matching instead of diagnosing this person’s situation. Instead, where at all possible, verify that your suggestion will work and write as much.

Some situations are inevitably uncertain. We investigated all we can but we’re short of complete confidence and don’t want to make a false promise. In this case we need to counterbalance “should” with a definite next step. If clearing the browser’s cache “should” fix things, then what’s the next step when that doesn’t work? Figure that out before replying and include it in your message.

Those steps above should clear everything up. Thanks for writing in!

Those steps above should fix the issue. But, if you try what I outlined and find it’s still not working, the next step is to…

These small language changes can have a big impact on the people we help. Simply using our service has likely left them more uncertain and hesitant than they’d like. They turned to our service with hope and a goal but have found themselves lost and confused. Even the software-savvy people we help are new to our particular, sometimes quirky, configuration of pixels and screens. For both, the uncertain and the savvy, confidence is elusive. We can lend people our confidence and expertise. We can show them the definite path forward.

The Craft of Customer Support

I’ve long-wished for more blog posts about the craft of customer support, posts that came from individuals rather than company blogs. Perhaps when you spend all day writing to customers the idea of even more writing isn’t exactly appealing. Fair. But there’s something qualitatively different about individuals writing in their own space on the web. And while I wrote more in the past, that’s lagged in recent years.

I’ve also long-felt that, no matter our career, we build our experience in the margins. Our expertise is driven by the small edges we find, polish, and learn deeply. That holds true for support, and when we do the work well it can be a long-term career. The question is how we as a community explore and teach that expertise. Writing on the open web feels like the best answer, though I’m naturally biased given my work of the last 10+ years and counting.

Starting next week I’m going to combine those two outlooks and, twice a month, write about the craft of support. What exact form this takes is a bit TBD, but I’ve been thinking about two topics:

  • Support writing: Our words are our primary connection to customers and I’d like to explore how small adjustments in our writing can make all the difference.
  • Book recaps: Since reading is my primary hobby I’d like to recap my key takeaways from various customer support books, with an eye toward helping people find books worth exploring.

Sound interesting? You can subscribe via this site’s RSS feed or the newsletter below. The newsletter’s nothing special, since each post will be on the web, but if you prefer email this makes it nice and easy. No spam ever and a one-click unsubscribe.

Here’s to writing more about customer support and to finding our expertise in the margins. We can always learn from one another and improve.