Tag: writing

Control the Conversation

It’s difficult to feel in control of a live chat. It feels like more of a face-to-face conversation than email, with each message exchange feeling instant. This immediacy creates a close connection to a customer that can make it harder to keep a conversation productive. Bow to this immediacy and you lose control and, with it, the ability to create a great customer experience. You’re now just along for the ride and hoping it ends up somewhere positive. What you need is to control the conversation and remain that confident expert guiding things to a resolution.

In my experience, chat goes sideways if the pace hits an extreme. Once things move fast they can end up off track. While it’s vital that support (not the customer) control the pace, that’s hardest when a chat moves fast and in short bursts. There are a few steps that help.

First, remember that you don’t have to engage with everything. In quick exchanges a customer’s raw frustration can come through. This often includes colorful language directed at you, the product, or the company. It’s best to just let this stress pass. You don’t want to admonish the customer for their tone. That only escalates things. Instead, stay in control (of both the conversation and your emotions) and remain focused on the task at hand, which is the only part of a message you need to engage with.

It’s also important to be deliberate in your phrasing. Short, fast messages can be sloppy. Clear, direct writing helps you keep control of the conversation; lose that clarity and all bets are off. A common mistake is to pose a question that’s intended as a statement or direction. As one example:

This is going to take me some time to dig into. Do you mind if I follow up with you later by email?

I asked that once knowing it would take over 30 minutes to sort out and had a customer respond, “No thanks, I’ll wait.” Not great! Instead, be decisive when it’s called for and if there’s a direction for how things need to go, just say so.

One way to do this is to create a shift in context. Once a live chat is off the rails it’s unlikely to go back to a productive conversation. This is when email comes into play. But for a shift to email to work you have to be firm; make it a decision rather than a hopeful question. It can help to be self-deprecating as that gives the customer a sense that they’re being escalated. Next time you’re lost, feeling stressed, and juggling a customer who simply cannot understand why it’s taking you this long, try something like this:

To be honest, I’m not sure what’s wrong here. It’s a bit of an odd case. Let me check with the rest of the team and figure out what I’m missing. I’ll follow up with you by email later today.

That buys you time and gives the customer a sense that they’ve been escalated to the pros. Your pride may take a hit, but try to shrug that off and move on. Plus, it’s easier to learn or figure something out when you don’t have an impatient customer pinging you for an update every 2 minutes. The chat was no longer productive, but at least you controlled what the next step was and are now on a path that lets you best help the customer.

Emotion is often what accelerates chat. Confusion, anger, and uncertainty can all cause messages to fly back and forth. The customer wants an answer now. You need a few minutes to compose yourself or figure out the root of the problem. The most important thing is to not leave yourself to the whim of a customer’s feelings and emotions. Understand that you can, and should, control the conversation.

Worthwhile Documentation

Detailed support docs are not enough. If they were, our queues would be emptier. A good doc builds a customer’s confidence and helps them find clear, approachable answers. They won’t find that, though, if we don’t make documentation seem worthwhile.

Any customer who contacts support is motivated to solve their problem, but that doesn’t mean a simple link will be enough to draw their attention. A support doc still has to sound compelling. And yet too often our replies tack on a link to documentation as an afterthought.

To make a doc sound worthwhile, focus on the words right before a link. I know I’ve sent many a reply like, “You can read more about this here…” with a link. That sounds superficial and ignores important context and direction. My job is to give the customer a look at what’s inside the doc and how it can help them—but a minimal reply like that does neither.

It helps to think about what the doc contains that I couldn’t just copy and paste into an email response. Here’s an example that makes it sound more worthwhile:

There’s a lot more you can do with this feature and our support doc covers all the details. That link takes you through everything and includes screenshots to help you find each step and get it set up exactly how you want.

That reply is longer, but it puts more energy behind the link. The customer gets a thorough nudge and greater confidence this is information they need to know. They can see documentation as more than just a dry manual and have a hint that it will help them be more effective. Manuals are off-putting while a good support doc helps someone learn and build confidence.

It’s extra special if you can include tidbits into some docs. If a feature’s key to the product, document a couple (brief) case studies or next-level steps. With those included you can add something like,

And check out the bottom of the page for tips from some of our largest customers about how they use this feature. There’s good advice in there that can help you avoid common mistakes.

This takes a support doc from simple help material to something more like educational marketing. It shows a customer not just how to configure a feature but how to thrive. That may save you another email from the customer later on once they’ve mastered the basics.

There’s, of course, much more that can be done with documentation. To overhaul a set of support docs can be a mountain of work that takes weeks or months while improving our own replies is work we can start today. There’s no development time required nor any software to integrate. It’s something each team member can tinker with and learn. Customers are willing to spend more time with docs once they know it’ll be worth their while.

Match the Situation

Years ago I emailed Zappos support because I made a mistake in a product review and wanted to correct it, which wasn’t possible on the website. My email was two quick sentences. The response was 5 paragraphs, most of which were unrelated to my question, and it buried the answer within a middle sentence of the third paragraph.

This approach can ruin a customer experience. A great support interaction matches the customer’s situation and mindset. Great support is tuned to a customer’s particular context and avoids relying on a simplistic routine since routines, while efficient, can often miss what’s really happening. There are three common examples I like to think about that help make this idea concrete: simple questions, rambling stories, and lists of questions.

Simple questions

Plenty of support interactions don’t require deep, careful investigation nor a precise tone. Some customers just have a simple question that you know the answer to. They’re in search of the missing puzzle piece and it’s your responsibility to provide as clear an answer as possible.

Yes, you may want to build rapport, prove you’re not a bot, or draw the customer’s attention to something which benefits them. That’s all fine, but it’s not what the customer asked. Leading with any of that information puts the focus on what you want, not what they need.

When confronted with a simple question I make sure the answer is the very first thing in my email. This builds trust as the customer knows their needs are my priority. Plus, it can diffuse a customer’s confusion or frustration since the first thing they read solves their problem. Once you solve their problem they’ll be a lot more inclined to listen to what else you have to share. No customer should have to read through a multi-paragraph email to find the part that answers their straightforward question.

Rambling stories

Eventually every inbox gets a rambling email that takes you on a journey. These are those stream-of-consciousness recreations of what the customer was doing whenever they ran into trouble. For better and for worse you have all the details; your goal, no matter the story, is to zero in on what’s relevant.

Often what starts as a long story only gets longer with each reply, so focus is important. It also helps to be patient; don’t pressure yourself to engage with each plot twist. Just find where the customer is stuck and reinforce the next steps they can take. Their story is also an opening to be personable. Don’t force it, but often you can find a nugget within the stream that helps humanize your service.

One way to approach these long-winded messages is to selectively quote from the email. Maybe the full note is 2,000 words. That’s ok. Pull out the three or four sentences that get to the heart of their question and either echo that language back to the customer or quote it inline in your response. It’s a gentle way to bring order to their rambling and indicate where you’re focusing your attention.

Lists of questions

Every once in a while you get an email that’s just a long list of questions. Often they’re numbered but sometimes they just run one right after the other in a big, epic paragraph. These are tough. No one wants to write out answers to 20+ questions and I’d bet few people truly want to read such a lengthy response.

When confronted with a long list of questions the challenge is to guide the customer to what will best help them, even if that doesn’t fully address each question in their list. Think of the themes that connect all their questions and find a way to start them on a path toward confidence and self-sufficiency. Their questions likely tell you a lot about their goals and you just have to nudge them along.

This is where guides and getting started tutorials are useful. It’s best when you can help the customer enough to get started while connecting them to a resource that will carry them the rest of the way. If you can’t help them make that step you’re bound to get another list of questions next week.

Wrapping up

The last thing you want is to slip into autopilot and churn out replies based in nothing more than habit. Sure, macros and predefined replies have their place but even those are best when they’re flexible enough to be customized to the situation. Guidelines like what I describe above help avoid the tendency to fall into routine and keep the focus on the customer.

Each of the three approaches above come from a common theme: the best support is tailored to the individual customer. No individual response is the categorical Best Response for every interaction. It’s all about how you gauge the customer’s own situation and deliver them a response that best matches what they need.

Plan Ahead and Speed Up Email

The gift and curse of email is its delay. It gives you space to solve a customer’s issue but extends a customer interaction across days or even weeks. It’s important that your replies help a customer move forward. And your very best replies help them resolve everything in just one or two responses.

I’ve found the best way to do this is to ask myself: what will happen if my suggestion doesn’t work? Even when I’m certain in my suggestion I consider what will happen if I’m wrong. I never want to put a customer in a position where all they can tell me is, “That didn’t work. Now what?” This puts us back at square one, introduces more delay, and leaves the customer waiting on me.

If you plan ahead and enlist the customer in your process you can avoid this situation. This can help you speed up the flow and prevent the customer from feeling stuck. There are two main approaches that help.

Think Conceptually

Part of your role in support is to teach a customer new concepts. These can range from how a feature works to the location of a browser’s address bar. When learning one new concept it’s only a short jump to learn other adjacent ideas.

For example, if you suspect a browser issue and direct a non-technical customer to clear their cache and cookies, consider if the console output or network details will also help. They’re already venturing into the great unknown of their browser settings so make sure you get the most of that. This helps you rule out their browser in one step so you don’t go through individual causes piece-by-piece. Here’s one example:

Thanks for those details about what isn’t working for you. A browser issue is the most likely cause in these situations; things can get stuck and lead to all sorts of odd behavior. There are a couple steps I’d like you to try that will help us rule this out.

1. Clear your cache and cookies and try reloading the page. We have a help article that explains how.

2. Check your browser console for errors. This one’s a little tricky, but we have instructions that show you each step.

If you see any errors in your browser console please copy those and let me know what they say.

This presumes that you have clear help articles for those two steps (if you don’t it’s a good reminder to add one!). The idea is to put the customer into an exploring mindset and combine similar requests. If neither option works, you ruled out both common causes in one reply, saving you and the customer time. And because you planned ahead and connected similar concepts it eased the customer’s experience, hopefully boosting their confidence in both you and themselves.

Think Sequentially

We all make heavy use of documentation in our support replies and often those help articles cover an involved series of steps. It’s a mistake to send that to a customer without first thinking about how they might struggle.

When you send someone to a multi-step support doc they can end up stuck or lost, which is why it’s important to guide them on what to do in that case. When you do this well you can get them back on track and avoid the dreaded, “That didn’t work.” response. As a brief example:

This is a great question; it’s one we hear often. We have instructions on what to do in our support site. There are 12 steps outlined, which I know is a lot, but each one has a screenshot to help walk you through what to do.

Can you try those steps and let me know how it goes? If you get stuck, no worries! Just let me know which step you’re stuck on and what you see at that point. It will help me figure out where things went off track so that we can get this all fixed up for you.

This kind of message increases the likelihood of a response like, “I got all the way to step 6 but when I got there what I saw didn’t match the instructions. Instead I saw…” By acknowledging that the customer may get stuck somewhere in the sequence you help them feel less lost as they always have your backup step. That step will still feel like progress. Plus, you will occasionally get an immediate pointer to where your documentation is out of date or less clear than you first assumed.

Final Touches

When you bring the customer into your process like this you create a smoother and more responsive experience. Gone is the one-step-at-a-time debugging that can lead a customer to feel like you’re guessing. In its place is a more considered approach that ties concepts together and moves in sequence.

The last thing you want is for this to feel like extra work, so be selective in what you ask of someone and only request the most relevant next steps. Don’t throw half a dozen things into one reply. Be deliberate and ask yourself what next piece of information you’ll need if this doesn’t work. Every customer’s time is valuable and the more you speed up email exchanges the better.

Finally, as I tried to show in those examples, remember to (briefly) explain why this information will help. It’s best to connect that to the customer’s own best interest, since customers will take an extra step if they trust it means a faster resolution. Email will never compare to live chat or a phone call for speed, but if you plan ahead you can significantly cut down on its inherent delay.

Expectations of Ease

When we set expectations we create a framework for how people experience our product. If we set different expectations, the same result can lead to a meaningfully different overall experience. The experience of using our product is as much about how it feels as it is about the end result.

We set a high bar for our product to live up to when we call something easy to use. That frustration you feel when assembling a why-is-it-this-&%$#@-hard piece of IKEA furniture is real. And part of it stems from the very fact that you bought the IKEA version because you expected it to be quick and easy.

Setting an expectation of ease often feels like a good idea as we rush to reassure a customer and try to provide lost confidence. Instead, we set someone up with a dangerous expectation: that new feature is easy to use, the task is quick to complete, the workflow simple to figure out.

What’s really behind an expectation like this is a baked in set of assumptions about how people use our product. We assume that someone can devote their full attention to the task, that they’re not unduly pressured or stressed, or that they’re comfortable embracing a level of uncertainty while they figure out a new or challenging product.

Attention, stress, and uncertainty. All things that have changed in this year of strange years. It’s a good reminder to re-evaluate our approach. No matter your product, your customers today likely aren’t at their best.

So what can you do? First, be cautious about setting any expectations of ease. Instead just focus on the fact that something can be done, you don’t have to qualify it as easy, quick, or simple. Second, ensure the customer knows it’s okay if they don’t get it. You want to keep them connected to you so you can learn when they’re stuck and lend a hand. Finally, review all those text snippets you rely on. You may be inadvertently sending things out of habit rather than out of their relevance for the person you’re helping today.

There is a fine line here as we shouldn’t discourage people. The right approach isn’t to under promise by setting a mundane task up to be a labor of Hercules; nobody is that much of a hero. We just need to help people feel confident and in control. We need to listen to where people are today and help them move forward, even if that isn’t easy.

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.

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.

Being Customer Supportive. Great collection of practical customer support advice from Elizabeth Galle.

Stop apologising

When there has been a deliberate change though—one that is important for future development and that almost certainly won’t be changing back—then that sort of apology can be counter productive. If you know that a feature has been removed and is gone for good, it’s unhelpful to offer false hope to a customer of “recording your feedback” and “voting for that to be returned”. It will probably never happen.

Stop apologising to customers and start leading them – Mathew Patterson.

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases WordPress.com users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.