Kristin wrote about our efforts to achieve 24/7 support, and it reminded me of a project I worked on last year. When we started talking about expanding the support team to improve our coverage outside of US business hours, David asked me to take a look at what we’d need to do to achieve a response time of under four hours for every case that came in, and related to that, what response time we could expect with each hire.

Framing the problem

When we talk about “response time”, we’re really talking about about one specific measure—the time from when we receive an email until we send an initial personalized response back (we stopped using autoresponders over a year ago, so every response we send is personalized). That encompasses exactly what we can control — how long we let a case sit in the queue and how long it takes us to answer. We exclude emails that don’t result in a reply (vacation messages sent to us in reply to invoices, spam, etc.), but otherwise include every single email in measuring our response time.

When we look at response time, we usually look at it one of two ways:

• Median, 95th percentile, and max response time: the point at which half, 95%, and all cases are answered by, respectively.
• Service level: the portion of cases that we reply to within a given time period.

So the goal that David was asking about can alternately be framed as a max response time of 4 hours or a 100% service level at 4 hours—they’re interchangeable.

There’s a really simple mathematical answer to “what do we need to do to ensure a max response time of no more than 4 hours”: at a minimum, you can’t have any gaps in scheduling that are greater than four hours. In reality you need a slightly smaller gap to actually achieve that service level, because after any gap in coverage you’ll come back to find a queue of cases, but at a minimum, there’s no way you can do a four hour max response time if you have a gap in coverage of more than four hours.

That’s a pretty easy and straightforward answer, and gives you a pretty clear idea of how you need to grow the team: hire such that you can make a reasonable schedule for everyone that doesn’t leave any gaps of more than four hours.

That didn’t answer the question of what we should expect in terms of response time as we grew the team over the course of many months, so for that, we moved to a simulation.

Simulating our support workload

Continued…

It’s been a big year for our support team here at Basecamp, as Noah wrote last week. We’ve gone through lots of change and added several more people to the team.

Back in 2012, a few of us began working swing shifts to help clear the queue for the morning staff. Emily also started working Sundays to make Monday easier on the team and clear out some older cases from Friday night and Saturday. While the majority of our emails come in during traditional US business hours, we all know that work doesn’t necessarily happen between nine and five (for example, I’m writing this at 9pm PST). When we saw how well the Sunday and swing-shifts worked, we hired Jim to answer emails in Manchester, UK. That covered our butts from 2am-9pm CST, leaving only 5 hours of unanswered emails Monday through Friday. That doesn’t seem like a lot, but five hours can feel like an eternity if you’re locked out of your account or have a worrisome billing question. Shortly after we hired Jim, we decided to grow the team to include Natalie in Berlin and Chris, also in Manchester.

Fast forward six months to a few weeks after we launched our phone verification feature, when DHH was traveling and didn’t have cell reception on a Saturday. He was essentially locked out of his own app. Saturday, however, was the one day we didn’t have someone answering support emails. When DHH couldn’t log in to Basecamp on a Saturday in a timezone far from HQ, he felt the pain lots of our customers have felt. We decided to make a change to how support works.

I wanted to hire four new people to cover the world around, but DHH wanted me to hire no one and finagle the schedule with our existing staff [insert trollface here]. We settled on a compromise: If we hired four newbies, then we had to also implement phone support, such that we wouldn’t just have a big surge in employees (from 8 to 12: a 50% increase) without also expanding the scope of work. We opened four new positions: US Saturday-Wednesday, EU Saturday-Wednesday, Asia/Pacific Monday-Friday, and Asia/Pacific Saturday-Wednesday. While we searched for these four candidates, the existing team took turns trading one full day of work for a 4-hour Saturday shift. After an exhaustive search, we found our newbies: JorDanée in Florida, James in Berlin, Tony in Sydney, and Sylvia in Hong Kong.

Meanwhile, Noah, our self-described (and self-deprecating) Data Monkey, built a simple call-back platform for our Support page. We started slowly and worked through a lot of in-house anxiety and assumptions around phone support: people get angry, people interrupt, people express frustration more easily, people yell. At first, Noah and I were the only people taking calls, and the call option was only available to account owners and administrators. Then, the rest of the team joined us. We started opening the call-back option to more and more users. Now, any logged-in user has the option to request a call from us Monday through Friday from 5am until 5pm CST, with the occasional wee hour and weekend option. (For the record, our users are as sweet as freshly grated palm sugar and super happy that we call them back within a couple of minutes, so that in-house anxiety has mostly subsided.)

You can check out Noah’s comprehensive summary of the support stats here, but I’d like to point out some stats to celebrate. We made a huge dent in email-response times this year, with the median time to response across the entire year falling to three minutes. For comparison, back in 2011 and 2012 our median response time for email cases was over two hours. Additionally, we’re now answering emails on weekends within six minutes on average, whereas customers would wait upwards of eight hours for a response before 24/7 email was implemented. In our first year of phone support, we averaged about 250 calls per month despite having millions of customers. The median call-back time is under three minutes.

Not a call center.

Many of us have been working together for nearly four years now, so we’re a close-knit group of diverse weirdos. The major anxieties that cropped up during these proposed changes were based in the fear of culture shifts; we did not want to lose the senses of freedom or autonomy that come along with remote work, and growing the team 50% meant introducing more (potentially not weirdo) people to our existing, comfortable culture. Every time you introduce a new person to a culture, the culture shifts a bit. While we’re happy to include more people on our team, we also know that we want to remain relatively small.

The biggest cultural shift was with phone support. We were a team used to writing emails to customers all day, not speaking with them on the phone. We all identify as writers and introverts, so the idea that we’d have to speak to people on the phone felt icky. There were lots of “I was hired to write, not to speak” and “I’m not comfortable on the phone” and “I refuse to work at a call center.” Once everyone started taking calls, those anxieties wore away for most of the team. (I now compare talking on the phone with my days teaching university English: it’s all a performance.) Yet, we still had to navigate working with people in a new, real-time format. People are complicated. They do get mad, interrupt, and yell. Those calls are hard. They make us feel helpless in a position where we’re meant to be helpful. After a rough call or email, our team is still here to support each other. We encourage each other to debrief those rough interactions and step away from work for a few minutes.

Phone support also inhibits some freedoms of remote work. While many of us work from our homes, there are times when we get stir crazy and want to venture off to a coffeeshop to work. We all know that it’s rude to take calls at a coffeeshop, so we cover for each other if someone wants to get out of the house just like we would if someone were sick or on vacation or having an off-day. A huge part of working a customer support job is supporting each other, and we’re getting better and better at that with each new challenge we introduce to our workflow.

We may still be a small team, but our culture has grown significantly this year. From a Jiu-jitsu’ing cat lover in Oregon, to a working Paleo mom who likes to #liveriveted, to a car-obsessed deadlifting vegemite-eating Aussie – we know that our small team still means everyone knows each other, gets each other’s jokes, understands each other’s work ethics, and most of all, trusts each other wholeheartedly.

2014 was a big year for Basecamp’s support team—we expanded our coverage hours dramatically and added phone support for the first time. Below is the summary of the year from a quantitative perspective that I shared with the team this week, reproduced here in its entirety.

Email case volume grew in 2014

We closed the book on 2014 with 123,350 cases, a 24% increase over last year (and just shy of the record setting 127k cases post-BCX* launch in 2012). Monthly case volume was pretty steady over the course of the year, with less of a summer/fall dropoff than we’ve seen the last few years:

Wednesday remains our biggest day for cases by a tiny bit, but we also saw a relative increase in Sunday cases this year.

U.S. mornings (up to about 2 p.m. UTC) continue to be our busiest time by far, and we actually saw a relative increase in mornings this year, with comparatively fewer cases coming in the afternoon.

Response time improved dramatically

In 2012 we had coverage during US business hours, roughly 7 a.m. – 6 p.m. CST five days a week; in 2013 we were doing a little better, with coverage 7 a.m. – 9 p.m. CST five days a week. This year we reached 24/7 coverage (with the occasional vacation).

Thanks largely to that investment in getting to 24/7 coverage, we continued to make a dent in response times this year, with the median time to response across the entire year falling slightly to 3 minutes. For comparison, back in 2011 and 2012 our median response time for email cases was over 2 hours. Even more significant is what happened to the tail—95th percentile response time fell from 16 to 2 hours.

Response time took an especially noticeable drop downwards in April when we started to add 24/7 support in earnest:

Not surprisingly, the biggest impact on response time was seen on the weekends, where we cut median response time from about 8 hours to 6 minutes. We made a dent on weekdays too, with median response time falling from ~10 minutes to ~3 minutes.

Those overall weekday response time improvements came largely from the addition of full overnight coverage, which has brought the wee hours response time to about the same as daytime:

Case types: more BCX, constant on-call load

The absolute number of on call cases (including both level 2 and on-call programmer cases) rose slightly this year to 5,805 (or about 22 per day, from 19/day in 2013), but relative to our overall increase in case volume on-call load fell by about 5% this year, thanks largely to improved tooling & root cause fixes.

BCX unsurprisingly makes up the biggest chunk of our cases, and that increased this year as Classic, Campfire, and Backpack cases each fell by about half in absolute terms. Absolute Highrise case volume remained almost exactly constant over the last year.

Accounting / billing issues are the single biggest category of cases that we receive, and increased the most dramatically vs. last year. We also saw a modest increase in the number of access trouble cases, while recording decreases in broken things/bugs and sales related inquiries.

Phone support

This was the year we added phone support, and we closed out the year at just under 3,000 phone support requests from customers. The median call waited just 39 seconds (and 5.5 minutes at the 95th percentile) for us to call them back, a wait time that many inbound call centers would envy, not to mention the fact that we’re doing callbacks! Calls clocked in with a median duration of 2.5 minutes, and a 95th percentile duration of about 10.5 minutes.

We saw pretty steady phone support volume over the course of the year, with changes as we changed the various places you could get access to the callback option.

Phone call requests almost exclusively come on weekdays from US & European customers, despite the fact that we offer it for parts of the weekend and overnights. Calls skew a little later in the day than cases do.

Other support projects this year

This was our third year of offering Twitter support, and we saw a modest decline in the number of tweets we sent out (to about 30/day, from 34/day). Tweeting is also a mostly weekday activity, and also skewed a little later in the day than do email cases:

This was also our third year offering webinar classes, and we clocked in at 102 classes offered in 2014, continuing our steady increases year over year:

Finally, we continued our steady march of making customers happier. 93.32% of Smiley responses in 2014 were of the “great” variety, a slight increase from last year:

---

All in all, a great year! We handled more cases while improving response time dramatically and holding the line on customer happiness and on call volume—a job well done!

* I refer to the new Basecamp launched in March 2012 as “BCX” throughout this post.

Basecamp can’t be everything to everyone — when you err on the side of simplicity, you have to say no a lot.

But when customers take the time to explain what they’re looking for and ask whether it’s possible, we want to give them something other than “nope, sorry!” So we end up suggesting a number of workarounds. Here are some of the most common.
To-do templates
Users sometimes miss the to-do list template feature from Basecamp Classic — the new Basecamp has templates, but not to-do list templates. So we suggest the following:

1. Create a new project template that includes the to-do list you want to be able to reuse
2. Create a new project from that template
3. Move the to-do list into the project you need it in
4. Delete the new project you created from the template.

The Email-In feature also lets you add files, discussions, and to-do lists to your project via email. So you can also keep a draft email with the to-do lists you want to re-use, and email it to your new project.
Sometimes folks have already created a project, but they want to apply a template to it. They can use the same create-a-project-from-a-template/move-things-over/delete-the-new-project process to add content from the template to the existing project.
File versions
This is another popular request from customers, especially those who were familiar with Basecamp Classic. That’s something we’ve explored for the new Basecamp, but at this time there still isn’t a way to upload multiple versions of a document.
In the meantime, you can upload the original file like normal to the Files section. The revision to that file can be uploaded as a comment on that original file (along with any notes about the new version). This way, you keep the original file and the latest version is always in the most recent comment.
Moving a single task from one project to another
You can move whole to-do lists from one project to another, but there’s no way to copy an individual task from one project to another (since Basecamp doesn’t know which destination list to put the task in). But you can:

1. Create a new list in the original project
2. Drag and drop the task into the new list
3. Click the new list’s title, then use the Move feature to put it in the destination project.

Assigning a to-do to more than one person
There’s currently no way to assign a to-do to a group, because users have different preferences about what should happen when the task is complete. Should every person to whom it’s assigned have to check it off? Does only one person need to, for it to be marked as complete? We’re still unsure how or whether to approach that one.
So for now, the best solution is to leave the to-do unassigned, then add a comment to it. In the comment, you can notify all the people who need to be involved.
Sub-projects and sub-tasks
People sometimes ask for a way to list multiple small projects under one larger one, or break a single task into multiple smaller ones. For simplicity’s sake, there’s only one level for projects and to-dos in Basecamp, but there are other ways to organize and prioritize them.
For groups of projects you want to keep together, we recommend using a common preface or emoji. For example, we use “BCX” to name any project that relates to the newer version of Basecamp (“BCX: Android”; “BCX: Support”), which helps us group all those projects together for quick reference. (Check out this video for other project organization ideas.)
And while there are no subtasks, you can add a comment to-do, in which you can outline everything the to-do entails. This video does a pretty great job illustrating all the ways you can organize to-dos in Basecamp.

In some cases, we get enough requests that we ultimately make a change. That was the case with Google Docs, Client Projects and the majority of the improvements we’ve made to our products over the years. When the same issues crop up again and again, it forces us to take a look at how things work, ask if there might be a better way, and take the time to fix it.
Do you use any workarounds in Basecamp? Let us know in the comments!

Doing business with a company means you’re not just buying their products, but the experience of having their people, opinions and expertise, too.

Some companies really understand great customer support and service, others fall hard. The latter is the case with my recent (now only) experience with Canadian online menswear retailer, Frank & Oak.
My story is common: I ordered a couple of items, but one got lost in transit. I had full faith that customer service at Frank & Oak could help me track it.
I got a week of radio silence through their online form, and email. Resorting to Twitter, I finally got a reply a couple days later: “we’ll email you.”
Fast forward three weeks from their first reply and we’ve got two valuable lessons from their final correspondence:

I usually answer my email within 3-4 days, but since you sent 3 emails, the number of days showing since our last communication stayed the same. Please wait for a response next time, so that I don’t loose track of our communication.

1. Blame the customer: 3 emails in a 3 week span, of course it’s my fault.
2. Passive-aggresively tell the customer they’re annoying: In 2013, most email clients order messages by time of receipt. My fault, I didn’t know that yours doesn’t.
Every bit of this Frank & Oak email makes it my fault. So much for making customers feel like a bad ass.
For examples on how to avoid bad customer service like this, you can read how Ryan switched to T-Mobile and had a great experience, or you can read how we turned our own disasters into gold. And whether you work on a support team or not, everyone should give Carnegie a read. You’ll make more friends, and probably more customers.
In the mean time, I’m going to find a place to buy a nice shirt.

Back in March of 2009 I joined 37signals as Signal #13 and the other half of our two person support team. At the time we relied mostly on bug reports from customers to identify rough spots in our software. This required the full time attention of one or more “on call programmers”– firefighters who tamed quirks as they arose. The approach worked for a while but we weren’t making software quality a priority.

I had a chat with Jason Fried in late 2011 about how my critical tendencies could help improve our products. Out of that, the QA department was born. Kind of. I didn’t know much about QA and it wasn’t part of the development process at 37signals. So my first move was to order a stack of books about QA to help figure out what the hell I was supposed to be doing.

It’s been almost two years since our first project “with QA” back in 2012. Ann Goliak (another support team alumnus) recently joined me at the stead. Our QA process isn’t traditional and goes a bit different for every feature. Here’s a look at how QA fits into our development process, using the recent phone verification project as an example.

Step 1. I sat down with Sam Stephenson back in early July for our first walkthrough of phone verification. Hearing Sam talk about “creating a verification profile” or “completing a verification challenge” familiarized me with the terminology and flows that would be helpful descriptors in my bug reports. Here’s what the notes look like from that first conversation with Sam.
Step 2. After the introduction I’ll dive right into clicking around in a staging or beta environment to get a feel for the feature and what other parts of the app it touches. This is often the first time that someone not designing/coding the feature has a chance to give it a spin, and the fresh perspective always produces some new insights.
Step 3. There are lots of variables to consider when testing. Here are some of the things we keep in mind when putting together a test plan:

• Does the API need to be updated to support this?
• Does this feature affect Project templates?
• Does this feature affect Basecamp Personal?
• Does our iPhone app support it?
• Do our mobile web views need to be updated?
• Does this impact email-in?
• Does this impact loop-in?
• Does this impact moving and copying content?
• Does this impact project imports from Basecamp Classic?
• Test at various BCX plan levels
• Test at various content limits (storage, projects)

Project states

• Active project, Archived project, Project template, Draft (unpublished) project, Trashed project.

Types of content

• To-do lists, To-do items (assigned + unassigned + dated), Messages, Files, Google docs, Text documents, Events (one time + recurring).

Views

• Progress screen, In-project latest activity block, History blocks (for each type of content), Calendar, Person pages, Trash, Digest emails.

When these variables are combined you end up with a script of tasks like this one to guide the testing. These lists are unique for each project.
Step 4. In Basecamp we make a few QA-specific to-do lists in each project: the first for unsorted discoveries, a second for tasks that have been allocated, and a third for rough spots support should know about (essentially “known issues”).

When I find a bug I’ll make a new to-do item that describes it including: 1) A thorough description of what I’m seeing, often with a suggested fix; 2) Specific steps to recreate the behavior; 3) The browser(s) and/or platform(s) where this was observed; and 4) Relevant URLs, screenshots, or a screen recording.

We use ScreenFlow to capture screen recordings on the Mac, and Reflector to do the same in iOS. We’re fans of LittleSnapper (now Ember) for annotating and organizing still screenshots.
Step 5. The designer and programmer on the project will periodically sift through the unsorted QA inbox. Some items get moved to the QA allocated list and fixed, then reassigned to QA for verification. Other “bugs” will trigger a conversation about why a decision was intentional, or outside the scope of the iteration.
Step 6. Before each new feature launch, QA hosts a video walkthrough for the support team. We’ll highlight any potential areas of confusion and other things to be on the lookout for. After the walkthrough, a member of support will spend some time putting together a help section page that covers the new feature.
Step 7. Within a couple weeks after a feature launch the team will usually have a retrospective phone call. We talk the highs and lows of the iteration and I use the chance to ask how QA can be better next time around.
At the end of a project there are usually some “nice to haves” and edge-cases that didn’t make the pre-launch cut. These bugs get moved into a different Basecamp project used for tracking long standing issues, then every few months we’ll eradicate some of them during a company-wide “bug mash”.
So that’s a general overview of how QA works at 37signals. We find anywhere from 30-80 bugs per project. Having QA has helped reduce the size of our on-call team to one. The best compliment: After trying it out, no one at the company was interested in shipping features without dedicated QA.

Earlier this year, Y Combinator partner and Wufoo founder Kevin Hale came to speak with 37signals about how to design software users love. Here’s the talk he gave at UserConf 2012, that inspired our support team to invite him to our company-wide meetup:

Kevin is big on making everyone at the company do support, and how that informs what he calls “support-driven development.” When everyone has to answer customer emails, they’re more invested in improving the product for the people who pay for and use it.

We’d considered a “5% support” model before, wherein everyone at 37signals would answer tickets one day a month. But it wasn’t primarily because we wanted everybody to get touchy-feely with customers; it was because we were drowning in tickets. We ultimately tackled that problem in other ways — by expanding business hours, hiring a few new people and creating a comprehensive help site. “Everyone on Support” no longer seemed imperative.

We were missing the main point, though. Putting designers and programmers and everyone else in direct contact with customers isn’t about putting out fires; it’s about fire safety. It’s about having the kinds of conversations that lead to better products in the first place.

The idea is hardly novel; plenty of successful companies (Amazon, Olark, Zappos) train every employee to work one-on one with customers. Paul English, CEO of Kayak, told Inc. Magazine:

The engineers and I handle customer support. When I tell people that, they look at me like I’m smoking crack. They say, “Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?” If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they’ll actually stop what they’re doing and fix the code. Then we don’t have those questions anymore.

But let’s face it: Few people are going to jump at the chance to answer tickets if they don’t have to. (“I don’t know how you guys do this every day” is a common refrain among developers who jump in on support.) Still, no one denies it’s good for them, or for the company. Ultimately, leadership has to believe it’s valuable, and be willing to get their own hands dirty too.

Fortunately, that’s the case here — after all, Jason and David used to answer all those emails themselves, so it was familiar territory. Shortly after Kevin’s talk, Jason asked everyone (via Know Your Company) “Is there anywhere we’ve been all talk and no action?”

The earful he received from the support team was what it took to finally get “Everyone on Support” implemented. Ann hopped on the case and assigned everyone in the company a “buddy” on the support team, someone they could go to with questions and who could proofread their replies if necessary.

We’ve been at it about eight months now. We still have some kinks to iron out — sometimes we’re fully staffed, for example, so the “EOS” person doesn’t have a lot to do — but for the most part, we’re pretty tickled with the results. A few discoveries we’ve made so far:
1. It’s an incredibly useful training tool. The fastest way to familiarize a new hire with our products is to have them answer questions from customers. Nathan, who joined us in July, says that he absolutely learns something new with every EOS shift. “As a new employee, that was vital to helping me understand what we’re doing and how we’re doing it. Seeing how some of our jobs get stuck in the queues (avatar uploads, project exports, daily mailers, etc.) really helped tie some of the things I see in Ops to what our customers are doing.”
2. Long-standing problems get fixed. It’s not uncommon for a designer to improve the way something is worded on our website during their EOS shift, or for a programmer to spend some time squashing a bug based on an interaction with a customer. Especially when we have sufficient coverage for the day anyway, that’s been a fantastic use of the EOS shift person’s time.
3. The workflow process has applications outside support. “My ‘real’ job is so scattered,” says Andrea, our office manager. “I’m usually working on 2-3 issues at one time. When I work EOS, I try to focus on one thing at a time, resolve. Focus -> resolve. Focus -> resolve. Applying that mentality to my real job helps me feel less scattered.”
4. It reminds us why we’re all here in the first place. Our customers are the reason we exist as a company — the reason we get to do the work we love and take home a paycheck for it. That can be easy to forget if you never interact with them. “Software engineers and designers are often divorced from the consequences of their actions,” Kevin says. Not so if everyone has a stake in making sure the product is a pleasure to use. “Ops can rapidly get detached from the customer, because all we’re doing is keeping the lights on and helping set up new apps,” Nathan adds. “EOS keeps me reminded of why we’re doing that, and how our customers use our products.”
Does everyone at your company have a chance to interact with customers? If so, tell us more about it in the comments.

In customer support, empathy is everything—we need to be able to put ourselves in our customers’ shoes, feel their pain, give them the kind of help we’d want to receive whenever we have a problem. Potential hires are even tested for empathy before joining the team. (In case you missed it, Jim wrote a lovely post about empathy yesterday.)

Empathy is a skill—like any other, a skill that can be fostered and developed and built into a culture. (Dev Patnaik’s “Wired to Care: How Companies Prosper When They Create Widespread Empathy” explores the role empathy plays in successful organizations.)

Every once in a while, admittedly, my empathetic skills can be … challenged. And sometimes I make mistakes.

It happens. When a person we are genuinely trying to help is being unnecessarily rude or refusing to listen, it can be frustrating. In those situations, our capacity for empathy is compromised. The temptation can be to “stoop to their level” because “they’re just not listening” or “I can’t get my point across any other way.”

I recently worked with a customer who wasn’t able to sign into her website. Not our product, Basecamp—her own website. I did my best to politely explain they were different tools, and that she’d want to contact the admin for her website. She “frowned” me, and left angry feedback because she still wasn’t able to sign into her website.

I checked this customer’s history—she had written in about the same issue before, and another teammate had already politely explained she was barking up the wrong tree. I tried another reply, explained a different way. She left more angry feedback, because she still couldn’t sign into this other tool.

At that point, frustration got the better of me. “I’m really sorry for the misunderstanding,” I wrote. “I can only help you with Basecamp, though. I’m unable to help you get into your website. That is not our tool, or our company. Does that makes sense? It is as though you have contacted support for your vacuum cleaner, when your dishwasher is what is broken.”

I went to her website and found the company who supports it, and gave her the link to their customer support site. Turns out, her website was for her petsitting business. I read her “About Me” page. She has two boxers.

I have two boxers.

Her humanity slapped me right across the face.

What was I doing, scolding this fellow animal lover (this fellow human!) about vacuum cleaners versus dishwashers? Why didn’t I try harder to explain things clearly and patiently, like I would with my mom and dad? (Come to think of it, why aren’t I more patient with my mom and dad when they have tech questions?) I felt about two inches tall.

She didn’t write back. I hope she got the help she needed.

From now on, in my mind: Every time there’s a challenging case, the customer owns at least two boxers.

The first thing I do when I read an email from one of our customers is to mentally translate what they have written into how I would write that email. I take each sentence, break it down, and rewrite it in my voice, with my understanding of how our software works. Subconsciously, everyone does this to some extent – I’ve found that by making this act of translation a conscious process, it helps me in three ways:

Empathy

This is the most important one for me – by forcing myself to write the question how I would write it, I become the customer. It becomes really easy to share how they feel about the question – whether it is joy or frustration, anger or confusion. Understanding that emotional state helps me to compose an answer that is respectful of how that person is feeling.

Attention to the details

In this email-driven world of ours, we train ourselves to read emails quickly, to skim for the important points in a desperate bid to keep on top of the incoming flood. Speed is good, but it also makes it easy to miss subtle hints that can help you to solve the problem the first time.

By breaking down the email into its component parts so that I can translate each phrase in turn, it forces me to make sure that I haven’t missed anything.

Clarity

When you’ve broken an idea down, and rebuilt it in your own words, you learn how to express that idea clearly. This is helpful in two ways – you can explain the problem to the rest of the team concisely, helping them to identify fixes faster. You can also explain the answer to your customer more naturally. I tend to use the same words that the customer used as much as I can, which cuts down the number of back and forth emails considerably.
These acts of translation really help with customer emails, but the same techniques can help whenever anyone is communicating in their own personal jargon – letters from my accountant and conversations with my three-year-old both benefit from some internal translation. Take the process for a spin – I think you’ll like the results.

There’s not much worse than needing help with a product only to be told to wait around until someone can get back to you. That’s why our support team strives to reply as fast as we can when you need that help. We track our average response times each day and work to get them as low as possible.
Today, our average time to first response is 2 minutes. On top of that, 99% of email to our support team are answered within an hour. We’re working on presupport but that might take some time to get right.
So what’s the secret? Like with most things, it’s a combination of things that we do to get that response time as fast as possible.

Make sure you have the right size team.

Jason talks about hiring when it hurts. If your support team is continually behind on answering cases, it’s a world of pain for your customers.
During the New Basecamp launch, people sent in hundreds and hundreds of emails with questions. There were times that we’d still have 400 emails waiting for answers at the end of the day. It hurt us, it hurt our customers, and it simply was not sustainable.
Adding more people to the support team cut that time down. It even gave us a little more breathing room. If someone isn’t at work that day, we’re still okay. We’re at ten people now on the support team, which is the sweet spot for our volume of emails.

Try whole company support.

If you’re a small company watching your payroll, hiring on a new support person can be tough. Instead, have people already on the team do a stint answering support emails. Having a designer or programmer spend some time working with customers helps you get those faster replies. It also lets the rest of the team interact with customers firsthand. It’s a win-win for everyone involved.

Use time zones to your advantage.

Our support team stretches from Berlin to Portland. We’ve got people working on cases in the bulk of our customer’s time zones. That means a Basecamp customer in London gets an answer right away rather than waiting for us to wake up here in Chicago. And by using time zones, we each work typical 9am–6pm hours instead of crazy overnight or weekend shifts.
Back to the New Basecamp launch, Kristin switched over to what we called a swing shift. She’d work 12–8pm to help us be ready for the next day. Staying later in the day made all the difference. It allowed us to reply to customers faster since we didn’t play catch up every morning.
Eventually, she moved to Portland and now stops answering emails at 6pm. All thanks to the power of time zones.

Bottom line – customers don’t like to wait.

I’ve needed help with products before only to find out it’s a 24 hour wait until I would get a reply. That’s insane!
Our customers use our apps to run their businesses. When they’re waiting around, it’s costing them time and money. I’m betting your customers are the same way.
Aim for those fast response times. Your customers will love you for it.