Today’s software company, whether providing desktop or SAAS offerings, provides customer support in a number of different settings. For example, in our company we interact with our customers in five different ways:

• Email
• Forums
• Live on-line chat
• Twitter
• Telephone

All of these communication tools allow the person offering support to point customers to resources on the web that answer their questions. If your company has online help that is designed correctly then you will be able to leverage your materials in order to quickly answer customer questions.

Let’s look at five keys to making your online help documentation work for you when handling customer support requests.

1) Create short documents that demonstrate tasks

When you write your documentation you should show users how to perform tasks, not discuss features. For example, create a lesson that shows “How to configure an account” rather than “The account administration screen”. By creating short, task based documents you can point your customer directly to documentation that shows them how to do what they want to do. This removes the step translating the description of a feature into the necessary steps required to complete the task and reduces the amount of follow up questions.

Short, task-based lessons prove very helpful when providing support. When helping a customer in a support interaction you can string together multiple online help documents for the user to help them perform a larger task.

Look at the document titles in the image above. Notice how each title explains a task.

2) Make the URLs of each help document easily accessible

Whenever someone is viewing an article in your online help documentation they should be able to copy the URL from the browser address bar. If your online documentation delivery system uses frames that hide the actual URL or if you place multiple answers on a single page then you are making it more difficult to link to the content.

Customer support via Twitter pointing the user to specific document urls

3) Author content in a format that is easy to search

When looking for the relevant document to send to a customer you will probably need to search your documentation to get the URL. Make sure your documentation delivery system has search functionality that returns relevant results.

4) Use a publishing system that allows you to quickly add new content and update existing content

Documentation should be a process, not a project. Your documentation will need to be updated as new customer questions come in or your offering is updated. Whether or not your documentation keeps pace with these new needs will depend on how easy it is to update.

Make sure you use a publishing system that makes updating content as effortless as possible. If too much work is involved then your documentation will become stale as the more (seemingly) pressing matters of the day push documentation updates to the back of the line.

5) Create content in a format that is clear

It is important that you choose the proper format for your online help documentation. You don’t want your documentation to create more questions than it answers. Above all, your documentation needs to be easy to follow. We recommend using static screenshots and text as this provides the best balance of clarity, ability to search and ease with which you can keep your documentation up to date.

This documentation uses text and images to clearly outline the task to be performed

-

Your online help documentation can be a real asset for you regardless of which setting you are interacting with your customers in. By implementing these five keys to better online documentation you will get the most out of your documentation investment.

For an example of how we have implemented these keys in our own documentation take a look at our ScreenSteps manuals.

(more…)

Using a web knowledge base to answer customer questions can be a tremendous resource. They are easy to access and easy to update.

Most web knowledge base articles are text based, however. Adding screen captures or other visual elements to your knowledge base articles can dramatically improve the results your knowledge base delivers. Most people think that it is just because the articles are more clear (visual information makes instructions easier to follow). But they also affect the user’s decision making when they are determining whether or not to read an article. Let’s look at why that is.

Knowledge bases usually contain “how-to” type articles. When a user views an article in your knowledge base they need to quickly answer two questions in their mind:

1. Does the knowledge base article apply to me?
2. Is the knowledge base article current?

Adding screen captures to your articles helps them answer these questions instantly.

Does The Knowledge Base Article Apply to Me?

By just adding a few screen captures the user can instantly see:

• Where the starting point of the article is
  

  Are there certain requirements that need to be met before you can use the information in the article? For example, if your article covers a function of Excel, does the user need to have imported some data before they can do what is described in the article? A screenshot of Excel with the data already imported will communicate that immediately.

• What part of the application the knowledge base article applies to

  If the application you are supporting has multiple screens, a screen capture will instantly communicate what part of the application the article covers.

• What type of result the knowledge base article instructions will produce

  If the user can see an image of the end result the article produces they can quickly decide if that is the result they are after.

Is The Knowledge Base Article Current?

This is probably the most important question you can answer. There is nothing more frustrating for your users then to follow the directions in your knowledge base only to discover that the instructions no longer apply to the version of the software they are using. Screen captures help the user quickly determine whether the version of the software that is described in the knowledge base article matches the version that they have. This saves a lot of frustration and lot of confused email/calls to technical support.

Visual Knowledge Base Example
Here is the same article both with and without screen captures. Notice how much more information is communicated with the simple addition of visual elements. (Knowledge base example taken from http://help.hover.com)

Conclusion

If users can determine that an article is applicable to them then they are much more likely to put the effort into reading it. by adding screen captures you can help your users make that decision in less time and get them to engage more quickly. This will dramatically increase the effectiveness of your knowledge base.

(more…)

This morning I read a post by Tom Johnson titled “If No One Reads the Manual, That’s Okay”. In it the author describes how he is writing a 200 page manual that no one will ever read and that somehow that is all right.

That no one will read a 200 page manual is perfectly OK. That people are still writing them is insane.

In the comments of the post, some technical writers were making the case that users needed to read the manual. But it doesn’t matter what you think users should do, only what they will do. The real problem here is that technical writers keep doing the same thing and expecting different results (the definition of insanity).

Here’s a suggestion, instead of talking about how people should use the content you create start trying to figure out why they aren’t using it.

And then fix it.

Don’t accept things the way they are.

Make your content useful and make it accessible when and where the user needs it.

Here are some questions to ask yourself (these all relate specifically to software manuals):

What happens when a user doesn’t read the manual? One of the things they do is contact support. Develop and deliver your documentation in a way that can be used in a support situation.

What are your users asking? Are they asking “Could I please have an overview of the Upload tab?” or “How do I upload a file?” Is your documentation structured around the questions your users have or the way your application is organized? Which would your user prefer? Which would be most useful to your users and your organization?

Where do users ask questions? They call, email, post to message boards and use Twitter. Can you deliver the content your users need (your manual) in the places where they are asking the questions?

These are the questions technical writers need to be asking themselves if they want to move beyond just fulfilling requirements to really adding value to their organizations.

Several months ago we recorded a webinar on this exact subject called Why Your Documentation Stinks and How to Fix It. Check it out if you want some new ideas on how to get people to read the documentation you write.

Yesterday we hosted our first webinar about how to use ScreenSteps and ScreenSteps Live to decrease customer support requests. Thank you so much to all of you who attended and for all of the kind words so many of you have shared.

Brian Weiss of WORD’SWORTH, one of the attendees, emailed us and said:

We hope that the rest of you felt the same.

For those of you who weren’t able to attend, we have posted a recording of the webinar. The recording is about 75 minutes long. The first 30 minutes contain a presentation on how to effectively use ScreenSteps Live to handle customer support. For the last 45 minutes Greg and Trevor respond to questions from viewers.

You can download a recording of the webinar here:

Decreasing Customer Support with ScreenSteps Live wmv (66.3 MB)

Decreasing Customer Support with ScreenSteps Live m4v (81.5 MB)

We are already working on plans for our next one. We hope you will join us. Be sure to check this blog or sign up for our newsletter to be notified when we will present one.

You can subscribe to our newsletter here:

http://www.bluemangolearning.com/newsletters/screensteps.html

I don’t ever plan my documentation. I used to. But not anymore. It’s a waste of time. Maybe if I were on a documentation team and had 6 months to get the documentation ready then maybe I would plan. I could plan and then revise and then plan some more.

But I am not on a documentation team. I run a business. I am the web programmer, accountant, custodian, sales person, system admin and business development director. I don’t have time to plan my documentation.

So what have I done? I have planned not to plan. I have created a system for documentation that requires no planning at all AND creates documentation that is much more useful to our customers. It really is quite simple. Just follow these simple steps:

1. I write down the questions my customers have actually asked me.
2. I create lessons in ScreenSteps that answer those questions.
3. I post the answers as a manual to ScreenSteps Live. You can see an example here.
4. When a customer asks a question I do one of two things:

- If I have a lesson that answers their question I send it to them. - If I don’t, I create one, add it to the manual and send it to them. See here and here for two lessons I added to our manual this last week in response to customer questions.

This system has worked really well for me. I don’t end up writing content that won’t ever get used again, the lessons are very easy to update because they focus around a specifc task and I can quickly respond to customer questions.

Try it out. On your next documentation project, plan not to plan. Just answer the questions people are asking. You will find that your documentation will be easier to create and easier to use.