Tag: support

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.

How to lose a customer, forever

Typically ease of use is something we think about when it comes to signing up for and beginning to use a service. I increasingly believe it’s the ease of use in leaving a service that has an equal impact on customer loyalty. The worse the experience of leaving is, the more your former customers will tell their friends not to even start.

Ultimately the cancellation experience should surpass, or at the very least meet, the signup experience in ease of use. Invert that relationship at your own risk because the harder it is to leave, the easier it is to decide to leave forever.

To illustrate this, let me recount my experience renting a small private office a few blocks from home. I toured the space on a weekday afternoon in February and decided to rent it on a month-to-month basis. 45 minutes after emailing the office manager I had everything signed and paid for.

On March 7th I was incorrectly billed an extra $15. On April 8th I was billed an extra $30. And again on May 8th I was billed an extra $30. On May 18th I got a refund for $45. But the remaining $30 was never refunded, despite multiple emails and in-person reminders.

Earlier this month I decided to switch back to working from home full-time. I emailed the office manager in the early afternoon on August 3rd, a Saturday. It will be 59 days later, on September 30th, that I will no longer be paying for an office I’ve not used since July.

There’s an asymmetry to the timeline of these transactions. I paid them thousands of dollars. They can’t be bothered to refund me $30. Signing up to pay them took an afternoon. Closing the account will take longer than it took to buy our apartment. And getting a refund is simply a lost cause (as is any inclination I have to ever use their services again).

There are parallels here to some of the more notorious customer experience complaints. I’m thinking of those companies with retention specialists, those that require you to pick up the phone to cancel a service you paid for online, that sort of thing.

We all know these companies. And when we do use them it’s more often due to the sheer lack of alternatives than it is out of loyalty. If you’re in a market where there are alternatives then you better pay attention to the ease with which customers can leave your service. If it’s an order of magnitude easier to signup than it is to leave then it’s only a matter of time before your customers have left for good.

Support Operations Webinar

At Automattic we recently started building a support operations team. We’re wrapping up hiring for a Director-level position and will add a handful of roles within the team after that. Formalizing this work will help us strengthen many of the behind-the-scenes processes that power our support. It’s been a great learning process to go through as well.

Later this week I’m joining the fine folks at Help Scout along with pros from SmugMug and FreshBooks to chat about how we’ve built our various operations teams. We’ll cover how we structure our teams, why we started building them, and more. It should be a great conversation!

You can find all the details for the webinar on Help Scout’s site. It’ll also be recorded, so if you can’t make it live they’ll send you the recording if you sign up.

Stressful customers

In support we often write to confused and frustrated people. After all, they likely got in touch with us because they’re confused and frustrated with our products. That’s okay, we’re expert communicators. We can help them get set up.

One thing we can do as part of that is not presume a customer is “abusive” or “rude” or “unreasonable” at the first mention of profanity and frustration. We want to resist our first impulse, which can often be to admonish the customer on their tone. This will more often than not aggravate their frustration.

Instead, when confronted with a profanity-laden message, our first instinct should be to give the customer the benefit of the doubt.

We must treat their frustration as a signal that we should invest more in our understanding of their situation. We need to pause, step back, and focus on the issue at hand. That means fully understanding the history of their interactions with us and their issues with our product.

It also means keeping the conversation focused on resolving their issue. We can recognize their emotion without condemning it nor playing into it. Every person we interact with is, well, a person. We all have moments when our frustration gets the better of us and we’re harsher than we mean to be with a company.

I believe our role in support is to help people be successful. And to see every conversation as an opportunity to change someone’s impression about our business and our product. Even the angry, profane, and ALL CAPS people deserve our help. After all, it’s typically our product or our missteps which have pushed them to frustration. That’s alright, our world-class communication can turn things around.

Three rules of maintenance

The condo building I live in has a property management company. This makes sense. The building is 120+ units across 12 floors with retail and office space. What doesn’t make sense is this same company’s poor communication. They are consistently unclear and underwhelming, particularly when it comes to maintenance.

Today they were servicing the fire safety system. This also makes sense. Fire is an existential threat to a 12-floor building and maintaining that safety system is key. But during this maintenance the alarm system speaker in our unit continually blipped on and off. Imagine the sound of plugging headphones in-and-out, in-and-out. Just a little blip. But that blip emanates from a unit typically used to signal a fire alarm or emergency. So let’s call this a disconcerting blip.

You’d imagine that ahead of maintenance like this a property management company would notify homeowners, right? Wrong. You’d also imagine that after being alerted to this disconcerting blip that company would acknowledge the impact, right? Nope. And you’d imagine that, even though a vendor was performing the maintenance, the property management company would take ownership of the mishap, right? Not really.

In thinking about this snafu it solidified some ideas in my mind around support and maintenance. I think they apply to software systems and physical infrastructure alike.

Provide awareness
It’s vital that you provide awareness for customers ahead of maintenance. Either passive awareness (like a status page they can check) or active awareness (like an email notification) can be successful. What counts is that you communicate somewhere, someway to your customers.

My property management company didn’t do this. At all. There was no email, letter in our mail, or notice on a bulletin board that this was happening. So when that disconcerting blip started I was just confused. That sucks. To resolve that confusion I went downstairs and talked to the on-site building manager (who is fantastic). He cleared things up instantly. But that’s not really his job.

When you don’t provide awareness for your customers you’re rolling the dice. Maybe everything goes well. If so, that’s great. But a single success does not signal a resilient process. Because when things don’t go well your failure to provide awareness amplifies your customers’ frustration. Now they’re angry at the impact of this maintenance and they’re angry at you. Best to avoid that.

Acknowledge impact
I know the maintenance plan calls for your customers to be fine. The maintenance won’t impact them. But, well, it might. And when it does you have to acknowledge that impact. That doesn’t necessarily mean you have to apologize. Things change. They don’t go according to plan. That’s life. Your customers will understand. Your first step has to be acknowledging that your work impacted their time.

My property management company didn’t do this. After talking to the on-site manager I sent the management team a short email explaining what happened and asking for a heads up next time there’s maintenance. A reasonable request, I think. Instead of any real acknowledgement, though, I got back this:

I spoke to Name (copied) and he said the speakers should not have sounded in your unit. There may be a problem in the system. He needs more information and will contact you to get this resolved.

That’s…factual? Nowhere in that do I hear an acknowledgement of impact. No, “Thank you for letting us know. This maintenance work wasn’t intended to impact homeowners and I’m sorry it did. We’ll improve our notification process going forward.” It’s nice to at least know the impact wasn’t intended. But when writing to your customers try and be a little less…cold. Acknowledge that, despite your best intentions, your work may have adversely impacted their day.

Accept ownership
Maintenance can be tricky. Maybe you’re dealing with third-party vendors. Maybe your data center’s backup generator ran out of fuel. Maybe you just didn’t account for weird edge cases. But here’s the thing: it’s your maintenance and they are your customers. Own that.

My property management company, again, didn’t do this. After getting that coldly factual email I replied to say, essentially, “That’s nice but my point about proactive communication stands.” Had they followed the previous rule and acknowledged their impact then we wouldn’t have gotten to this step. Instead they said:

Sorry Andrew. We were assured by the testing vendors that no units would be affected and therefor did not send out a notice.

Well that’s nice. Didn’t end up meaning much, did it? Passing off the impact you have on customers to a third-party doesn’t divorce you of responsibility. When you avoid taking ownership you convey to customers that you’re not really invested in their success. You know you had an impact on their work. But you’re choosing to just sort of go, “Eh, but it wasn’t really our fault.” When you do this you offer no reassurance that this maintenance problem won’t happen again. And again.


When it comes to maintenance, communication is key. You need to keep your customers aware. You need to acknowledge when you have an unintended impact on their day. And you need to own your role in causing that. When you don’t do these things your customers are just pissed off. And worse, they’re doubting you. Because if you can’t communicate well around routine maintenance then why should they trust you to communicate well around more important matters? They shouldn’t.

Asia-Pacific Hiring

One of our big goals at Automattic is to cover support 24/7. Our customers span the globe and we want to always be there for them. Since we’re distributed that means we also seek to hire great people from around the world.

Hiring like that helps us be around 24/7 without necessitating graveyard hours. And right now we’re keen to hire more team members throughout Asia-Pacific.

As part of that Deborah and Pam from our hiring team will be in Australia and New Zealand next week. If you’re interested in Automattic or if you just want to chat about how we handle support you can find them in a few places.

They’ll be in Sydney March 8th and 9th, including at the local WordPress meetup. Then they’ll be in Auckland, NZ from March 10th through 12th, including at the local WordCamp. And finally they’ll be in Melbourne March 13th and 14th where they’re hosting a local event.

And if you’re in Asia-Pacific and reading this, we’re hiring.

SUPCONF: New York

One of the things I’m most proud of from this year was helping to organize the first ever SUPCONF in San Francisco. I spoke about how to build a career in support and helped plan pieces of the event. It was amazing to see a Slack community come together in-person and connect.

Later this month we’re holding the next SUPCONF in New York City. Over two days we’ll host speakers from Medium, SmugMug, Wistia, Help Scout, Automattic, and more. Beyond that we’ll have dedicated time and space to talk with other attendees.

That time and space for connecting with attendees was one of the things I was happiest with from SUPCONF SF. I think attendees walked out of the two days having gotten to know far more people than a traditional conference would have allowed for. A hallway track can be great for outgoing folks. Being intentional with how it’s organized, though, can give even those who aren’t outgoing the confidence to engage.

We also have many other events happening around the conference. From a pre-event cupcake social to a GIF battle to a hosted dinner and conversation there’s a lot going on.

If you find that interesting I’d recommend registering soon while there are still a few tickets left.

How to Provide Great Customer Support. Solid podcast episode from Hiten Shah and Steli Efti about customer support. Filled with lots of practical tips and distinctions.