Writing beginner level tutorials. Great tips about what to consider when writing tutorials aimed at beginners. My favorite nugget is, “[people looking for help] won’t be searching for the solution – they’ll be searching on keywords relating to the problem.” (via Daniel Bachhuber)
Tag: support
The Front Line
After we write and ship code that probably contains a bug or two (or three), our job is to then write more code, which will also contain bugs. It’s a bad cycle.
This means that someone has to be in the middle, as the face of Flickr, acknowledging these mistakes and going to great lengths to fix things. This is often a thankless job, as users just want their problems to go away and developers (usually) don’t like to be told they messed up. But they do it for the good, and for the love, of the site. Every bug that gets filed and every support case that gets carefully answered makes the site that much better.
After being a liaison between these two worlds long enough, you end up knowing more than anyone else on the team. When you have millions and millions of users that hit every button and link in combinations you would never dream of, then reporting the “interesting” outcomes of their explorations, these support agents become walking encyclopedias of the ins-and-outs of the site and with Flickr, there are odd edge cases waiting on every page. Having people on your team aware of everything the site does is huge. You literally can’t buy that or replace it or outsource it, though it appears that Yahoo thinks it can.
Nolan Caudill – The Front Line. (via MK)
Avoiding easy
When you spend all day working with the same piece of software your definition of what is easy for someone else becomes horribly skewed. Since I started jamming with the CoPress gang in 2009, I have spent thousands of hours staring at a WordPress dashboard. It means much of the WordPress interface is easy for me. That’s dangerous.
I try to minimize the number of times I use easy in a support reply. I avoid phrases like “Setting up custom menus is easy…” or “Writing a new post is easy…” There are a few reasons for this.
First, if a feature or product were legitimately easy the user would not be writing in to support about how stuck they are. Sure, some percentage of users will find questions to ask about any interface. But do you want to start the conversation by assuming the user falls into that percentage? You venture to learn much more if you assume the software is wrong, not the user.
Second, describing something as easy sets a dangerously high bar for the user when they walk away and try it for themselves. Before you characterize a feature as easy you should be certain it actually is. If you say “easy” and the user does not get it they will, at best, feel like they are wasting your time and, at worst, feel like it is not worth using your product.
Finally, the worst part about saying a product is easy is that it immediately starts the conversation by putting you in command. You are the expert. You are the one who said it was easy. In some cases that is okay. It will work out. But doing so shuts down your opportunity for learning from your users. If, instead, you think back to the days when you did not know everything, you can start the conversation on an equal ground. Help the user accomplish their goal but also learn about where the pain points are so that you can make the user’s experience, and your product, better.
The best support is a conversation. The best support happens when a user learns how to do something new and you learn about how your product can be better. This can only happen when you do not immediately think of your software as easy, intuitive, or simple. If you can remember that you too were once new to things you will end up with a better product and, most importantly, happier users.
A complete list of open source help desk software packages. This is cool. Now, how can I find the time to test and play with all of them…
Amazon and customer service
How in the world can these two paragraphs actually exist in the same article?
The company’s customer service—which Mr. Bezos later called “the cornerstone of Amazon.com”—started with the founder himself answering emails. By 1999 it was manned by 500 representatives packed into cubicles and answering customers’ questions.
The people handling these emails were generally overqualified and underpaid, with no experience in bookselling. Disaffected academics were popular because they were well-read and could supposedly help find books on a huge variety of topics. They were paid about $10 to $13 an hour, but with the possibility of promotions and stock options dangled before their glazed eyes. The best of them could answer a dozen emails a minute. Those who dropped below seven were often fired.
Absolutely nothing about that second paragraph says “cornerstone of Amazon.com.” If that’s how the cornerstone of the company is treated I’d hate to see what the other teams at Amazon have to put up with.
The quote is from Jeff Bezos of Amazon: Birth of a Salesman by Richard L. Brandt in the Wall Street Journal. Also, it’s atrocious that a writer can put those paragraphs next to each other without calling Bezos on what is obviously a ludicrous assertion.
How Tumblr Hired Its 3rd Employee. Cool little story about how Tumblr hired Marc LaFountain, their 3rd employee and head of customer support.
Personal recommendation of support documents
Earlier today Daniel posted this idea:
Prioritize frequently asked questions on an external facing documentation site based on how often the questions get asked in support tickets. Show the number of times a given question was asked this month as a way of indicating to the customer that the answer probably already solves their question.
It gave me a quick idea to jot down: personal recommendations for support docs. The idea would be to take something akin to the Like button on Facebook or WordPress.com but turn it into a way for users to say “This doc answered my question.”
Really low friction interaction is the goal. One click should register whether it helped the user and then display their Gravatar next to the doc to show that it worked for them. In a way this would be turning the vetting of documentation into a user-facing feature.
The data would be public. Having a publicly displayed list of those users whom the doc has helped may convince future users that the answers are found in docs. Sort of a “Oh look, it worked for these 150 people, maybe it’ll work for me” scenario.
To take it to the next level you could aggregate a list of vetted docs for each user. This way they could look back and see which ones they’ve found answers in before. Maybe they have a repeat question and you just saved them half an hour of searching.
A new WordPress.com support homepage
At the Happiness meetup in St. Louis earlier this month a few of us started working on a redesign of the support documentation homepage for WordPress.com. It saw the light of day yesterday.
Ryan at WPCandy even wrote a short post about it. In it he writes:
It’s not often that support, or documentation in general, is given much attention — let alone redesign attention.
The mini-project was a lot of fun to work on and it’s great to see the change positively received. There will hopefully be a lot more coming soon. 🙂
The Customer Service Happiness Manifesto
The Customer Service Happiness Manifesto. John O’Nolan writes about how to approach customer service. Some terrific advice and details on how to communicate with and cultivate happy users.
Adding a phone number to LessAccounting increased our paid user base. The benefits and goals of successful phone support. If it’s done well it can be incredibly helpful to curious users.