You’re reading Signal v. Noise, a publication about the web by Basecamp since 1999. Happy .

Signal vs. Noise: Support

Our Most Recent Posts on Support

The 5 most common Basecamp workarounds

Emily Wilder
Emily Wilder wrote this on 16 comments

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!

Lessons from Frank & Oak’s Support

Mig Reyes
Mig Reyes wrote this on 19 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.

Quality Assurance

Michael Berger
Michael Berger wrote this on 16 comments

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).


  • 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.

Everyone on Support

Emily Wilder
Emily Wilder wrote this on 9 comments

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.

A refresher course in empathy

Emily Wilder
Emily Wilder wrote this on 24 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.

Found in translation

Jim wrote this on 2 comments

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:


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.


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.

Don’t Keep Customers Waiting

Chase wrote this on 15 comments

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.

When empathy becomes insulting

David wrote this on 38 comments

Most corporate customer service departments seem to have been reduced to call scripts of apologies with no power whatsoever to actually address the problems they encounter. That’s the conclusion I’m left with after dealing with three business bureaucracies this year: Comcast, Verizon, and American Airlines.

All train their front line people to glaze the interaction with the plastic empathy that’s supposed to make you feel like they care, even when they demonstrably do not. It’s the customer service equivalent of empty calories, but worse, it’s also infuriating.

There’s simply nothing worse than someone telling you how sorry they are when you can hear they don’t give a damn. Nothing worse than someone telling you that they’re doing all they can, when they’re aren’t lifting a finger.

The emotional chain reaction is completely predictable: At first, you’re comforted that someone appears to care even if the tone is off (humans are remarkable at sussing out insincerity). Then you realize that their only job is to get you off the line, not solve the problem. Then follows the feelings of being powerless and betrayed. And then follows the anger.

That’s a vicious cycle and it must be almost as bad on the other side. Imagine having to field calls from customers every day who you want to help, knowing that the only thing you’re allowed to do is feign that “we apologize for any inconvenience you may have experienced”.

What’s so sad too is how little it would often take to resolve the situations. You bend a policy here, you expedite an order there, you bubble an issue up to a manager. A natural, caring organization designed to create passionate customers stretches and bends. A rigid business bureaucracy looks to nail every T on policies, procedures, and practices—customers be damned.

(This post was brought on by my recent experience in American Airlines earned an enemy)

Basecamp Delivered is Headed to Atlanta

Chase wrote this on 5 comments

Getting support online is great, but wouldn’t it be nice if you had an expert right beside you? A few of us will be in Atlanta and would love to meet you and your team!
We’ll be at Roam in Alpharetta on Friday, April 19th, at your service. We’ve got 30-minute sessions throughout the day to fit your schedule. Registering for one 30-minute session will cover you and up to five others on your team.
We’ll be there to answer all of your Basecamp questions and to help turn you into a Basecamp pro. We can also show you some best practices to help you and your team get the most out of Basecamp. You’ll just want to bring your own laptop so we’ll be able to do all this inside your Basecamp account.
Space is limited. Make sure to register and save your spot.

To our awesome customers: a shout-out

Emily Wilder
Emily Wilder wrote this on 2 comments

Our customers can be unexpectedly, hilariously great sometimes. It’s not at all uncommon for one of us on the support team to post something a customer said in Campfire, because “this lady just made my day!” or “this guy was so funny and nice!”

Now, we’re empowered to do right by our customers, so that’s part of it—we can all take care of billing issues or ID merges or whatever our users need without going to a manager. (Psst: there is no manager.) When we’re able to fix a problem within a few minutes or we prove to be real people rather than robots, that tends to pleasantly surprise people, and they react accordingly. Awesomeness begets awesomeness.

Super speedy, plain and clear communication – didn’t feel like a call-centre experience – was quite obvious that Jim knew what he was talking about rather than just reading from a script. Got the exact answers and actions that I needed. Not used to this level of service – feel a bit dazed ;-)

But we don’t deserve all the credit. Our customers just tend to be savvy, and kind, and they consistently disprove the popular consensus that people on the Internet suck.

No problem. Machines don’t mess up near as often as often as people. So odds are I just didn’t save it correctly. Thank you again for your time and trying to help.
Chase answered my question quickly and completely. He also threw in “have an awesome Tuesday” which is a mildly absurd thing thing to wish someone as it is usually weekends which are “awesome”. I’m gonna run with it though and try to make this day “awesome”. I already high-fived my dog. He seemed confused.

A surprising number of folks write back just to say thank you. They don’t have to—it’s our job to help. But it’s still nice to hear and gives us warm fuzzies.

You know what Kristin, you just made my day … and restored my faith (a bit) in our species.

Sometimes they go beyond that, even. Out of gratitude or wackiness or whatever, they send us photos and videos of their pets, or links to memes.

Thank you. I attached a flying unicorn to show my appreciation.

Some of our San Francisco customers know Merissa is a huge Giants fan, and a few submitted support tickets to tell her they were excited for her during the 2012 World Series. People will sometimes write in just to say they love Basecamp, or to wish us happy holidays.

Just want to say Merry Christmas guys … we’ve been using Basecamp for many years and continue to love the service. Keep up the good work and hope to be on your service for years to come. Here’s a big thank you. Thanks to the web-based nature of work I can stay in touch while getting some awesome snow on holiday in Niseko, Hokkaido, Japan!

Those of us in support are here because we genuinely enjoy helping—but you folks make it easy. Thanks!