Year: 2020

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.

The calm of rereading

A list of books that you reread is like a clearing in the forest: a level, clean, well-lighted place where you set down your burdens and set up your home, your identity, your concerns, your continuity in a world that is at best indifferent, at worst malign.

L.E. Sissman1

Even in normal times, reading is my primary hobby. In the midst of a pandemic, with none of the usual work travel that a typical year involves, that’s even more the case. My time for reading has easily doubled and, as importantly, is no longer interrupted by timezone changes and long flights.

One of the most calming ways to spend that time has been to reread favorite novels. These are those enjoyable stories that I find easy to reside within. They don’t have to be profound works of Literature, just books that I connect with.

Rereading brings something familiar back into the day. You catch an echo of previous readings and past versions of yourself. As the poet quoted above notes, rereading provides a piece of understood continuity in a world that can be anything but.

James Hilton’s Lost Horizon is near the top of this list for me. Pretty much anything by Hermann Hesse is, too, though The Glass Bead Game remains a particular favorite. And Susan Cooper’s The Dark is Rising series held up unexpectedly well despite (or maybe because of?) a 20-something year gap from my last reading.2

If you’ve not read a favorite novel in years, pick it up again. Give your brain a break from the world and any desire to be productive, just let it fall back into a familiar story and pattern at a time when we lack those things.

  1. Poet (slash advertising executive) and winner of a Guggenheim Fellowship as quoted in Alan Jacobs’ The Pleasures of Reading in an Age of Distraction.
  2. Try to ignore the cover art on the current edition, which feels very non-canonical; such is the problem of locking the first edition you read in your mind as The Right Edition.

2019 in books

Building off of 2018’s more organized list of books, I logged each book I read over the course of 2019. It was a more reading-filled year in which I finished 72 books. A big part of that came from making more time for reading in my vacations; the early morning hours are just the perfect time for a cup of coffee and a book.

Most of that reading happened over a digital format. The new(er) Kindle Oasis from Amazon is a near-perfect device, at least for my habits, and its adjustable warm light is one of those instantaneous difference makers I can’t imagine going without. While I still prefer hard copy books the convenience, portability, and single-purpose nature of the Kindle win out for day-to-day reading.

My favorites on the nonfiction side were Alain de Botton’s Status Anxiety and The Goodness Paradox by Richard Wrangham. They’re very different reads as one is more philosophical and the other more popular science. Status Anxiety considers why, both historically and ideologically, we feel such a need to gain and compete for status (and all the anxiety that comes along with that). The Goodness Paradox is a fascinating look how humans exhibit extremely peaceful day-to-day relations alongside vicious forms of planned violence. The discussion of bonobo and chimpanzee behavior and habitat was one I found particularly worthwhile.

On the fiction side, my standout favorites were three Classics-related books: The Song of Achilles and Circe by Madeline Miller, and The Odyssey by Emily Wilson. Miller’s books are retellings of myths from Ancient Greece. She really masters the storyline in a way that makes them accessible even if you’re unfamiliar with the history. Wilson’s book is a new translation of the Homeric poem. While it’s all written in iambic pentameter she relies on a voice that makes Odysseus’ journey engaging and easy to follow.

There’s a lot from 2019’s reading that has stuck with me and, I hope, will continue to filter into my thinking. A 2020 personal goal is to get more of my reading notes into a public, online format. Over the course of a typical nonfiction book I’ll take a few thousand words of notes, but they sit in raw, local text files. There’s some sort of editorial process those need to go through, though, to be intelligible outside of my own brain.

My 2020 reading list is up and running. And as I figure out how to best share reading notes I’ll link to them from that page.