There used to be a panicked feeling that would set in when we’d have any sort of outage or issue in Basecamp past — that stomach-dropping, heart-palpitating, sweaty-palmed feeling. But on November 8th when I awoke to a 6am text spelling out Basecamp’s downtime, I wasn’t worried. Before I finished reading the full text, I remember thinking, “Oh, they’ll have it sorted out before I can finish making coffee.” But as I continued reading and began to understand the estimated downtime to be at least two hours, my adrenaline hit.
The first thing I wanted to do was check on the support team. Were they in panic-mode? How sweaty were their palms? How many customers had they talked to already today? How close to capacity were they?
And by the time I received the alert and logged on (coffee brewing while I said Good Morning, thank glob for remote work), Basecamp had been in read-only for about 30 minutes, three times my prediction. Despite the stress of a lengthy downtime, knowing that we’d have a few hours of this status allowed us to settle in and accept our predicament. We had time to get into a flow and trust ourselves to talk our customers through this.
Really, what I realized when I logged on was that everything was absolutely under control on the support team. And of course it was: for the past two years, our team has been conducting crisis drills with each other. Once a month, we rotate responsibility for these drills and each person is responsible for coming up with their own style of drill. They’ve become quite the gif-filled, fun time! We work from a playbook (hosted on GitHub in case Basecamp is down) that acts as a living document we can update as-needed. We’re currently in the process of using our experience from the read-only outage to revamp and reassess the playbook to make it even more accessible, comprehensive, and succinct — no small task, mind you!
Good help is hard to find. I dread calling the credit card company, the phone company, any service provider, including and maybe especially SaaS companies. I anticipate talking to someone who is poorly trained, under-paid, powerless, and miserable. I anticipate their frustration rubbing off on me. I anticipate arguing to get my needs met. And that’s if I can even get a real human to talk to me. The people standing in the way of good help aren’t the customer support representatives themselves, though. Corporate culture, the bottom line, and rotten support for service roles has ruined how folks get the help they need.
I’m not alone in this. I’m not the only consumer who approaches support defensively, with their hackles up. Before we dig in, I want to tell you about a customer of ours — let’s call her Nancy — who, like me, had low expectations. She wrote to us asking for a lower price (which we didn’t have).
One of our reps, who has been at Basecamp for almost five years, wrote her back to politely tell her that we don’t have any lower plans to offer her.
Here’s what they wrote to Nancy:
Her response back was a little bewildering:
Three words! A sentence fragment! End of transmission. I saw this and recognized something interesting. Nancy was replying as if she were on hold with an automated service: Say ‘Account and billing’ for our accounting department. Say ‘Technical support’ for our technical department. I’ve been greeted by too many of those automated services and have more than once simply repeated the word “Human” until a person got on the phone with me. I swear, it works more quickly! Anyway, I recognized this in Nancy, so I jumped on a call with her. She immediately confirmed my suspicions and told me that she thought that the person who originally responded to her was a robot — and she then read the whole email to me in a robot voice to further her point. She also told me that because she thought she was speaking with a robot, that her three-word response was an attempt to get the robot to understand her. In short, she was speaking the robot’s language. To her, Basecamp was nothing more than beeps, algorithms, and machinery. We were no longer a group of humans with families and hobbies and struggles — we were machines that didn’t deserve even a full thought.
So how did we get here, to this point where our customers assume we are not even human? This was Nancy’s first interaction with us, so she had no context or history with us that would have lead her down this inhuman path — something else, outside of Basecamp, made her believe robots are the general first responders. We all know that capitalism has made the bottom line more important than the people. We need to reject these late capitalist temptations in order to protect our customers, our people. The people are why we’re here, the people pay our salaries, the people use our products. Don’t be fooled into thinking that anything other than people can support your customers.
Nancy, like myself and so many of you, drew from her previous experiences with customer support. So many companies put up some automation, a chatbot, some AI that ends up standing in the way of customer service and support. Nancy, by the time she emailed us, was already fed up with this culture, this treatment. Frankly, I’m fed up with it too. I never want to sit on hold listening to shitty music, pressing menu buttons, entering my account ID. Like Nancy, I want to talk to a human. I want us to get to a place in our industry where I know that when I contact a company, I’ll speak with a well-trained, cared-for human.
Because I live by the Golden Rule, to treat others as I want to be treated, I need to formalize how I want to be treated in order to better help our customers. What do I want? I want to talk to a well-trained, compassionate, and intelligent person when I have an issue. I have never in my life wanted to work out a problem with an ill-informed person. I never want our customers to feel that way about us: either that they cannot get a human to speak with them or that the humans who are speaking to them are simply unhelpful. Place yourself in a compassionate position — how do you want to be treated when you need to contact a company with an issue? What’s your ideal scenario? Start compiling your values so that you know what’s important to you.
Once you’ve figured out how you want a company to treat you, it’s time to look in the mirror. Are you treating your customers the way you want to be treated? Would your friends and family receive decent help from a decent human? Would you rest assured knowing your neighbor would be treated compassionately and timely if they needed help from your company? To put it shortly, are you proud of how your customers are treated? Does your company stand up to your own expectations?
If not, that’s ok. I want to help.
Now that you’re coming to grips with your own values and expectations, it’s time to open up a direct line of communication with your customers. Not an answering service, not an auto-reply, not an automated recording or menu, no bots, no AI. Figure out what you can manage. Email is the best way to gauge this.
Here’s what our support page looks like. It takes one click to get here from our homepage. We’re not hiding behind a “contact us” link at the very bottom of a page.
If you scroll down, there’s a text box below this that you can fill out to send us an email that goes directly to email@example.com. We also show you roughly how long it’ll take for us to respond to you. On a normal day, we answer 100% of emails within an hour of receiving them. 90% of those, however, are answered within 30 minutes.
That quickness, that attention, didn’t happen overnight. It was an iterative process that took about a year or two. We kept adjusting our methodology, each time failing a little better. When I started at Basecamp, we had four people answering emails. We all lived in the same timezone and worked roughly the same hours. At 8am on a Monday morning in Chicago, we’d have 600+ emails waiting for us. We rarely answered an email on the day it was received. Now, we have fifteen people stationed from West Coast US to East Coast Australia. We answer emails 24/7, save holidays and company meetups, with folks working roughly 9am-5pm five days per week. No one works in a call center. We train and support our own employees. We are connected to each other through Basecamp. Our team is the face of Basecamp.
I’m showing you this so that you can see how easy it is to talk to someone at Basecamp. We’re not hiding behind a device or a bot that’s trying to convince you that we care. We actually do care. We really do care. We know that our customers want to talk to us. They don’t want to wait on hold or have some AI device convince them that their problem is simpler than it really is. They want our expertise, our consult. When I call our customers, they aren’t asking me Yes Or No questions — they are giving me their stories, their narratives. They want me to understand their daily workflows and needs so that I can consult and problem-solve with them. I want to help our customers succeed — hell, it’s in my own best interest that our customers succeed not just at using our product but at their business so that they can continue to pay us to use our product. Part of helping them succeed is hearing their stories. When people can speak their truths aloud, then they are better able to process those truths. That means that when we give our customers the opportunity to speak to us, to tell us their stories, then they understand their workflows better. If you understand your truths and workflows better, then you can do better work. When you employ a bot or use an automated service, you’re sending the message that you’re too good to talk to your customers yourself, that they don’t deserve your time or patience or thoughts. Your customers want to talk to you, and you should want to talk to them.
Let me show you just a glimpse of the feedback we get at Basecamp after we have conversations with our customers.
So, you see that our customers (who aren’t different than yours) want to talk to a real human. A real human! They want to have a real conversation with another person. It’s not just that they are happy that they got to talk to another human — it’s that they are surprised that they did. Like Nancy, they assumed we were robots. Why? Because so many companies have failed them, treated them like a burden so that they learned robots are now being employed to help customers. This happy surprise that our customers get after realizing our humanity isn’t exactly a good thing, it’s not exactly flattering. The bar is so low that all we have to do is be a real human. What we’re doing at Basecamp isn’t ingenious. We’re simply understanding our own capacity for answering emails (60–75 per person per day) and doing that in our own voices. We’re simply allowing a team of people to have human conversations with our customers. It’s sad to me that our fellow humans expect so little from us. We only have ourselves to blame!
Check out this hilarious clip from the latest season of Bojack Horseman, in which one character is struggling through her day and needs help from a customer support rep. Diane is carrying a lot of emotional baggage with her and needs a human touch, someone who can empathize and alleviate some of that burden. She’s instead met with a robot.
It’s funny and we laugh (it’s dystopian but honestly not all that absurd), but this is a daily reality for so many people who simply need a human conversation, someone to guide them through a difficulty (even if that difficulty seems frivolous to us). A harsh reality played out here is that, too often, service providers like this are not trained to actually help a person in need.
It’s not just that a human conversation is what our customers want and deserve. Our relationship to our customers should be more symbiotic — we need just as much from them as they need from us. Sure, our needs are different, but think about how we know to grow our product, where the holes are. At Basecamp, we talk to our customers. We interview them. We listen to their feature requests, their rants, their raves. We don’t simply look at data and clicks (we do that, too!), but we also have real conversations with real people. Real humans!
It may seem cheaper to employ chatbots and automation, and that’s because it is. It’s not a good thing when cheap is synonymous with flimsy. You’re sacrificing intel, product knowledge, connection, and culture. It’s not worth the sacrifice. Your human support team connects daily with your customers, your customers who not only carry with them the money you need to stay in business but also the knowledge of how to improve your product.
So if customers want to talk to humans and if customers have product knowledge to glean, why are we seeing so many companies employ these automations and bots? One of the reasons is simply that we’re a society that’s obsessed with technology and profit and the intersections therein. Maybe we should all reread Frankenstein?! But I also think that a more compelling reason is that support teams, in general, are not treated with the dignity and respect that they deserve. That creates a culture of apathy and causes high turnover rates. Turnover frustrates managers and hiring committees: Why won’t people stay? This job is too draining. Let’s get bots who don’t complain and can’t leave. Apathy frustrates your customers who will find another service provider who can support them genuinely. I can tell you from experience that it’s not the work itself that makes people leave; it’s not the work itself that creates apathy — it’s the culture.
I’ve been supporting Basecamp customers for over seven years. Three others on my team have been supporting Basecamp customers for over seven years. Several others have been doing this for nearly five years. Collectively, our team has been supporting Basecamp customers for 64 years. It’s rare when someone leaves. So, I’ll repeat myself: it’s not the work itself that creates high churn and apathy in support positions; it’s how the employees are treated.
We all need to start placing higher value on the team that works directly with our customers. That means finding people who are preternatural helpers, first and foremost. What are preternatural helpers? People who enjoy problem solving with others. People who want to cull all sorts of knowledge for themselves and others. People who run to a problem instead of away from it.
Our team is made up of librarians, educators, personal assistants, fraud specialists, and IT professionals. All of these kinds of helpers, in order to succeed in this field, must be strong writers. You need a team of people who can communicate effectively in any form — that means that their written word must be passionate and strong. You need to hire people who can devise a way to gently say no, to kindly show a user how to accomplish a simple task without making them feel stupid. You need to hire people who are capable of handling difficult conversations with grace and candor. You need to hire people who can translate customer conversations into new product features or even new products themselves. Writers can do this because they can conjure these tones and emotions in strangers. Writers can identify, organize, and synthesize information for your customers to understand easily.
It’s a red flag to me when I receive bad support. The red flag is always for the company itself. It’s rarely the fault of the person trying to help me. Rather, these situations show me that the management, the company at-large abandoned this person. It’s a systemic failure, not a personal one, due to poor training, poor wages, no stake in the company (cultural or financial), no trust or autonomy. It’s honestly so easy to remedy.
Once you find the right folks (those polymath writers haha), you need to write and maintain effective and thoughtful training documentation that sets your new hires up for success. You need to constantly support your team. That looks different for each person you hire, so you need to get to know each person individually. Employees deserve regular reviews, regular feedback, opportunity to share their feedback, 1–1s, team chats. You need to listen to your team to know where you’ve failed so that you can atone and reconfigure. Let them guide you as much as you guide them. Your support team deserves competitive wages that can support them in a career — support work is not a stepping stone to another career; it’s its own career. They deserve retirement security, paid time off, childcare, healthcare. I could go on. If you want to treat your customers well, then you have to start treating your support staff well. If you value your customers, then you better value the folks who talk to your customers. Otherwise, you’re setting your customers up to fail and waving that red flag.
Once your team is comfortable and confident, you need to start giving them time away from the queue to process all the information customers gave them, to maintain documentation, to teach and interview customers, to learn new processes, to advance their skills.
Each support representative should have their own project for which they are responsible. On our team, each person spends one full day each week on working on Research & Innovation, a kind of Personal Development. They write help documentation, programming documentation, teach classes, interview customers, write blog posts, do social media engagement, learn programming, etc. I don’t decide what each person works on — I help them come to their own decision. This management style gives them a sense of ownership and dedication, a stake in a team so that there would be a true gap, perhaps even a systemic failure, if they left. Your support staff should not feel expendable. Help them feel essential by trusting them with their own passion project. Let your team show you better methodologies, better processes. Let them suggest protocol. Give them ownership in their work.
Try to remember that you started this process. You shifted the culture. You hired the right people, you trained them effectively. Now trust them. If you don’t trust them, then you took a wrong turn. People will soar when given the freedom. They will be grateful and hard-working, dedicated and loyal. They will challenge your company and make it a better place to work. I can’t say the same for robots.
At Basecamp, we’ve been running an initiative called Everyone on Support for nearly five years now. Each person in the company, whether a designer, developer or podcast producer, spends a day every eight weeks or so responding to customer emails. As Emily wrote a few months in, EOS quickly proved its worth: Direct contact with customers gave people a new perspective on our products, first-hand experience of the problems users were facing, and a reminder of what we were all working towards together. Lessons were learned, bugs fixed, and cross-team relationships were strengthened.
And then we got busy. With customer requests climbing, the support team lost some important people, and those that remained developed an unhealthy obsession with “inbox zero”. Our stress was infectious: Folk would turn up to their EOS shifts eager to help and leave deflated because they’d barely made a dent in the email queue. Each of them had a dedicated support team buddy to ask for help, but rather than “bug us” with questions, they’d spend hours down help-page rabbit holes. And on the rare occasions that things were quiet, they got bored because we weren’t leaving them with anything to do.
Something was very wrong, but the support team was too busy to notice. We didn’t have time to check in with each other, much less the people who were joining us for the day. We’d started Everyone on Support with the best intentions of not turning our coworkers into part-time firefighters, but that’s exactly what they became. Month after month, people would show up, grab the kind of requests they’d seen before, respond to as many as they could before their eyes started to swim, and clock off feeling bad because they hadn’t kept pace with the pros.
We hired some wonderful people, and reset our expectations for the support queue. While we took the time to train our new members, we paused EOS for a few months. That meant that we could put our whole focus on training, and take some time to think about how to do all-hands support right. As part of fixing our unhealthy behaviours, we carved out some time for “research and innovation”. I spent that time working out how we could invite our colleagues into the new, healthier space we’d created for ourselves. Here’s what we did, and what we learned.
Clear expectations are everything
Right from the start, we wanted to be clear about what Everyone on Support is. We put together a guide to outline what we expect from our guests and from their buddies on Team OMG (our pet name for the customer support team at Basecamp). A doc called What is EOS? What is EOS NOT?reaffirms our original goals for the scheme and how we’re going to achieve them together. It also reassures folk that they aren’t fodder to paper over cracks in coverage. We’ll work together to ensure their shift will be interesting, useful and fun.
As a bad manager in a previous work life, my initial impulse was to impose a solid structure onto EOS. On their first support shift, each person would respond to X number of login emails, then level up to billing issues, before starting to look at feature requests, and so on. I drew up a detailed syllabus, and asked for help fine-tuning it. Jim pinged me, and we had a great conversation, including the following question:
What does the loosest implementation of this look like? The company as a whole has been moving towards a more structured way of working for a while, but a lot of Getting Real and Rework are about doing less. How can we capture that spirit in EOS? What’s the smallest amount of work we can do to give the most support to the folks doing EOS?
I decided to scrap the syllabus. Using metrics risked the kind of anxiety around speed people had experienced in the past. Being too prescriptive would suggest that there’s only one way to succeed in support. And neither of those things got us closer to our goals for EOS.
I turned my gaze to the work we’d done to onboard the new members of the support team. OMG had done a great job of building a loose framework to support the learning of the newbies, and that felt like a better fit for what we were looking to do with Everyone on Support. I salvaged some bits from the abandoned syllabus, and repurposed them. When EOS would start back up again, everyone would have a collection of resources and some advice on handling common cases.
Basecamp is a company which values independence. The best approach was to give everyone everything they need to succeed, and then get out of their way.
Communication is key
Basecamp’s support team are thoughtful, kind humans. Instead of telling them how to manage their charges, I encouraged them to talk it out, and discover the way that person works best.
I suggested that each EOS day start with a discussion about what our guest supporter wanted to do, and end with a catch-up about how it went:
Your job is to help ensure that your buddy has fun, learns something new and feels good about their shift. Creating the experience that best works for them is going to come down to good communication.
A two-way street
Team OMG is full of good listeners (it’s our job!), and we’re as interested in learning from our coworkers as we are in teaching them. When updating our buddies list, I tried to pair people along shared lines of interest. Time zones made this tricky, but I’ve managed to connect support folk interested in research and product development with specialists in data and design, and the two-way insights have started to flow.
One size does not fit all
When training new OMG team members, we recognise that everyone learns and works in their own way. That’s something we’ve built into our approach to Everyone on Support: for some people, we pick emails that will be of interest and provide hints as to the answers; for others, we leave them to it, and stand by in case they have any questions.
Once someone’s comfortable with email support, it’s up to them how they spend their time with us. If something fits in a single day, and is going to benefit our customers, then it’s a good use of a support shift. People on EOS have squashed bugs, launched customer research projects, improved our internal tooling, leveled-up our external documentation… and that’s just the start!
Everyone on Support is a work in progress, but it feels like we’re going in the right direction. For six months now, we’ve been running a much more chill, cheerful — and constructive — version of EOS. I’m going to keep steering it with a light touch, and check in with people, to see how they feel about where we’re headed. Basecamp’s approach to all-hands support aligns with our values and how we choose to work as a company — so you may not be able to apply everything here to your own initiatives. We didn’t get it right on our first try, and we’ll make more mistakes in the future. It’s worth it.
Do you offer all-hands support? How does your approach differ to ours? Or are you thinking about rolling out something similar in your organisation? And what concerns or challenges are holding you back?
A few months ago, I got this email from a customer:
It would be wonderful if there was a way to tag/assign forwarded emails to specific task lists within client projects. The “email forwards” section is really cumbersome on large scope client projects where we have lots of balls in the air at once.
It’s pretty straightforward. Our app doesn’t have this feature and they would like it to be added. It’s a feature request. Our support team sees a dozen or so feature requests every day.
Deciding how to handle feature requests like this one is tough. Do you track every single one? Are you only focused on some subset?
And most importantly — how do you turn a customer email into something usable for your product teams? That’s the end goal — something usable by others in the company.
Early in our days at Basecamp, we would literally “read them, throw them away, and forget them”.
“It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones. Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget. “ — Getting Real
When you’re a company with a few people in it, it works. Everyone is pitching in to answer customer emails so you’re bouncing into that support queue often. Once the company gets bigger though, that approach doesn’t work as well.
As Basecamp the company grew, and our support team grew, we tried tagging all of those feature request emails.
Idea for the calendar? Tag it. Feature request for the message board? Tag it.
But now what? You can go to the product team and say “We’ve seen a 5% increase in customers requesting a grid calendar. “ But how is that helpful information? Just the raw data doesn’t really help. And our support team couldn’t really put together a story from those tagged emails.
That means the product team has to dig through those tagged emails and hope to see any usable information from the customers in those tag emails. It slows things down at best and at worst, leaves the product team without anything to go on.
There’s got to be a better way, right?
That’s the version I want to share with you today. Here’s how we handle feature requests at Basecamp right now.
When a feature request comes in, we start with this question — where does it fit in Basecamp the product?
From that answer, there’s three general paths forward for that request:
We’re not going to do it — requests like translations, Gantt charts, time tracking.
We’d like to — ideas like Clientside improvements or Dropbox linking. These are ones we’ve built out in previous versions or have talked about a bit before.
We don’t know — ones like turn a message into a to-do, out-of-office setting, more keyboard shortcuts. Maybe we’ll explore them down the road. ¯\_(ツ)_/¯
Path One — We’re not going to do it.
If we’re not going to do it, we tell the customer so. This sets expectations up front and lets the customer know if they need to explore an integration, use a workaround, or consider switching to a different product.
For example, a customer might request the Basecamp UI in Spanish. That’s not one we have intentions of doing so there’s no need to track it, tag it, or anything else other than tell the customer we don’t have plans to do that.
Paths two and three — We might at some point.
For the other two paths, we want more information. As the support team, it’s our job to give the product team enough information to make decisions around building a new feature.
It’s kinda like being a detective. We go out and investigate the situation a customer is when they email us their feature request. We talk with people involved, detail the facts, and then bring all of this back to the product team. Once they know the facts, the product team can start thinking through our options.
I want to take you through an actual customer interview that started with “I need X” and ended with a new feature in Basecamp.
Basecamp 3 launched without a grid calendar. You know, the ones that look like Google Calendar, Outlook, etc. We had an agenda style list view of events in projects. And you could always subscribe to an iCalendar feed if you really wanted to see it in a grid calendar using Google Cal or such. But there wasn’t a grid calendar in Basecamp 3 itself.
Naturally, customers emailed us asking about it, especially ones that had used a prior version of Basecamp where a calendar was included. Each week, we’d see emails asking “Where’s the grid calendar in Basecamp 3?”.
From the product team’s view, a grid calendar is tough. It took us months to build one in the Basecamp 2. With Basecamp 3, it was looking like many months of work, which is way outside of our normal six to eight week work cycle. And customers expect your grid calendar to be as good as all the others out there — so you need color coding, week and day view, invites, integrations, repeating options, event length options, etc.
It’s a lot of work. But we have to build it because it feels like everyone’s asking for it, right?
So let’s investigate! It’s kinda like flipping the detective mode switch. I needed to find someone that needed a grid calendar right then and find out everything I could about what they were really trying to do.
Meet Annie (name changed to protect the innocent). Annie is a psychologist that works with a team doing in-office client sessions as well as field work. She’s used Basecamp for about a month when she emails us.
Hi. I’m wondering if besides the scheduler is there a way to look at a whole calendar that has everything on it at a glance? Like a week at a glance or a month at a glance or even a day at a glance. Otherwise I have to look at each schedule. And I don’t want to have to constantly open my calendar or have to sync each event created by others to my calendar. Help. Much needed feature.
Perfect — I’ve got my first witness in the “I need a grid calendar” case. I set up a call with her to find out more.
Now with the call, it’s structured around the idea of a Jobs-to-be-Done interview. I’m not looking for the feature she’s seeing in her mind. Instead, I want to know everything I can about the situation that led up to her emailing us. I want to know what “job” she needed that grid calendar for. And I want to put all of this on a timeline as best as I can. That way I can say this happened, then this, which made this happen, and that’s when she emailed us.
So we’re on the call.
First question — “what was going on an hour ago when you decided to send us that email with your calendar idea in it?”
Annie said she had just added an event in Basecamp to book a meeting room for a client session. She had to drive into the office to do that.
On our timeline — I’ve added a new piece of information.
Second question — “Why did you drive to the office to do that?”
Annie said she needed to look at the wall calendar to see what rooms were open for that client session. There’s eight rooms. That’s eight open spots a day for clients.
Third question — “Wait, wall calendar? What’s that?”
Annie said they used to have a company secretary that handled client appointments. But for cash flow reasons, they had to let her go. In her place, they tried using Basecamp for client sessions but couldn’t easily see what dates/times/rooms were open. So they painted a 12ft x 6ft wall with whiteboard paint, drew out a grid, and now use it as a calendar for scheduling. They still add the events to Basecamp for the reminders.
Fourth question — “Have you had to do this before — driving into the office to look for an open spot? If you have, what made this time different than the others?”
Annie said she’s done this before but this day was supposed to be her off day. Plus, she was frustrated because she got to the office, looked at the wall calendar, and saw all eight spots were booked so the client would have to wait until next week.
Whew — what a timeline!
Think about that — even though her client meetings were in Basecamp, she had to drive into the office, on her day off, and physically look at this giant 12ft by 6ft whiteboard wall only to find out it was a wasted trip since the rooms were all booked.
I’d probably drop an email to the support team then too.
From Annie’s interview, we found out the feature request for a grid calendar isn’t all about this massive calendar tool. It doesn’t have integrations. It can’t do recurring events. It doesn’t sync with your phone or another computer.
But notice what it does really well — it shows space. It’s all about seeing open spots and how busy things are on a given day. That’s something our agenda list view in Basecamp can’t show you.
But is Annie alone in how she uses this? Or does this happen with other customers too?
Back to the queue to find more witnesses for the case!
When I interviewed more customers, the same pattern kept appearing. Jeff needed to see open spots to decide if his team could fit in new client work that week. Shirley needed to see which designers were available and which were spread too thin.
Through these interviews, we found the job customers had. In their language, it was all about a grid calendar. But once you dig in, it was all about seeing space on the calendar. It wasn’t the need for a full blown calendar app. Just something to see the space.
With those details, we could write up a pitch for a new feature. It was picked up for one of our cycles. A team of three people built out the new schedule in about seven weeks. And it fit what our customers were really needing.
It’s Ongoing Research
For us, these interviews happen each week. Usually 2–3 a day if we can. A feature request email comes in and we try to schedule a call with that customer for the same day. With it fresh in their memory, they can really provide details about the situation and put us in their shoes at that moment.
So that’s how we approach feature requests. Find a customer with a feature request, interview them, repeat those interviews until you can see patterns. With that information, a pitch can be written and then the feature created.
Customer support is a double-edged sword and can be both rewarding and draining. Helping people feels good, but constantly empathizing with strangers can get exhausting. We all hope that the good outweighs the bad, but that’s not always the case. When the scales are imbalanced and there’s stress at and about work, it’s easy to forget that work doesn’t have to be stressful.
Our team answers (mostly) emails and (some) phone calls seven days a week across four continents. Each person works 40 hours a week in Autumn, Winter, and Spring and 32 hours a week in Summer. But, 40 hours a week of nonstop emailing doesn’t allow folks to synthesize the data they just internalized to help guide Basecamp in an interesting direction. How can we analyze feature requests if our energy is zapped at the end of the day, the end of the week? How can we help shape tech support culture at-large if we don’t have time to benchmark or conduct research? Our team is comprised of fourteen badass thinkers with diverse backgrounds, so why aren’t we giving them space to think and collaborate? Finally, how can we introduce more calm into a stressed team?
Over the summer, I convinced Jason and David to let support stray from the 37signals mantra to “hire when it hurts,” which allowed us to hire two people when we thought we were looking for one. Part of my proposal included a schedule that set aside one or two hours per day for each person to work on something other than contacting customers, to be decided by self-selection. When Jayne, relatively new at the time, and I discussed what she could work on during her time off from contacting customers, I encouraged her to use her background as a research assistant to help guide her. That’s how we came up with the name Research and Innovation, or R&I for short.
There’s an element of trust in this type of structure that is essential if your team wants to try this out. Don’t micromanage people’s projects, but do offer suggestions and guidance when asked. I know that each person on the team will spend their time wisely and at their own pace. Ideas aren’t born from ether; they are born from consideration and formulation, research and comparison, all of which require time and space. If someone spends a day formulating an idea, then it was a day well-spent. It’s important not to question that judgment. (If you’re questioning someone’s judgment, then you should also be questioning their position at the company.)
When the time came to execute the concept, we decided to piggyback off our four-week summers: each support rep’s “summer day” during the rest of the year is now their Research & Innovation day. That allows for easier scheduling, gives us an idea of how the summer will look, and provides a full eight-hour shift of uninterrupted focus.
It’s been about a month since we introduced this structure to the team. Some folks do lengthier demos, teaching users. Some create industry-specific accounts to share with users. Some track and analyze feature requests. Some benchmark with other support teams. Some create content for our help documentation. For the record, these were all things we were doing before we introduced R&I. The difference is that instead of squeezing a quick pitch or a fast demo into a ten-minute slot between emails, we can now take our time to do our best work.
Beyond doing our best work, we’ve also noticed a shift in tone and attitude. The team is more involved in the goings-on at Basecamp. We’re happier, more relaxed, with better morale.
One thing that interests me the most is do you have some kind of automatic integration between Help Scout and Basecamp or do you manually write important things in BC?
Why I’m interested in that is because I would like to know how do you associate BC to-do for engineer (if engineer support is needed and if you resolve support issues over to-dos) with concrete customer issue in Help Scout!
With our setup, we don’t have any automatic integrations between Help Scout (the customer support app we use) and Basecamp. Through a few nifty Zapier integrations, you could absolutely set something up like that. But we’ve chosen to keep things a bit more simple for us.
Here’s how we handle interactions between our support team and programmers when it comes to bugs.
Most of the situations we see on a daily basis are one-off problems. Maybe a Doc is acting weird because of some HTML that was pasted into it. Or a file isn’t downloading because something went wrong with uploading it.
For these customer emails, we assign it to an “on call” folder in Help Scout itself. We’ll also leave a note with any info that might be helpful for our support programmers working. From there, they’ll take a look, fix up whatever the problem was, and assign it back. That’s when we let the customer know it’s fixed up.
Sometimes we’ll find bugs and issues that are out-of-scope for the on-call developer team. Those are usually something that’s affecting all of our customers rather than just an isolated person. When that happens, it’s added as a to-do inside Basecamp.
We have a project called “BC3: Bugs” to keep track of them. That project only has one tool enabled — the To-dos list.
The first stop for every new bug is the “Awaiting Triage” list. This allows us to have an easy place to quickly add in new bugs as to-dos.
The to-do name is kept short for easy reference. The notes field contains any details, screenshots, links back to a Help Scout case, or anything else that might be helpful.
From the “Awaiting Triage” list, the bug is then either assigned out or taken by someone that sees one they want to fix. Here’s a full thread where the bug was added as a to-do, discussed, and then fixed.
From the support side, I was notified throughout the process and could keep our customer in the loop. Once Scott fixed things up, he checked off the to-do as complete. Then I emailed the customer with the good news.
It’s in Basecamp!
Keeping it in Basecamp this way means everything is in one place. I don’t have to add a bug to some other app and then link it back to Basecamp. Our programmers and designers only have one place to check for new bugs. Everything’s kept right there in Basecamp for everyone to see.
If you found this article helpful, click that 💙 button below. Thanks!
Finding it tough to keep your support team (or any other team) on the same page? Give Basecamp 3 a shot. It’s a free 30-day trial. Teams simply run better on Basecamp.
An inside look at how our support team uses Basecamp 3.
The Basecamp support team is a fully remote team that spans seven time zones and helps our customers 24 hours a day, seven days a week. It’s tough to get everyone on a team on the same page. It can be even harder to keep them there.
That’s why our team uses Basecamp 3 to stay organized. The tools inside our team space ensures that everyone has answers to questions like “Who’s taking care of Twitter replies right now?”, “What are the common cases we’ve seen this week?” or “Where’s the outline for our online classes?”
With our team entirely remote, it helps to have a place to chat in real time. A virtual water-cooler if you will. Enter Campfire.
Campfire gives us a place to talk instantly about anything that we need to. It’s where we go to ask others about a particularly interesting customer email. Or share the latest Taylor Swift music video. We’ve even had some fun GIF battles there. As shifts come online and then leave at the end of the day, you’ll also see lots of hello’s and goodbye’s said. It’s a powerful tool for making sure that your team feels connected, even if they are on the other side of the planet.
Default away from the never-ending conveyor belt.
While Campfire is great for those real time chats, it’s not designed to be an all-day meeting. For updates and other messages that the entire team need to see, we use the Message Board. We also use it for conversations that need some time to happen, like this one.
Instead of that message being lost in the never-ending conveyor belt of a chat, it’s right there on the Message Board. The conversation happens through comments with plenty of time for each person to think about their answer.
Create space with the Schedule.
For any events related to the team, those go on our Schedule. It can be things like customer trainings or calls, our regular 1:1s, and times that we’ll be out for vacations or other days off.
We also schedule in time to work on side projects or anything else that takes us out of our email queue. By putting it on the Schedule, we create space for each of us. Without that space, your team will end up as queue monkeys trying to get through just one more email.
With the Automatic Check-in tool, we ask everyone on the team a few things on a regular schedule. The check-in allows us to talk about questions like “What was a common issue that you saw this week?” without needing to hold a weekly team meeting.
All of your resources in one place.
Our Docs and Files tool sees a lot of use. It’s our go-to place for our files, the online class resources, our customer ideas, and anything else our team might need. Everything’s organized by topics using the folder option. And a few of those folders even have Readme docs in it to give a person the gist of what that folder is for.
One of my favorite folders in here is the Happy File, an idea we stole from the team over at Automattic. It’s a place to share the love that customers have for Basecamp — the team and the product. Here’s Jeremey Duvall on how it works:
Every Happiness Engineer is encouraged to create a happy file just for them. In that file, they keep amazing [customer] interactions… When they feel down during the day, looking through the file is a quick way to pick themselves back up.
Instead of it being an individual file, we’re trying it out as a team file. Whenever someone has something to share, they start a new doc and put the comment, email, Tweet, or whatever it is there.
It’s in Basecamp.
Remember those questions where we started? It’s a simple answer now — it’s in Basecamp! One place to check who’s handling Twitter replies, what common cases we’ve seen this week, and where that class outline is. It’s our central source of truth for everyone on the team.
If you have any questions about how our team works or want more details on anything above, leave a comment and I’ll do my best to answer!
If you found this article helpful, click that 💙 button below. Thanks!
Finding it tough to keep your support team (or any other team) on the same page? Give Basecamp 3 a shot. It’s a free 30-day trial. Teams simply run better on Basecamp.
Before I worked on Basecamp’s support team, I freelanced as a writer and editor. One of my less glamorous gigs was contributing to a textbook teaching non-native speakers how to write business emails in English. Language stuff aside, I’d be researching emoji or “netiquette” or how tone rarely transmits over text, and catch myself thinking, “doesn’t everyone already know this?”
Now that I respond to emails all day, I can safely say: no, a lot of people don’t know how to write a good electronic message. Because they weren’t taught how. Folks who would never call themselves writers are thrown into a world in which most communication is done through text, and, in many cases, their livelihoods depend on it. Unfortunately, unlike my limited readership, most people aren’t handed a textbook when they sit down to craft emails.
That’s where we come in! Basecamp’s support staff write hundreds of emails a day, and we’ve gotten pretty good at it. At the time of writing, 93 of our last 100 customers were happy with our replies, saying things like “easy to follow”, “quick, simple and to the point”, and “the perfect response”. So I thought I’d take some time to share what we’ve learned about writing clear, efficient, effective emails.
Before I begin, let me say that we appreciate all of your emails, because they mean that you are using our product and either want our help using it better, or want to help us out, by giving us a heads-up about a possible bug or improvement. We treasure in particular messages from non-native speakers, whose English is almost certainly better than our Spanish, German or Chinese. Please keep sending us emails, and if you would like to get really good at writing them, follow these tips.
“Dear Sir/Madam” is how we used to begin communications, back when we had to scratch our messages on dead trees with pointy sticks filled with liquidised vegetables. Back when being formal mattered. Back when we believed there were only two genders, and that it was important to assign a person to one or the other.
That was then, and this is now. Now we say “Hey!” or “Hi”. Or, “How’s it going wonderful Basecamp helper unicorns?”. Imagine you aren’t Writing An Important Letter, but walking up to a stranger and introducing yourself — only you’re blindfolded and can’t see what kind of body the person inhabits. Actually, that sounds kind of scary — forget that. Just be friendly, be informal, be cool.
DON’T USE ALL CAPS
You would think that everyone would know this by now. YOU WOULD THINK THAT.
Get to the point!
Everyone on my team reads upwards of 100 emails a day, more like triple that if you count the ones we scan to see if they’re spam, out-of-office replies or something else that doesn’t need our full attention. So please, get to the point. As quickly as you can.
Say what you need up front (right after your friendly salutation!), before getting into the specifics. Try to let the reader know: here’s what the issue is, here’s what I want you to do about it, and here’s all the info you need to get it done. We all wish we had time to read epic tales sewn through with plot twists and colourful characterisation, but we don’t. Keep it moving, people!
Paragraphs are your friend
There is nothing more disheartening than opening an email to see a dense block of unbroken text. OK, there are far more disheartening things, like war, famine and injustice, but we’re talking about email here. And sometimes email will screw with you, removing all the formatting and mashing your carefully-chosen words into a single stream of consciousness. You can’t always control the output, but you can be mindful about what you put in — and aim for it to be as legible as possible.
Use paragraphs. Even better, make every paragraph a single sentence, each of which makes one discrete point.
That’s how I write most of my emails now, because this way they’re most easily understood.
I’m doing it right now — doesn’t it look nice?
Writing this way forces you to consider everything you’re setting down.
Think about the person on the other end, the person who has to read this, and ask yourself:
Could this section be clearer or more concise?
Should that part come before or after this part?
Do I need to include this at all?
Try to avoid this:
And aim for this instead:
Don’t tell us it’s urgent
You know how we feel about “ASAP”. If you’re writing to Basecamp support, we’ll get back to you in a matter of minutes, because we want to keep you happy and productive. And anyone else you contact will be working to their own set of priorities. If you’re up against a specific deadline, or you need this thing dealt with before you can do that other thing, by all means say so. But words like “immediately”, “URGENT” or (ew) “ASAP” aren’t going to speed things up.
So far, so prescriptive. But writing is always personal. It’s your voice, and we want to hear from you. So forget everything you were taught in Business English 101 (but remember everything you learned here 😉) and drop us a note from a living, breathing actual human. Ask us to “take care of” something, rather than “actioning” it, and we’ll respond in kind — with the real words that real people use. And probably an emoji or two. 👍
Attach photos of your pets!
This is special advice for when you email Basecamp. Your CEO or divorce lawyer may not appreciate an attachment of your dog in a Halloween outfit — unless they’re really cool. But, no matter what size or shape of animal you have, we want to see it! There are times when you need to be strictly business, and there are times when you need to sign off your correspondence with this:
Happy emailing — we look forward to hearing from you 🙂
When I’m at work, I’m my best self. I’m positive, patient, helpful, curious and considerate. I tap seemingly bottomless reserves of empathy, and drip, drip, drip kindness out to customers and colleagues. I’m resourceful and flexible, bending over backwards to solve people’s problems. I take pride in exceeding their expectations. I listen to criticism, but try not to take it to heart, and I show up ready to make a difference to someone’s life, day after day after day.
But when I close my laptop, something changes. By the time I’m done working, I’ve usually had enough of other people. The last thing I want is to be around other humans, listening to their problems, responding to their requests. I forget to call my mum. I miss my friends’ events. I complain about going to buy ice cream for my wife — something I actually love to do — because I don’t want to be asked for. One. More. Thing. I open Twitter and get into fights with trolls, then turn around and troll others. In my downtime, I’m antisocial and cynical; I’m lazy, sloppy and thoughtless.
What if it doesn’t have to be this way? What if the me who makes customers happy all day could continue to spread cheer through his private life? If switching off from work didn’t have to mean switching off the parts of my personality I’m tired of exercising — all the nice parts. What are the things I practise in customer support that could make me better at supporting humans in general, and myself in particular?
I have a plan for being my best self, even when I’m not being paid to do so, when I’m not being monitored and given feedback. You know, when I’m “just” living my life. Here’s what I’m going to practise — and what I’m going to listen to, to get me in the mood:
Just do it
If a customer writes me an email, I respond in a matter of minutes. If they want to talk on the phone, I’ll call them as soon as I can. My goal is to resolve their problem as quickly as possible, with the bare minimum of back-and-forth. But if someone calls my personal phone, there’s little chance I’ll pick up; zero chance if I don’t recognise the number. I hardly ever listen to my voice messages, let alone return those calls. I don’t pick up my mail, and it’s returned to sender. In my office there’s a patch of wallpaper I’ve been waiting for months to strip. Well no more. Whatever needs to be done, I’m going to… just do it.
You’re gonna wake up and work hard at it You’re gonna wake up and stop giving up You’re gonna wake up and just do it
It’s easy to forget that, on the other side of that phone call, email or tweet, is another person, made up of flesh and blood, and faults and feelings. Good support pros keep in mind, and occasionally remind their customers, that we’re all human here, doing the best we can in sometimes frustrating situations. I’m going to try to speak to people online with the same courtesy and respect that I would if we were face-to-face. Even if I disagree with them, no one deserves to be disrespected, demonised or dehumanised. We’re all human, after all.
I’m only human, I do what I can I’m just a man, I do what I can Don’t put your blame on me
My team practices something called noncomplementary behaviour. That’s a Psych 101 term (beautifully illustrated by this Invisibilia podcast) for meeting anger and frustration with politeness and positivity, leading the conversation in a more constructive direction. Don’t feed the trolls; have a cup of coffee with them. Some people can’t be helped, but others will benefit from a little listening, understanding and empathy. I’m going to be the disarming, charming(!) person Basecamp expects me to be, and make life more bearable for everyone, myself included.
The killer in me is the killer in you My love I send this smile over to you
Let it go
In life, especially online, it pays to pick your battles. We waste so much time and energy fighting with people whose beliefs we have no hope of changing — and I’m as guilty of this as anyone. While supporting customers, I’m empowered to help them and address their concerns, but there is a fair amount of frustration and criticism I let wash over me. Outside of work, I’m practically powerless, and vulnerable to stronger and more personal attacks. I’m going to stop taking it personally, make a positive difference wherever I can, and let everything else go.
Let it go, let it go Turn away and slam the door I don’t care what they’re going to say Let the storm rage on The cold never bothered me anyway
At Basecamp, we take self-care very seriously. We’ve invested in health benefits for employees; we’ve created a Basecamp for that. Over the years, I’ve become better at caring for myself, and worse at caring for others. With all the terrible things happening in the world, it’s easy to feel hopeless, and my way of coping has been to detach, and exist in a state of blissful ignorance. But part of my job is to empathise with people, to care about what they care about, and by doing so, help make their lives a little better. I’m going to invest myself more in others, in their passion and their pain, and see if I can inject a tiny bit more love into the world.
I know you’ve been hurt by someone else I can tell by the way you carry yourself But if you let me, here’s what I’ll do I’ll take care of you
I’m going to try and break down the (otherwise healthy) separation between my work and my life, and let the good habits filter through. I’ll hold onto that positive attitude past 6pm, and see what else I can apply it to. It’s going to take work and thought, practice and commitment. But it’s going to help me live my best life. Why not join me, and let me know how it works out?
If you’ve read this and thought, “I do that anyway”, then you might be perfect for Basecamp’s support team. We’re hiring someone in the US to help care for our customers, and resolve their problems with a considered response and a smile😀. If this sounds like you, then apply to join one of the world’s best customer support teams here.
I’m writing this on a sunny Sunday afternoon. Here in beautiful Berlin, most of my friends are enjoying a lazy start to the day, having returned from the club, bar or all-night pop-up kombucha stand just a few hours ago. Maybe some brunch, they’re thinking, followed by a stroll along the canal. Do they have everything they need for a barbecue? Or is this one of those curl-up-in-the-duvet-with-delivery-pizza kind of days?
Not for me, it’s not. I haven’t had one of those weekends in a while. I’ve been supporting Basecamp’s customers from 9am to 6pm Central European Time, every Saturday and Sunday — give or take — for two and a half years now. While everyone around me slowly stirs to life, I’ve been at my desk for four hours and, after lunch, I’ll have another four to go. And you know what? I’m happy to be here.
Working on the weekend isn’t anyone’s idea of a good time, much less working every weekend. When I was being hired, everyone I spoke to would double-check, “are you really sure you’re fine with a Saturday-Wednesday schedule?” Each time, I would reassure them: it won’t make much difference to me. I came to Basecamp from a world of freelancing that has little respect for working hours, and I expected to find a better quality of life sticking to set shifts, no matter when they fell (I was right).
Now I’m the one doing the double-checking. My team’s undergone a bit of a reshuffle, and I’m moving across to cover weekdays. We’ve already found an awesome replacement for my shifts, and in doing so, we asked again and again: are you willing to work weekends indefinitely, and do you have any idea what that really means? I only gave my thumbs-up to candidates who could convince me that they understood how hard working those shifts might be — and that they could still see the upside.
What upside, exactly? Anyone who’s had to clock in outside of regular office hours knows it can be a bummer, and everyone else can easily imagine the drawbacks. But until you’ve done those shifts for an extended amount of time, you may not realise that many of the all-too-apparent negatives are actually super-secret positives. Here’s how to turn your Sunday smiles upside down, and make the most of your weird work schedule:
Reap unexpected rewards Basecamp isn’t just a business tool — it can help anyone organise whatever they need to get done. The weekend is when the professionals put down their tools, and everyone else tries to get their personal projects off the ground. Every now and then, I speak to someone who doesn’t really understand computers, for whom the cloud is a mystery, and who has set aside their Sunday to get their heads around “this Basecamp thing”. People like this can be a challenge to work with, but getting them up and running is especially rewarding.
Turn isolation into independence Curiosity is a requirement at Basecamp — we expect everyone to work out the solution to whatever problem they face (and, of course, to ask for help when they’re stuck). However, when everyone else is online, it’s easy to get lazy, and rely on more experienced support staff, and the people who built Basecamp, for answers. On the weekend, I don’t have this luxury. Outside of emergencies, any answers that our customers need are going to come from me. I’ve learned more, and helped more people, by hunting down my own answers than I have by tapping others on the shoulder.
Bond with your fellow weekend warriors Basecamp literally wrote the book on remote working, and one of its important lessons is “Thou shalt overlap”. When you’re about to spend the next six hours on your lonesome, you learn to make the most of the 60 short minutes you have with your fellow weekend workers. When I jump online to say hi to Sylvia, who’s been running things from Hong Kong, the Campfire chat room soon fills up with dad jokes (mine), dog photos (also mine), squeals of delight (hers) and music recommendations of varying tastefulness (both!). Of course, we’ll still overlap a few times a week, but when we do, we won’t be anywhere near as desperate for human contact. Boo, this one’s for you.
Maximise your quiet time As soon as Sylvia logs off, things really quiet down. On a typical Saturday or Sunday, I respond to half as many support emails as I do on a weekday, and far fewer tweets and phone calls. This gives me time to do less urgent, but no less important, things like pitching new features, updating our internal documentation, organising my replacement’s training — and writing blog posts like this one.
Make the most of your✌🏽weekends✌🏽 My most cherished quiet time comes after I clock out on Wednesday evening. Because Basecamp believes that Work Can Wait, I’m left to enjoy this downtime free from distractions, except in the case of emergencies like a bowl of noodles Sylvia really needs me to see. When everyone else is at work, I can choose from my pick of machines at the gym, set a leisurely pace at my local brunch spot, get a whole row to myself at the cinema, or do the weekly shop while the aisles are empty. Best of all, as the people around me are gearing up for the weekend, I’m getting ready to return to work. Which is when I tell myself…
Remember: you have the best excuse ever “I’m so sorry I can’t come to your vernissage-slash-electro-swing-party in that disused sewer pipe — I have to work in the morning. Maybe next time!”
Of course, I’m happy to be getting my “real” weekends back. But I’m glad I got to experience what it’s like to support different kinds of customers, at different times, with different needs.
As for my weekend warriors, hold strong! Make the most of the quiet moments, in and out of work. Take the extra time to hold your customers’ hands and lead them across their own personal obstacles. And support each other — be that rare ray of sunshine in your colleague’s working weekend. Wherever the weekday work takes me, I’ll be here for you!*
*Except on Saturday mornings, when I’ll be having a nice lie-in.
Basecamp 3 can help you organise whatever you’re working on, whenever you choose to work on it. Check it out now at basecamp.com.