Author: Andrew Spittle

Nicereply Podcast Interview

Craig Stoss and the folks at Nicereply had me on their podcast to talk about how we hire in support at Automattic. The episode’s a nice, focused 20-minute conversation about our hiring approach and philosophy. I’m a big fan of these short, specific podcast conversations; not everything has to be 60+ minutes!

One of our quirkier (yet highly effective!) practices is text interviews, which I wrote about earlier this year. Craig and I talk about that and more. If you’re interested in distributed teams, hiring practices, or any mix of the two, give the episode a listen.

And, of course, Automattic’s actively hiring in all manner of roles.

When customer service succeeds (and a pause)

As more of my writing energy flows toward work (82,000 words on our internal blogs this year) I find less for these posts. I have a half dozen drafts, but each resists my attempt to create better shape and quality. So rather than send half-baked ideas I’m going to pause my bi-weekly schedule of posts. Call it a summer vacation of sorts.

This week, instead of a post, I’d encourage you to read this Seth Godin post from 2015. It remains one of my absolute favorites about customer support. The core of his idea is that:

Customer service succeeds when it accomplishes what the organization sets out to accomplish.

This also means that when we do something new we have to think about how it supports our organization’s goal. Impact comes when new ideas match a company’s definition of customer support. This is as true in strategy as it is in individual support replies. No matter our role, our work is better when we connect it to what our organization sets out to accomplish.

No tactic, approach, or strategy is true for all (or even most!) teams. But that also means we can learn from organizations that take steps we would not. Instead of brushing off an inapplicable idea, learn to ask why it works for some other company. If it won’t work for your team, try to figure out why it’s successful for another.

The Best Service Is No Service

As hard as it is to remember, support teams need to reflect on why customers have to contact them at all. That’s often easier said than done as day-to-day pressures encourage a heads-down focus on the queue. The risk is that you might optimize for work that never needed to happen.

This is why I find so much worthwhile advice in Bill Price and David Jaffe’s book, The Best Service Is No Service. The authors present a vision for support that goes beyond that day-to-day, heads-down view. The book is loaded with guidelines and anecdotes, and each time I read it I take away something new.

Price and Jaffe start from the premise that people don’t begin each day hoping to contact support. This seems obvious, but it’s a reality that companies often overlook. That oversight shows up when companies focus on what a customer needs help with rather than why they need help at all. The authors put forward a clear goal: create an experience that’s so great customers don’t have to contact support.

It takes many pieces working together for that to happen and the authors outline seven key principles. For anyone leading a team, these principles will help you think about how support can partner with teams across the company. While I find some of the specifics too prescriptive, it’s nonetheless a framework that helps me examine my own assumptions and learn where our team can improve.

Early in the book they outline three categories of customer requests. These are what the authors call “dumb” contacts—those emails, chats, or phone calls that could have been avoided:

  • Customer interactions caused by the company. Think of all those issues caused by unclear processes, poor products, or long delays.
  • Customer interactions caused by support. Often these are mistakes which cause a customer to contact support again.
  • Customer interactions that are easy-to-answer. These are all those questions that take just a few seconds (or a script) to answer.

In my experience, and in many of the anecdotes they share, these three categories catch tons of issues that customers face every day. Fixing them often just takes an update to support docs, or an improved email template, or a similarly quick next step. That quick payoff is a great place to start as it helps build the trust and habits that let a team tackle more complex issues.

One of my all-time favorite examples of this kind of work comes from Dan Heath’s book Upstream. In a lot of ways it’s a less structured, spiritual successor to The Best Service Is No Service. In the first chapter of Upstream, which is also available on Medium, Heath relates how Expedia realized almost 20 million calls a year came from customers who just needed a copy of their itinerary. Wowza! They got a team together and after quick, basic improvements went from 56% of customers contacting support to just 15%. Talk about dramatic results.

A common thread in both Upstream and The Best Service Is No Service is that great service depends on more than just the support team. To make progress on those three categories I mentioned earlier requires involvement across company leadership. That’s not easy, but Price and Jaffe’s book provides a number of clear, practical suggestions. It won’t do the hard work for you, but it will give you the language and examples that help your team create a great customer experience.

When Snippets Aren’t Enough

Great customer support balances personal attention with efficiency. There are times to tailor a reply to one particular customer just as there are times to send a quick snippet and move on. What’s tough is knowing which approach to use in a given situation.

I think of it as a matter of education versus process. If I need to teach a customer, I use a highly personal reply. If I need to share a process, then a snippet works just fine.

Snippets are great for process-oriented questions that follow a common pattern. It’s easy to fire off a helpful, standard reply once a customer simply has to take certain steps. Something like how long it takes a refund to go through or what steps a customer must take to close their account are a perfect time to use simple, consistent snippets.

Educational replies, though, aren’t well served by snippets. The problem is that a customer has yet to understand some key concept and turns to support to teach them. The gap can’t be closed in the same way for each person. If I just look for a common pattern and send a preset snippet I don’t reach the customer where they are. My job in support is to figure out how the customer thinks of the situation and relate things in a way that helps them build confidence.

When teaching a customer I need to pay attention to things like terminology and the level of detail I go into so that I write in a way they’ll understand. If I overwhelm them with details or make something sound technical and complicated, I’ll lose them. The same can happen if I’m too brief in a situation where they need more detail to relate to. It’s all about connecting my reply to where they’re coming from.

Sometimes this means relatively simple things like mirroring a customer’s language for a common term. It can also involve providing a metaphor or way of relating the new information about our product to something they already know and feel confident about. Or it can be as hands-on as writing out a sample message they need to send someone like their ISP who has to fix the issue.

Those steps add an important level of personal attention into a reply. Efficiency has a role to play, too, and snippets can be a real boost. But if you go through a queue matching pattern after pattern you quickly lose sight of the people on the other end of your responses. Much of the time they need help that’s more than just a process to follow, and that’s best accomplished with individualized care.

Slow Follow Up

Live chats start fast but often require follow up emails to resolve. That follow up doesn’t have to be so fast. It can happen tomorrow.

This is easy to overlook. Chats ping-ping-ping and create this latent pressure to follow up rightnow. Many issues aren’t time-sensitive, though, and good follow up can take time. You shifted to email to create that time, so it’s best to avoid adopting a false sense of urgency.

It helps to create space for follow up emails by blocking out time in each day’s schedule. This helps you stay in the flow during chat shifts. It also creates a simple decision point: Do you have time blocked out later in today’s calendar for follow up? If so, you may be able to follow up later today. If not, tell the customer that they’ll hear from you tomorrow.

When you set aside space for follow ups you give yourself room to breathe. Live chat shifts will no longer, one follow up email after another, steadily eat into the surrounding hours. Instead you’ll have time to focus and make sure you see the entirety of a customer’s journey.

Some customers inevitably won’t like this. And you shouldn’t delay just for the sake of moving slow. But when a slower pace is required it helps to give the customer some homework. There’s likely more than one task they were working on, especially if your product involves building something. Gather pointers and suggested next steps for them to work on while you and the team figure out how to resolve their earlier issue.

The next time you have a live chat that needs to shift to email, pause. Don’t instinctively commit to fast follow up. Instead, ask yourself if it’s required or whether a slower pace is best.

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.

Reading Notes: March 2021

Each month’s reading leaves me with scattered notes that don’t quite, by themselves, make up a blog post. I hope to gather these and give them some sort of shape as a thinking out loud exercise.

In March I read 8 books, from young adult fiction to academic history (which is pretty typical for my eclectic tastes). I find genre shifts help me stay more engaged and read with closer attention (though it could just be I’m easily distracted by new avenues of thought). I keep my reading list up to date in case you’re curious for the full list.


One thin, practical book I tried to absorb as much as possible was How to Take Smart Notes by Sönke Ahrens.

Ahrens’ premise is that notes are the starting point for writing and it’s through writing that we learn. The system he describes draws from the work of Niklas Luhmann, a German sociologist who wrote at a prolific pace. The basic idea is to write short, individual notes, review them daily, and file them into a system (analog or digital) that creates connections between notes. Those connections help us deepen our understanding and explore topics in greater depth.

This inverts the typical writing process, or at least how it’s taught. Instead of starting with a topic and constructing a reading list and questions from there, you start with reading and out of that generate topics and questions to explore. If you do this well you shift from not knowing what to write about to having too many topics to choose from.

Ahrens’ also suggests that writing creates distance between us and a book. He describes how this distance is required in order to think about an argument instead of just within that argument. Notes and the writing they lead to become not a record of our thought but our thinking itself.

It’s a book I wish I read while still in college. Even outside an academic context, though, I found it valuable and have been tinkering with Obsidian to see how I can implement its core ideas.


In a different genre, Lloyd Alexander’s Westmark trilogy is a delightful set of books. His Chronicles of Prydain holds fond childhood memories. But, somehow, I never got to Westmark.

What I find so enjoyable about the series is its constrained ambition. It’s not a story of existential struggle for humanity; it’s just fun, with well-developed characters and a concise plot. The trilogy has this lightheartedness that lets you enjoy its world for a moment.


I also read two in-depth history books: David Abulafia’s The Great Sea and Peter Turchin’s War and Peace and War. It’s fun to pick up small anecdotes within these larger histories. I often imagine the author’s joy at unearthing some obscure, humorous detail in their research.

The Great Sea is a history of the Mediterranean through what took place on its seas. Among impeccable research and detail is this gem:

In 1599 the Venetians were so exasperated by the Uskoks that they sent a cargo of poisoned wine into Uskok-infested waters, let it be captured, and hoped to hear that the Uskoks had all died from drinking it. Since they remained full of life, however, the ruse obviously failed.1

Imagine being assigned to crew that ship. You wonder what happened to all the poisoned wine and what Uskok conversations were like as they headed back to port.

Or, from War and Peace and War, there’s this description of Elizabeth I’s creative taxation (slash rebellion suppression) system:

When one of her subjects became too wealthy, she invited herself to his castle along with her whole court. After some weeks of dining and wining the queen and hundreds of her followers, the unfortunate host was financially ruined for many years to come, and was too busy paying off his debts to contemplate rebellion.2

That sounds like a gentler approach than Elizabeth’s predecessors, Henry VII and Henry VIII, who would simply kill landowners who got too wealthy.


My reading lists3 remain a mess, but I did add 4 books in particular that I look forward to reading. Through The Long Now’s excellent Seminars About Long-term Thinking I found The Optimist’s Telescope and More From Less. Both Bina Venkataraman and Andrew McAfee gave excellent talks as part of the seminar series. And from Marginal Revolution I added Walter Isaacson’s The Code Breaker and Tom Zoellner’s Island on Fire, which covers an episode in Jamaica’s history that I know nothing about.

  1. Abulafia, David. The Great Sea. Oxford University Press, 2013, pg. 457.
  2. Turchin, Peter. War and Peace and War. Plume, 2007, pg. 272.
  3. Lists are one of the least-functional aspects of Amazon’s empire. They’re so basic and, at times, illogical it merits its own post.

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.

Not Everyone Contacts You

Only some customers ask for help. Many love the product, find it intuitive, and go about their merry way while others are so lost they give up and never bother to get in touch. No matter how busy the ticket queue gets, it doesn’t represent all customers.

This makes any support-driven definition of customer sentiment only one (important!) piece of a larger puzzle. Without a reference point it’s difficult to make meaningful.

If you lead a team, you want them to understand their work in context. The most important thing from support’s perspective may be minor in the overall customer experience. Alternately, what can feel like a flood in the queue may indicate a deep fault line that needs repair. The key is to provide balance, and there are three steps you can take.

Track the percentage of customers who contact support

The size of a queue or a given week’s volume isn’t inherently useful. A backed up queue could be the sign of a growing business. Hundreds of complaints could be a tiny portion of customers. It helps to compare support interactions with the wider customer base. This provides a reference point for understanding the nuance of support load.

To start, track the percentage of new customers who contact support 1, 7, 14, 21, and 28 days after signing up. A multi-stage timeline indicates how often new customers have immediate questions and how those build over time.

As one example, maybe 10% of customers contact support but 90% of those contacts come within the first 24 hours of signing up. That’s a good indicator you need better onboarding and new user help. Alternately, perhaps only 3% of customers contact support but the company has a real issue with churn. That suggests a need to connect with more customers and, at the very least, figure out what’s lacking about the product.

As a nice side effect, this can act as a planning framework. Not only will you understand the current balance of customers who need help, but you’ll be better able to plan for future changes in the business. This kind of data shows roughly how many new customers lead to how many new support interactions, which helps you anticipate hiring needs and more.

Invite the product team to highlight all that new features can do

Support teams can focus on bugs and lose sight of what’s improved. After all, the queue is not usually full of customers who just want to say they liked a change. Over time this focus on all that’s broken can drain morale.

It helps to give product leadership a space to showcase the positives, especially when that comes prior to launch. A town hall or demo session creates a balanced relationship and focuses the team’s energy on progress rather than problems. It’s also an opportunity to ask questions ahead of time, which prepares the team to support things post-launch. Shortly after any launch you want to remember what’s improved, and without a reference point back to the product’s wider progress it’s easy to get stuck thinking nothing ever changes.

Celebrate what customers accomplish

Some customers who need help nonetheless make stellar use of a product. Often that success comes after they contact support, which makes it hard to see the connection between their support interactions and later accomplishments. But it’s that connection which reaffirms the value of each interaction; any one email may be the key that helps a customer reach their goal.

When possible, highlight these customers for the support team and wider company and focus on what each achieved through the product. What’s valuable is less about how they used certain features and more about the overall aims they accomplished. These are a good reminder of why the support team’s help matters and the type of impact it has on people. Even when a queue is full, good things arise through solving those problems.

A reminder

At any point, some portion of customers will need help as a result of poor design, engineering bugs, or marketing confusion. The ability to resolve those questions with grace is both the job description and job security of a great support team.

It’s all too easy for a team to overly focus on those problems and lose sight of accomplishments. It helps to add perspective, showcase the positives, and find the success stories. These strategies restore balance to the daily work of support which makes the work sustainable. That balance is a reminder that there’s more to how customers use the product than just what comes into the queue.

Stormy Feature Rollouts

Ever change a design or launch a new feature that your customers just hated? It’s not fun! It pushes you back on your heels and makes you rush to justify the decision. Customer after customer complains about the same thing and in response you churn out rote explanations of how they can adapt and why the new way is better.

The problem is that those formulaic replies prevent your team from learning more about where customers struggle. It’s better to restrain your desire to explain the new feature or change in design and instead keep a curious mindset. Use that curiosity to ask about how the customer used to work and what they now find difficult. Lean on cues they mentioned in their message (or rant!). As one brief example:

I realize the editor’s new line spacing is frustrating for poets like yourself. Could you tell me more about how you used the old editor? I’d love to better understand your writing process as it may help our team reconsider how this works.

Your phrasing needs to give the customer an opening to talk about their positive experiences in times past. Not everyone will take that opening, of course, but it helps to make them feel heard right away. Echo their language back to them. Show that you’re listening and curious. And then ask open-ended, inquisitive questions that get them to share more about how they used the product in the past.

The goal is to not get bogged down in their frustration with the new design. You can always detail what their options are once you better understand how they expect things to work. You want to encourage a conversation about why this change made things difficult. You want to learn not just what the customer dislikes about the new version but what they loved about the old version. This will help you relay customer feedback back to your product team because the best products are those people love to use, not those they don’t hate.

As with so many things, this is easier said than done. And, yes, some customers are just going to vent. That’s okay. That’s where those formulaic responses can lend a hand, especially if you are swamped under a growing backlog. It’s still worth the effort to find those handful of customers who give you an opening. When you find them, it’s worth investing in some individualized conversations to understand your customers’ point of view.

As you talk with more customers, you build a model of how this particular change impacted them. That understanding is crucial for your product team. Knowing that many customers are unhappy isn’t actionable. Knowing that many customers are struggling to adapt because this new design complicates a common workflow is actionable, insightful gold. That’s fertile ground for the next design iteration.