Providing customer support with copywriting allowed my company to run a web service that handled nearly 30,000 email entries. Great customer service is a highly personal process, but, of course, nothing says great customer service like a fantastic product. Here are 4 lessons every business should know for providing customer support:
- Explain your service using the fewest possible words — every piece of detail is an opportunity for confusion.
iDoneThis is an email-based productivity log. At the end of every day, we email our users and ask them what they did that day. To make an entry, they just respond to our email.
From the start, we included a line in our email which we used to split the original message from the user’s input. Our daily emails used to look like this.
————————————i done this—————————————
Howdy! Take 30 seconds to write out what you got done today.
Today is day zero. Clean slate.
But remember the ancient wisdom — a journey of a thousand miles begins with a single email.
Put each thing you did on its own line
Everything you write above the dotted line gets saved.
We kept a calendar for you.
To unsubscribe from the daily email reminder, please email us at firstname.lastname@example.org
To our surprise, the dotted line instruction confused our users. Many of them didn’t know what the dotted line was, especially because email clients insert dashed lines into reply text. Other users didn’t know what to do with the dotted line. A few copied the dotted line, deleted the reply text, pasted the dotted line, and wrote above it. Others wrote their entries directly above the dotted line but below the envelope information for the original message. That worked, but resulted in a far bulkier UI than we’d intended.
It became clear to us that reference to the dotted line alone confused users because it led them to believe that they should do something other than simply reply to our email. On April 5, we got rid of reference to the line completely, but we wanted to make sure that users wrote their replies above the dotted line, lest they check their calendars later and find empty entries. We instructed users to “[w]rite [their] reply above our message.” The judgment on our new language came back swift and hard.
Hi I did get an e-mail but, but could not type in the———————-space help!
I can’t figure out where to enter my what I did info. You say above your message,but that’s not working.And I guess ya can’t write in the calendar square. Help,please.
I am unable to write in you e-mail.
I wuill have to unsubscribe from your service.
Good luck to you.
I like this idea…just don’t know how to see what I’m typing. Please, help!
I am a new subscriber. I use Firefox 4.0 for my mail. I am unable to get a cursor to appear above the ——i did this—-line. I’ve tried the arrows, select all, tried to erase the ——i did this——- line, etc. What should I try now?
no where on/above your message am i allowed to type anything. what gives?
The next day, we changed the language to read: “Just reply to our email to make an entry.” We’ve had 0 support emails since.
- Use help documentation to handle corner cases.
In early April, one user wrote to us, “[L]ove the interface you have. Simple, uncluttered, and just what’s needed. Heck, you don’t even have a FAQ [iDoneThis] is so easy [to use]!” A day later we had to write a Help section to stave off early-onset carpal tunnel.
Explaining your service in the fewest possible words means handling the corner cases with copywriting outside of the main user interface flow. For instance, it’s a corner case that a user will write his reply below the original message — the vast majority of people write their replies above the original message — so it should be left out of the primary set of instructions. But if you don’t handle corner cases somewhere, you’ll either continue to receive support queries or lose users for unknown reasons.
After we changed our copy to instruct the user to just reply to our email, we did see a small uptick in queries about entries appearing blank. We handled that issue in our Help documentation and that issue disappeared.
- Users won’t read most of the words you write—understand how context shapes meaning.
We had a major usability issue in onboarding our users: after the user signs up, there’s nothing for the user to do until the evening when she receives the first daily email. Initially, after signing up, the user went straight to her calendar with a message at the top that said to wait until the evening.
Unused to having nothing to do after signing up for a website, users told us that the site was broken because they didn’t have a way to input their entries directly into the calendar or by email. “I don’t understand how this site works,” two users echoed.
We unabashedly looked to OhLife to solve the problem. OhLife is an email-based diary with a gorgeous and simple interface which had a similar usability pattern. (Users get a daily email asking them to write a diary entry for that day.) They have a welcome page that explained how to use the product and sent the new user their first email soliciting the first diary entry immediately upon signup.
We split the baby in the worst possible way — we welcomed the user with a welcome email which instructed him NOT to respond but wait until the evening for the first email to which he could respond, and in the browser, the user was taken to his blank calendar page which again included the directions to wait until tonight to do anything.
Our new users told us this was dumb — by emailing email@example.com with what they had done that day. My own mother did this. We failed to onboard 6 out of every 100 new users in this way. The flow didn’t make sense: Sign up -> empty calendar page with the instruction to respond to the evening email -> and then an email from us shows up in the inbox.
This showed us the power of context in circumscribing the effectiveness of copywriting. We changed around the words in the welcome email to make it more clear that the user should not respond to that email. But while the words in the welcome email were clear, their context strongly suggested a different action. We repeatedly told our users to expect an email from us to which they should respond, and then an email showed in up their inbox.
The support emails continued to flow in until we nixed the welcome email and replaced it with a welcome web page. The semantics made sense — web pages said that they weren’t editable, and they weren’t editable; emails said to respond, and they were respond-able.
- Include help text on every single page.
Users don’t read most of the copy, so it’s a good rule of thumb to repeat yourself and include help text on every single page. On our main page and our welcome page, we tell the user that iDoneThis is email based, but we still received 6 emails per 100 new users asking us how to make entries via the browser. We added a paragraph to our Help section again explaining that entries could not be made through the browser and we still received support emails.
Finally, we added help text to the calendar page itself — an obvious solution, really, but one we initially perceived as inelegant — and the support queries went from 6 per 100 new users to zero.
Today. The number of support emails we receive per 100 new users has dropped to nearly zero.
The lower volume means that we can give great customer service to those that do request it. The support emails that arrive in our inbox these days are for known and unknown bug fixes, not usability questions. That frees us to focus on the most important aspect of customer service — building a great product.