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

Signal v. Noise: Support

Our Most Recent Posts on Support

Why would you want to call me?

Sarah
Sarah wrote this on 114 comments

I spent almost 45 minutes on the phone with my bank today because of an error with their online banking. I didn’t want to, I had to, after their email support told me my issue couldn’t be handled online. It was such a mind-numbing, protracted, time wasting experience that it made me ask myself, “How can anyone ever ask us why we don’t offer phone support?”

In a perfect world, calling a business for help would be quick, painless, productive, and human. But it’s not and it’s not going to be. That old time ideal of calling the local retailer or company and talking with someone after two rings was demolished by the call centers and overseas help desks that sprung up in the information age. It’s time to stop thinking that phone support is so essential. We’re lucky that we have an email support system that works and is incredibly efficient considering the volume of customers we interact with daily. It works because we’re committed to making it work, and if we can do it every company with a mailserver can do it too.

Now, I know people want to pick up a phone and talk to a live human being. We all want assurance that our money is being spent on something maintained by human beings who speak our language and hopefully live in our same country. I get that instinct, because I share it at times. I also totally and completely understand some people’s experience with email tech support is way too techy, unreliable or frustrating and dialing an 800 number is an escape from that. What I don’t get it is why a person would rather sit on the phone for however long it takes – maybe 45 minutes!!! – rather than send an email and go about their life while it’s read and replied to.

Phone calls require you to stop what you’re doing, go to a quiet place, and concentrate. It requires waiting on the line, listening to hold music, being transferred and possibly having the call lost, all so you have to start over again. You can’t share a phone call with your colleagues, you can’t get someone else’s input or feedback.

Emails can be printed out and saved. They can be sent to someone else who can chime in on the thread. They’re a historical document you don’t have to copy down hurriedly while information is spewed out to you. They can be sent quickly, tagged, labeled, archived. You can send an email whenever you want, there’s no business hours to abide by or schedule to confer with.

We get requests every day from people who don’t think email support will cut it and demand a phone number to call us. Their worries are assuaged when they get a reply from me in less than 15 minutes that is informative, helpful and obviously written by a human being. It’s absolutely 100% possible to provide excellent customer care without a phone or phone number, and our company proves that daily.

[Design Decisions] Basecamp support request form

Matt Linderman
Matt Linderman wrote this on 35 comments

We recently added a support request form to Basecamp (there used to be just a direct email link). The goal of this form: To prioritize support inquiries, reduce uncertainty, and get people the answers they need faster. It also reduces the number of back and forth information-gathering emails, which ultimately makes everyone more satisfied with the support experience.

It’s worked really well so far too. But the last question in the original form was missing the mark:

orig pulldown

We wanted to know how important the problem was and gauge the emotional state of the person writing to us. But this pulldown just didn’t cut it.

First off, it required too much reading for a pulldown menu. Who wants to process this much info when there’s a problem? Also bad: It’s a pulldown but the options aren’t mutually exclusive. Someone could very well be confused AND worried AND upset. This pulldown just muddies the waters.

So we decided to change it to an actual scale. 1 = not a big deal, 4 = I need help ASAP.

newer pulldown

Much easier to process but it still wasn’t helping us learn whether or not this query was a top priority or not. Why? Because everyone’s problem is urgent.

For example, let’s say someone’s having trouble uploading a file. If they can’t figure out how to upload a file, they’ll say it’s urgent. If file uploading is broken, they’ll still say it’s urgent.

That’s no help to us. Of course, we’ll get back to them either way. But if file uploading is broken, we need to know that immediately so we can fix it. If it’s just confusing someone, that’s a different ballgame. We’ll still quickly resolve the issue, but it’s not a fire that has to be put out instantly.

We thought about adding in a radio button question that asked “Is something broken?” But we didn’t want to make the form any longer. (No one likes feeling interrogated while seeking help.)

So we went back to the drawing board and came up with this solution:

type

This gets at what we really want to know here: What kind of problem is this? We lost the subjective nature of the original “give us your emotional state” question and replaced it with a clear question with a clear answer. It’s better to ask for facts than emotions.

Now, if something’s broken, we can spot it and fix it right away. A system failure is much more important to us (and our customers) than a feature request or general feedback. This method lets us prioritize these queries accordingly, instead of treating them like they’re all the same.

Update: Per feedback on this thread, we’ve adjusted the menu to the following (more consistent language, no more “general feedback” category since “other” is close enough). Thanks for your comments.

i pulldown

Related: Copywriting is Interface Design [Getting Real]

Behind the scenes at 37signals: Support

Matt Linderman
Matt Linderman wrote this on 13 comments

This is the fifth in a series of posts showing how we use Campfire as our virtual office. All screenshots shown are from real usage and were taken during one week in September.

CampfireWe use a separate room within Campfire to discuss customer support issues. This helps us keep all these related conversations in one place and keeps the main room (fairly) distraction-free. Again, the ability to quickly share screens is a killer feature here. Let’s take a look…

Turn a customer support query into a site change
Jamis deals with an admin setting problem and Ryan suggests a confirmation dialog change. Jamis plugs it in and Subversion reports the update. one week in CF

Upload a problem screen submitted by a customer
Sarah Hatter helps out on a lot of support queries these days. Here she uploads a screen sent in by a customer and asks for advice on how to solve the issue. (Skitch is a helpful tool for marking up and sharing screenshots quickly.) one week in CF

Continued…

Lessons from T-Mobile's support

Ryan
Ryan wrote this on 45 comments

A few years ago I switched from Cingular to T-Mobile because Cingular’s customer service stunk. My experience today was another proof that I made the right choice.

Late Saturday night my beloved Samsung T509 had full signal in my apartment, but I couldn’t place or receive any calls. Heading outside, I walked six blocks before my calls would go through. Some kind of cell phone black hole was centered right on my apartment. What a bummer, especially when you’re trying to order pizza without a landline.

So the next morning I went out for brunch beyond the boundary of the black hole. I called T-Mobile with a forkful of chilaquiles and expected to wait on hold. Much to my surprise, T-Mobile doesn’t make you wait. They take your number instead and call you back. Three minutes later, my phone rang. The girl on the other end was friendly, listened to my problem, apologized, and told me she’d send an engineer asap. She couldn’t promise a response before Wednesday due to New Years, so I crossed my fingers and hoped for the best.

Today my comatose phone gave a familiar chirp. T-Mobile had texted me this message:

An Engineer has reviewed your trouble ticket and a resolution has been found. Thank you for choosing T-Mobile.

After making a few calls and dancing around the room, I had to reflect on this. T-Mobile nailed this support experience from the beginning through the middle to the end.

1. I never had to stand in line
Waiting on hold sucks. T-Mobile knows it so they gave me another option and called me back.

2. The agent cared about my problem
The girl on the line was kind, attentive, and apologetic. She made me feel like it was their problem and their responsibility. Which is exactly what I want as a customer. She also promised an update by a specific date, which eased my uncertainty.

3. When the problem was fixed, I heard it from them first
I received a text message as soon as my service was restored. That little victory SMS taught me that when they have downtime in the future, I can trust they will work quickly and notify me when it’s fixed. It’s so frustrating to repeatedly pick up the phone every half hour to see if it works. Thanks to their communication, next time I can relax and wait for the good news.

Kudos to T-Mobile for the good example.

Red Hat: If we ship it, we support it

Matt Linderman
Matt Linderman wrote this on 3 comments

Red Hat Enterprise Linux 5 recently launched with a streamlined, cut-through-the-crap service-level agreement (SLA). The old version was seven pages, the new version is one page (competitor Novell’s is 36 pages). According to Red Hat, the new SLA eliminates legalese and offers “no questions asked” support on anything it makes.

With one fell swoop of a presentation slide, [Red Hat vice president of support Ian] Gray took the nine-page document that accompanied Red Hat Enterprise Linux 4 and turned it into a one-page affair meant to simplify a customer’s service experience. “If we ship the bits, we support the bits,” he said. “No more legalese.”

In the old SLA’s place was a “production support scope of coverage.” While technically an SLA, this one-page document now says if Red Hat made it, and it’s production-ready, then Red Hat will support it—no questions asked.

sla

Plus, the company is simplifying support for customers too. It is creating the Red Hat Cooperative Resolution Center to solve problems even when they come from partner products.

In addition, Red Hat created a support center called the Red Hat Cooperative Resolution Center. The center will work to solve issues whether they arrive from Red Hat technology or a partner’s applications, executives said. With this center, Red Hat will take sole ownership of inquiries for any partner’s product that runs on RHEL 5, regardless of whether the problem lies with RHEL 5 or the partner’s product. It’s important to note that Red Hat says it isn’t just covering vendors like Oracle, but all of its partner applications as well. According to Red Hat, its support technicians will accomplish this by working with the support staff of a customer’s vendors to solve a problem.

Kudos to Red Hat for seeing things through their customers’ eyes. Customers don’t care who/what caused the problem, they just want it fixed. When multiple technology providers are involved, it’s nice to know you can count on someone to get it done rather than shift the blame. [tx ED]

On Writing: Managing disaster at Freshbooks, Dreamhost, Dancing Trees

Matt Linderman
Matt Linderman wrote this on 34 comments

[“On Writing” is a new category of SvN post that offers examples of interesting online copy.]

Freshbooks responds to downtime
It’s easy to provide great service when things run smoothly. Handling problem situations is a much tougher — and often more important — test. Freshbooks’ Up and Running blog post is an example of how to do it right.

The company experienced a hardware failure which resulted in downtime and some loss of data. Bad news for sure. But the company’s response, including a detailed explanation and a free upgrade for all accounts, defused the situation and turned a negative into a positive.

Especially nice: the clearly titled sections that explain the problem, what caused it, what they were doing about it, how to tell if you were affected, what to do if your account was affected, and an apology.

For anyone who was inconvenienced by the interruption of service and/or irretrievable data, myself and the entire FreshBooks teams are deeply sorry. I want to extend our thanks to those of you who called and emailed to enquire about the problem. To a person, everyone was polite and understanding, which under the circumstances, was greatly appreciated by myself and the other FreshBooks staff who were hard at work bringing the service back online.

The result? Impressed customers who left raves like these:

Thanks for the open communication and commitment to quick resolution during this ordeal.
I for one greatly appreciate your detailed information, acknowledgement of the problem, and your willingness to provide your clients with some perks to make up for the inconvenience. Outstanding customer service is very hard to come by nowadays. I am a new trial FB user who is now sold, if I wasn’t already!
I appreciate the honesty, dedication and commitment on the part of the FreshBook staff.

Dreamhost’s anatomy of a(n ongoing) disaster
Dreamhost handled a similar rough patch with a long explanation peppered with tongue in cheek images of disaster scenes. The level of detail is impressive though it’s probably a good idea to offer some sort of Cliff Notes version for people who don’t want to read through that much text.

Our number one priority right now is getting this nagging network problem understood and fixed. Once that’s the case, we should be able to put things back in Alchemy, who didn’t lose power on Friday at least. Once things are going good there, we’ll be able to add new servers and transition old ones slowly with little to no downtime.

We’re also going to be buying our own UPSes, since we have learned we can’t trust our data center OR our building to do it. We’ll start by putting the core routers on them, then our internal databases and servers, then our file servers, and finally the hundreds of customer mail, web, and database servers.

Continued…