The company went from 500 customers to 6,000 in about a month, the post explains, and predictably the burden of customer support skyrocketed while the number of employees held constant.
"We saw our support e-mails explode from 23 total requests between January and late March to about 300 over a two-week stretch at the beginning of April," the company says.
How did the iDoneThis team respond? They took a long, hard look at the words on their website and e-mails. "We knocked our support e-mail volume down from as high as 16 per 100 new users to zero by becoming better writers," declares the post, before going on to offer four tips on how you can manage a similar feat.
"Explain your service using the fewest possible words--every piece of detail is an opportunity for confusion."
In the post, the iDoneThis team explain how they tried out three versions of an e-mail they send to their customers explaining how to add completed to-do items to their calendars and discovered something counter-intuitive in the process. Offering more detail didn't eliminate questions, it increased them.
As a result they whittled their original e-mail of a dozen lines or so down to one that simply read: "Just reply to our email to make an entry." They've had exactly zero support emails since.
"Use help documentation to handle corner cases."
Sure, you should keep instructions as brief as possible as per tip one, but that doesn't mean you can get away with not explaining things more thoroughly elsewhere. Just keep that extra information for the befuddled separate.
"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," says the post.
"Users won’t read most of the words you write--understand how context shapes meaning."
No matter what you say, if the user's intuition about a product tells them something different from your instructions, they're going to ignore what you write. This is sort of like making the largest button on the TV do anything other than turn it on: if you mix your visual and verbal signals you're going to confuse people.
For the iDoneThis team, this means that when new users sign up to an app that they know accepts completed to-do items via e-mail and receive a welcome email, they're going to reply to that email with completed to-do items. Even if you say in huge, bold, capital letters that it is simply a welcome e-mail and users shouldn't reply, they still reply.
"The support e-mails continued to flow in until we nixed the welcome e-mail 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; e-mails said to respond, and they were respond-able," the team concludes.
"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 e-mail 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... and the support queries went from 6 per 100 new users to zero," explains the post.
JESSICA STILLMAN is a freelance writer based in London with interests in unconventional career paths, generational differences, and the future of work. She has blogged for CBS MoneyWatch, GigaOM, and Brazen Careerist. @EntryLevelRebel