Basecamp's Chase Clemons on delivering better support

In his time outside of Basecamp’s support inbox, Chase is the host of the Support Ops podcast. There, in a regular roundtable discussion alongside colleagues from Automattic, Buffer and Wistia, he explores how to create happier and more successful users.

Chase recently joined me on our own Inside Intercom podcast to share how to improve experiences for customers, as well as your own support team. Our chat covers making remote teammates successful, removing contact barriers for customers, the internal and external benefits of investing in help content, and much more.

If you like what you hear, check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed.

What follows is a lightly edited transcript of the interview, but if you’re short on time, here are five key takeaways:

1. In the world of support, there’s always another email in the queue or a chat awaiting response. To keep your support team from burning out, you need to establish a culture of limits – that it’s okay to turn off the computer at working day’s end.
2. It’s true that a happy workforce makes for happy customers, but you can’t establish the former without giving your team opportunities to learn and grow both soft and hard skills, and share knowledge.
3. Startups must pay attention to the small things that make it harder for customers to get in touch. Things like no-reply email addresses may seem harmless, but create a very real barrier.
4. Invest in self-serve help content for your product from day one, and that means treating your help site just as you would a product feature – it should look, sound and feel like your support conversations.
5. Providing support for older versions of your product can be a big customer happiness win, but you must be prepared to invest time getting new hires up to speed on the quirks of previous builds.

Adam Risman: Chase, welcome to the show. Obviously Basecamp needs no formal introduction. We’ve had Jason Fried on the show and are big admirers of your product and work. Can you give us some insight into how support at Basecamp has evolved in your time there?

Chase Clemons: I was hired in May 2011. I got out of college and I thought for a while I wanted to be a public school teacher and realized that really wasn’t my jam. I stuck around the restaurant world for a while, just because growing up my parents had restaurants, so I was really familiar with it. Basecamp put out an open job for a support team member, and I applied thinking there’s no way in hell I’m going to get this. A week later I got a call from Jason and everything just happened really quickly.

We were a really small team at that point, maybe half a dozen people, and our customer base was not quite as big as it is today. The support volume wasn’t quite as big as it was today. Now we’re one of the largest teams inside Basecamp itself. We’re up to 12-13 people, and with those extra people we get to do cool things like trying out live chat for customers or trying out some social media ideas or some community things, a little marketing, all those other things that you can really experiment with once your team gets big enough to give you some space.

Adam: That’s interesting to hear about your background prior to coming into a customer support role. How diverse are the backgrounds on your team?

Chase: That’s one of the things we look at. For the most part the people that apply for jobs on the support team are pretty diverse. We’ve hired several former librarians. We have a former apartment complex manager. I was from the restaurant world. People that all were interacting with customers in some way, shape, or fashion, but they weren’t doing what we think of as online customer support.

Adam: Are there certain skills that all those people share?

Chase: It sounds clichéd, but there’s the thing that everybody calls soft skills, like empathy, being able to write well, being able to communicate well. Those are the common threads between all of us. In those jobs you’re dealing with customers face-to-face so you have to be quick on your feet about thinking through the situation, how you can help that particular customer. It’s all things that translate really, really well to online customer support. The hard skills, those are things that we just teach. Here’s how Basecamp works. Here’s how our email system works. Here’s how Intercom works, etc.

Creating a remote culture

Adam: Basecamp is truly a remote workforce, and your founders wrote the book on remote working. A lot of growing companies the first thing to go remote is support. Perhaps it’s to cover more time zones, to be where your customers are, or even reach 24/7 coverage. What’s been the key to creating a healthy culture among team members that are so spread out?

Chase: The biggest thing for me personally has been limits. I joke around with the rest of my family and say, “I can do my job from the middle of a field as long as I have a laptop and I have an internet connection somehow.” You don’t get a snow day. You can always work whenever you want to work, so one of the first things that we always instill in new hires is knowing your limits. Knowing when to turn off the computer, when to shut down the browser, when to walk away from it.

With customer support, there’s always another email in the queue, there’s always another chat that can be entered. There’s always another tweet that needs an answer, so it can be tough to know when to stop working now and just walk away. That’s one thing that I think is really key, especially when it comes to being a healthy contributing member on a remote team like ours. Know those limits, because if you don’t then it’s going to be a world of pain.

Know those limits, because if you don’t then it’s going to be a world of pain.

Adam: Do you have to go the extra mile when it comes to sharing information that everyone has learned when they’re spread apart like that, and not retreat into silos with the things you’re learning in customer conversations every day?

Chase: Absolutely. I mentioned earlier, we look for people that are good writers. The reason for that is because you have to be able to communicate in a written form whether it’s talking to a customer or it’s pitching a new idea to the rest of the team or giving an update on a project. All that happens for the most part via written text. Granted, you can do video tours of a new feature that you’re working on or a new idea. You can sprinkle in all sorts of images and pictures and things like that, but for the most part your ability to write well directly relates to how effective you are at being able to interact with the rest of your team.

You’re also doing a lot of this not only for the moment in time, but also for people down the road that are going to come back and read this later. When we’re writing out the explanation for why a design is a certain way, or why the choices we made to do live chat rather than this, we want to be able to effectively communicate them. That way our new hire six months down the road can read it and instantly be up to speed on that conversation.

The keys to a happy support team

Adam: So much of what we read every day about good support focuses on obvious things like keeping customers happy and avoiding churn, but at the foundation of all that you ultimately need a happy workforce. How do you facilitate career growth for your support team so they don’t feel like they have to leave support for a product or a customer success role for advancement? Are there things beyond people management that you can offer in the support?

Chase: There’s two things tied up in this. The first one being are you happy with where your career is going. Are you happy with where you are right now and the options you have for your career? The second part is what are those options? What things can you do in support?

Basecamp is a relatively flat organization, so take our support team, for instance, we have a team lead, and then everybody else is pretty much on the same level. There’s no “If you do three more projects and collect two more stars you get to bump up.” We just don’t really have that. Instead what we do is we focus on growing you as a support pro. Advancing you and your skills whether it’s those soft skills that we talked about, or hard skills like learning CSS so you can help figure out bugs a little bit easier. Whatever those things are that you want to do, we help and make sure that you have those opportunities to do that.

Make sure the circumstances and the situation are primed for happiness.

A good example: Basecamp does an internship program, so Marissa, one of my support teammates, and I were talking about what it would look like if we were mentors and we had somebody as an intern. That’s going to be a fun side project that we get to work on. It’s not climbing a ladder, but it’s going to advance us as support pros. We are going to get better at our job from doing something like that.

The other thing really is that happiness I mentioned. A lot of people are wrapped up in having to have a super happy workforce because happy people mean happy customers, and that’s true. At the same time the job that we have is to make sure the circumstances and the situation are primed for happiness. I can’t make somebody happy.

Especially for startups as they focus on, “Well I’ve got to have a happy workforce”. Yeah, you do, but you’ve got to create that circumstances, the context, the situation for it, rather than worrying about is Joe going to be happy if I tell him to do X, Y, and Z.

Adam: When it comes to your teammates communicating that level of happiness is there anything you can do for remote team members to open up those lines of communication?

Chase: Definitely. We go as far as to we have a project set up called Care Camp, where you can go in and you can talk about things like if you’re feeling stressed at work and what are some options for setting yourself up in a situation where you could be less stressed. It’s also a place where we talk about different food diets and exercising because all that plays a part in a person being happy in the bigger sense. We do that. We also do one-on-ones, not only with Kristin, our team lead, but also with each other. A lot of it, too, is after working with somebody for a long time you can tell if something is going on just from the way they’re interacting with you.

The example I like to use is I’ve worked with Joan and Marissa now for five years. If one of them is having a bad day I can feel that through their text chat conversation with me, and vice-versa. That’s something that’s only going to come with time, so if you’re a brand-new startup and you’re doing this remote thing, don’t think it’s just going to automatically happen. You’ll start to pick up on certain people’s habits and little ticks and things like that, and you’ll get a good sense of where they are that day.

Adam: Speaking again about structure within teams, what’s your take on specialization? Is it a good way for team members to carve out a niche and gain deeper learning or does it open up more windows for silos?

Chase: Specialization for specialization’s sake, I’m not a fan of it. I’m okay with the idea of you want to get better at a certain part of the product or you want to really dig in on how PCI compliance works so you can really have a good understanding of how billing works. That’s fine. If you want to dive deep on that, go for it. The end goal should not be for you to hoard that knowledge. The end goal should be for you to share all of that so that all of us get a knowledge boost from what you learned. Specialization, if you want to do it, go for it, but just remember to share whatever you learn with the class. Make sure that you write it down so future hires will have that to refer back to. Don’t keep it locked up to the point where if any billing email comes in, you have to go, “Jane over there, she’s the only one that can handle this, so we are just going to have to wait for her to get back from vacation.” Share. Specialize but share.

Letting customers get in touch

Adam: Earlier this year you wrote a really great post on Signal vs Noise about the issue of no-reply email addresses. Basically they create an unnecessary and impersonal blocker for customers who might want to have a conversation with you. A lot of startups are still using these for things like newsletters. Many of our listeners are coming from early stage startups themselves, so I’m sure this isn’t your only pet peeve in the space. What other common blockers might they be creating by simply following these trends that seem innocent on the surface?

Be particular about how the system automatically treats your customers.

Chase: Yeah. It seems so innocent. It’s like an email address that you just happen to throw in that one little form field on your newsletter. On the receiving end it’s so impersonal. As far as other little things, and there might not be another customer in the world that actually agrees with me on this stuff, but I think like little things like making sure it’s really, really easy to get over to your support documentation.

There’s some bigger ones too. When you first set up whatever app you’re using to do your customer support in whether, it’s Intercom or Help Scout, be really particular about how the system automatically treats your customers. I’m sure you’ve been in the situation where you email some company and then you get an automatic email reply back that assigns you a ticket number, and then tells you all these weird little short codes that you can use if you want to open the ticket or close the ticket. That ticket language drives me nuts. It’s an email. That’s all it should be.

Actually the worst offender is if I get a reply back from a company and I don’t reply to it, then 24 or 48 hours later I get this automatic email from this system saying, “Hey, you haven’t replied. We are going to close this ticket out. Go ahead and open up a new one if your question is not answered yet.” I’m sitting there thinking this is such a robotic move. It’s like I’m trapped in a system now, and it’s usually really unintentional. Whatever support product they picked, it might have that as the default and then you have to go in and turn it off. Pay attention to those little things. Pay attention to the things that make it a little bit harder on your customer when you could be making it a little bit easier on them.

Adam: Right. When I’m in that experience, as I’m trying to make progress I’m actually being presented something that makes me feel as though I’m further away from it.

Chase: Exactly. I was talking to an airline the other day, and it was literally like, “Oh, do you have your ticket number?” I’m sitting there going, “What? You have my name and my email address. That should be more than enough for you to figure out what’s going on. What ticket number?”

The importance of a good help site

Adam: No matter how many blockers you remove, sometimes the quickest route to an answer for users is through self-serve. At Basecamp you have a really robust and intuitive help doc site, and it’s clear that you’ve invested in that space. When should startups be investing in this kind of content, and what’s been the key to doing it well for you guys?

Chase: Startups are going to get a million different answers about when you should start doing this. For me, it’s always from day one. As soon as you release your product and have customers using it, you need to have a help doc site that is basically a feature of your product. Don’t treat it like an afterthought, don’t treat it like this nice to have little thing over here. Treat it with the same care and intensity as an actual feature inside of your product itself. Invest in it from the very beginning, and then from there any time you add a new feature just go ahead and add that into your help site. Do those simultaneously.

One of the things that we push for here at Basecamp is the moment a new feature goes out to the customers we flip the switch on the documentation for that on the help site. It’s instantly live the moment customers get that new feature. Not an afterthought. It’s going to take a little bit of coordinating. That’s fine. If you have to take an extra day or two for the help site to be updated to release that new feature, that’s fine. Take two extra days. Just make sure that it’s a feature of your product. I think that a lot of people forget that.

At the end of the day a help site does two basic core things. First it explains how to use something in the product, and then second it explains why you should use it. A good example with us, if you ever use Basecamp 3, we have two tools inside of it. One is called Campfire. One is called the Message Board. Campfire is this group chat tool, instant conversation back and forth. Messages are more like a traditional message board. You post a message about an update or an announcement, and then people are able to reply to it as a common thread underneath it. With our help site we talk about not only how you use those, like how do you post a message; we cover how do you format the text in the message; how do you format the text in a message; how do you save it as a draft before you post the message.

Then we also talk about why, like what’s the situation where you want to use an instant chat, versus a lower gear, give people more time to reply to messages type of tool. It comes up in almost every conversation I have with a customer when I’m talking about the different tools in Basecamp, they ask, “Why am I going to use this versus that in this particular situation?” Explaining not only the nuts and bolts of how to use it, but also why you would use this over that, that’s the job the help site has to do at the end of the day.

Adam: We’ve talked about both of us a couple of times to make good support a differentiator for your product it’s got to be human rather than robotic, or corporate. Do those qualities apply to this self-serve support content as well? How do they manifest themselves there?

Chase: They absolutely apply. If you think about your help site as an extension of your product, a feature of your product, it’s kind of weird when you use a product and then you go over to the help site and it’s completely different. You can tell two completely siloed teams worked on each one. You don’t want that kind of feeling. You want it to just be this seamless experience going from one to the other and then back. When you start writing up your self-serve content, use your own tone, use your own voice, use the language that you’re using in the app itself. If you’re telling people to post a message, use the phrase “post a message” rather than “submit a message.” It’s a different kind of voice, even in just like that one word change right there.

Have your own tone. Have your own voice. Have fun with it. A lot of times you see help sites that are very vanilla, very off the shelf, templated, kind of robotic style, like it’s an afterthought. Help sites don’t have to be that way. Add in some videos. Add some gifs. Add some animations. If you go to the Campfire chat I was talking about earlier, we have a page that talks about Campfire. It’s got screenshots on there. It’s got gifs on there. It’s got a video at the very top that shows you a real world situation where you would use it.

All that is going to give the customer a better experience about answering their question, versus something like, “We found this free WordPress theme and we just slapped it on there, and then we slapped some text in, and all this was done like six weeks after the feature came out.” Again, treat it like a feature. Give it that same care and attention.

Until the end of the internet

Adam: Another thing people would notice visiting your help site is that you still have a lot of content there for Basecamp Classic and Basecamp 2. There’s this idea that Basecamp, “until the end of the internet.” You aren’t forcing anyone to update when the new product comes out, and you continue to support those older versions because you don’t want to interrupt the way people work. What challenges does that bring from a support perspective, and how have you guys built your strategy around that?

Chase: As a customer is there anything less terrifying than an email you get from a product that either says, A, we’ve been bought, or B, we’ve got this brand new version that you’re going to love? Something is changing, and our customers are small business owners. They don’t have time for change. They want steady. They want stable. They want Basecamp to be basically what it is today, tomorrow. Whether that’s they’re using our oldest version, Basecamp Classic, or if they’re using our brand new Basecamp 3 version. That was our promise. Our promise is until the end of the internet we’re dedicated to supporting our products there, so as long as we’ve got power, as long as we’ve got servers, as long as the internet is there in some kind of form, you are going to be able to use Basecamp Classic, which has been around for 12 years now. We’ve got customers that still use Basecamp Classic, that love it. It does exactly what they need it to do. They’re not going to change anytime soon.

Learn more about Basecamp’s Until the End of the Internet philosophy.

Support-wise, you’ve got to learn those products. Whenever you get hired on the support team, we tell folks it’s going to be about a three-month ramp-up process before you learn all three different versions and all the little quirks for each, because they’re all different enough that they’re distinct products. Training becomes a little bit harder. We talked about the help site that we have. All that is still there not only for customers but for us too, so if we forget how some little weird thing works in Classic, it’s probably in the help site, and you can go back and look at it there. It’s definitely a cost that goes into this, but I think at the end of the day it’s a cost that customers appreciate, and it’s one that it’s going to pay off down the road.

The product feedback loop

Adam: We’ve written a lot about how we at Intercom use our product to support Intercom, and I think it’s safe to assume as a remote team you’re using Basecamp to support Basecamp in a lot of ways too. Through all that time in the product, what role are you playing in the feedback loop when it comes to new features?

Chase: Couple of different things that come into play here. The first one is I talked earlier about how every new feature before it gets released has help documentation written for it. Usually the designer that’s working on that feature will go through and work things up, but we’ll have some of the other support team go through and help them out with that as well. The help site, that help documentation is getting made by people who are coming from two different angles: the designer who is coming from the, “I built this feature,” and then the support pro that’s coming from the, “Yeah. We have to teach people how to use it now if we need to.” We get some support feedback in that way.

Before it hits that process, our QA team goes through and they spend about a week, a week and a half actually QA’ing every feature that comes out. Two of our earliest support hires are embedded there. They get to touch every single new feature that goes out as well. They’re really, really great at not only spotting, yeah, there’s a bug in Internet Explorer when you do this particular sequence, but also really good at, “I think customers are going to be confused about this thing. Can we change it to this flow?”

All hands support, that’s been a big thing because it rotates every designer, every programmer into the support team for a day so they can talk to customers right there in the inbox. You’re right, we do use Basecamp to support Basecamp, and one of the ways that we do that is we have a folder set up in our support project that basically collects all of the different customer ideas and feedback that we get back inside of our email inbox. We’ve got it split up into these different areas where basically we can go if you send me an email about, “I would love if Basecamp could do X because of Y.” We can take that email and then put it inside of Basecamp in that section. That way when a designer, at the very beginning when they pick up on a new feature, they can go into that section of the project and look at all the different feedback we got from customers, see it in their words with their screenshots if they attached any, or files if they attached any.

The designer is able to really get a good idea of where the customer is coming from, because they’re reading actual customer words, actual customer ideas. I’ve worked with teams before where they take that kind of customer feedback and usually it’s locked up in some other product or some other app over here in the corner. That’s great. It’s great that you’re collecting that, but having it in a place where your team is going to interact with it on a day-to-day basis, where your company is going to see it every day, makes a big difference.

Adam: It’s interesting that you mentioned, too, embedding support team members. That’s something that we’ve done at Intercom recently to help extend support’s influence and bridge communication gaps is getting those support folks in with the product people, and it’s making a difference.

Get the customer voice out of the inbox.

Chase: It sounds like this little thing that you can do that isn’t going to have a big impact, but there’s so much power that comes from that. You know that whenever you’re looking at a feature that the customer’s voice has been there. Some features, it’s going to be one of those where maybe it doesn’t work how the customer originally intended it to do. Maybe it’s like the customer said, “I needed X,” but then you really dig into it with that customer and other customers and you find out, “Yeah. They really need more like Z,” and so you make Z.

The first step that you as a startup can do is to get that customer voice out of the inbox and into the hands of people that are working on the product. However you do it, whether it’s all company support, customer days, putting that feedback right inside whatever app you’re using, you’re really going to get the benefit from doing that.

Behind the mic on Support Ops

Adam: You’ve got your own podcast that you host, SupportOps, where you’re joined by Carolyn from Buffer who we mentioned, Chase Livingston from Automatic, and Jeff Vincent from Wistia. What can listeners expect from that show and what do you have coming up there?

Chase: What other show can you really get two guys by the name of Chase on it? Really. If nothing else come to listen for that. From the very beginning we had the end goal of wanting to help any team out there improve their customer’s experience, whether it’s a startup, a company that’s been around for a while, remote, non-remote, whatever. Every business has customers, so our goal was to help you make your customer’s experience just a little bit better.

We do series on everything from how a support team can work with the rest of your company, to how you can grow and learn more yourself as a support pro. If you get a chance, go and check us out, SupportOps.co. At the very top I’ve got a Start Here link, which is a good primer on the show itself and myself, the other Chase, Carolyn and Jeff, and it’s got a couple of our favorite episodes listed, too. If you’ve got customers then you’re going to come away with something that’s going to make your their experience just a little bit better.

Adam: Come for the two Chases, stay for the support insights. Thanks so much for joining us today.

Chase: My pleasure.