As I wander the web I run into a lot of organizations that try to use user forums for software documentation. This is a big mistake. It creates a poor experience for your users and sets your organization up for customer support headaches. Software documentation and user forums have different purposes and need to be treated differently if you are going to deliver superb customer support.
We are happy to announce the availability of our new eBook, “5 Keys to Successful Software Documentation.”
This eBook lists 5 keys to software documentation that will make sure you are authoring and delivering your documentation in the most effective manner possible. For each of the keys we offer real-world examples from successful customers. At the end we tie everything together with a simple implementation plan that will help you get started on the road to creating successful software documentation.
We won’t spoil all of the content, but in the eBook you will learn:
We would love to hear your thoughts and feedback so please leave comments or send us an email.
Over the last couple of weeks we have been thinking a lot about customer support vs. customer success. For the purposes of this article and several follow-up articles I plan on writing I am going to the define these two terms as follows:
Customer support: Helping your customers solve problems they encounter when using your product. This includes addressing bugs as well as providing information about how to accomplish specific tasks with your product.
Customer success: Helping your customers improve their business, their organization or their lives by using your product.
Customer support deals with small, focussed issues. Customer success deals with the macro application of your product to achieve larger goals. To create real evangelists of your product or service you need to have great systems in place for supporting your customers, but you also need to have systems in place to ensure their success with your product or services.
We are really good at customer support. We have great systems in place that help us address support issues quickly and consistently. But our results with ensuring customer success are more mixed. We have some customers who are fantastically successful with ScreenSteps and ScreenSteps Live and who evangelize it regularly while other are simply satisfied customers that are happy with the product.
To a small company like ours the value of a thrilled customer who shouts our name from the roof tops vs. a satisfied customer who occasionally uses ScreenSteps is huge. If we were to put a monetary value on those customers the difference would be literally thousands of dollars vs. a one time $40 or $80 purchase.
What is the main difference between these two types of customers? Our “satisfied” customers just use ScreenSteps to create documentation. They are using it to complete one of the tasks that need to get done in the course of running their business or organization. Our passionate users use ScreenSteps to change the way they run their business or organization. ScreenSteps and/or ScreenSteps Live don’t just change their documentation. They change their business.
Category: Keywords: ScreenSteps.me, customer support, marketing, screenshots, ScreenSteps Desktop Status: draft
We just launched our public beta of ScreenSteps.me last week and the response has been pretty exciting. I have to say that I haven’t been this excited about a new feature in ScreenSteps since we released our integration with ScreenSteps Live and ScreenSteps Desktop. ScreenSteps Live solved a huge problem for me as a business owner. It let me support more customers with less time and effort. During the two weeks I have been using ScreenSteps.me, it has saved me hours time. Here are just a few of the ways I have been using ScreenSteps.me.
We recently started working with a freelancer on Elance. She is doing some CSS work for some new templates we have coming to ScreenSteps Live. Elance has a message board where I can give job descriptions and provide feedback on the work provided. I have been using ScreenSteps.me to do two things:
The whole process has gone very smoothly. I have never had to send follow up messages to clarify what I need. Almost all of the “back and forth” that is usually involved in trying to describe how I want a job done has been eliminated. I ask for something and a day or two later I get a message that it is completed. It is wonderful.
View an example of one of our Elance posts
I use a lot of software products everyday in my business. Invariably I find bugs in the products I use (including the ones we develop). But describing bugs in an online chat or email can be tedious and usually involves a lot of back and forth communication as the company tries to understand the problem I am having.
This week one of our service providers, Chargify, went through a major business model change that shocked their customers and caused quite a stir on the Twitter, TechCrunch and Hacker News. To their credit, they were out engaging early and often trying to quickly make modifications to their new plans to appease their angry customers.
Yesterday Lance Walley, their CEO, posted about why they had to change their prices. Essentially, they had priced themselves into a corner. They worked primarily on a freemium pricing model but with a premium sales and support process. The two don’t mix well.
Their original pricing made it very easy for businesses to “try out” their service. Any business could use Chargify to manage up to 50 subscription users for free. After that there were various price plans based on the number of users you had.
We already had a billing system in place before switching to Chargify but Chargify had a lot of features that were really nice, saved us a bunch of time and mode our lives easier. After starting out with the service we eventually became paying customers.
The problem for Chargify was that they experienced all of the costs associated with our account when we were free customers.
Chargify isn’t simply a service you turn on and it starts working. Especially if you are going to use their API (which is the approach we took). Working with API’s, no matter how good they are, takes time for customers and creates a lot of questions. Organizations that offer API’s often have to spend a lot of time answering those questions.
In our early days I had questions about the product and how it worked that were quickly answered by phone, email and Twitter. And I eventually became a paying customer. But according to what Chargify is saying, there were many, many customers that never converted from free accounts to paying accounts, simply because they weren’t growing fast enough.
Once again, most of Chargify’s support costs were incurred while accounts were free (now that we are a paying account I rarely contact support at all). If your support costs are high for free accounts and very few of those accounts become paid accounts then your business will run into trouble very quickly which is exactly what happened to Chargify.
Chargify’s support has always been fantastic, but it was the wrong sales/support model for the pricing model they had implemented. If you are going to offer a freemium service then the sales and support process needs to be largely self service.
Chargify had a pricing model that required self-service but a setup process that required a lot of one-on-one interaction. The two don’t mix. If set up is going to require a lot of one-on-one time then you need to do one of the following:
I am not a fan of the freemium model, especially for new B2B businesses. We tried it in the early days and things have gone much better since we went away from it. But if you are going to have a free or low cost solution you need to make sure that you have resources in place to effectively scale your business.
One of those resources is good documentation. I really believe that better documentation could have really helped Chargify out. They recently launched a new documentation site. This is much better than what they previously had but it still isn’t there. The lack of a search feature is a major omission which just serves to increase their support costs. In addition, support resources are now spread out across a knowledge base, software documentation, forums, an FAQ and API documentation. In the end it is easier to contact support than to find an answer to your question.
We have had many businesses come to us who were in the same situation. We had one customer come to us who was just about to shut their business down because of high setup costs. They started using ScreenSteps Live and support requests instantly dropped. We regularly hear the same story from other customers. Having good documentation that is updated regularly helps them scale their business.
Now, not just any documentation will do. Our customers are following a simple methodology for creating documentation that decreases their support load and improves their business. If you have the methodology in place then things work great. If all you do is create documentation and pray that it works then you won’t get very good results.
One of the major causes of backlash for Chargify was their refusal to grandfather existing customers as they rolled out new plans. It is fairly typical for SaaS based products to grandfather existing users when they roll out new pricing plans (Grandfathering is the process whereby existing users are able to keep their current pricing regardless of new pricing for new users). Zendesk learned this the hard way several months ago and eventually ended up grandfathering customers. I am assuming that Chargify is doing this because the cost of supporting existing customers is higher than the profit gained by those customers.
You can’t grandfather customers if existing customers are causing you to lose money. Don’t put yourself in this position.
The lack of grandfathering really ticked a lot of people off. As a customer it really felt like a breach of trust to have pricing changes sprung on us with such little notice. But obviously, it was a move Chargify felt they needed to do quickly.
This is another area where better docs could really help them since the majority of the costs associated with existing customers are support related.
Let’s be clear. The Chargify guys are much smarter and accomplished than I am and have created some incredible businesses (Grasshopper, Engine Yard, etc.). As far as marketing, product development, and PR they really know what they are doing and we can (and have) learned a lot from their examples and blog posts. But I believe that if they would have focussed on their support and documentation costs from the beginning then they would have been in a better position to raise prices for new customers while keeping existing customers happy. They could have made sure that at least their existing paid customers were profitable customers.
We have done a lot of things wrong in our business but we have always focussed on having great documentation. We see this as being a key factor in allowing our business to grow. We develop and support three significant products, ScreenSteps Desktop, ScreenSteps Live, ScreenSteps Workgroup, and plan on launching a new service, ScreenSteps.me, fairly soon. There are only two of us but we always answer the phone and respond to support tickets quickly.
But we don’t get that many calls. And we don’t receive that many support requests. Our customers are doing some really amazing things with our products and integrating with a wide variety of services. But because the docs are good and are in a simple, centralized location our customers’ questions are answered before they have to contact us.
This gives us a lot of flexibility as we go forward. We have a subscription service, ScreenSteps Live, that is really affordable for our customers. At some point we will probably increase prices for the service. But because our support costs for existing customers are so low we will easily be able to grandfather existing accounts, allowing them the option to keep their existing pricing and plans, only upgrading to higher priced plans if they want to. We have already done this once in our history and received zero push back from our customers. They viewed the new pricing as optional as opposed to obligatory. We were able to make it optional because of low support and infrastructure costs.
Could that change? Yes. If our infrastructure costs dramatically increased then we could be in a position that we would have to increase prices for existing customers. But infrastructure costs seem to be going down instead of up so I don’t really see that happening.
Will we be sticking with Chargify? Yes. They have a great product and great service. And the new pricing isn’t really that big a deal for us. The way the pricing increase was handled left a bit of a sour taste in our mouth and changed what was unbridled enthusiasm to something a little less glowing.
I should probably be careful in what I say. We haven’t experienced the kind of growth and press attention that I am sure Chargify has. And maybe things would be different if we did. But I do know that the money our customers pay us is more than what they cost us in support. That gives us a lot of options as we grow our company.
If you would like to read an excellent summary of what of what Chargify learned from this experience you can find it here.
Free eBook: 5 Keys to Successful Documentation
FAQs (Frequently Asked Questions) are a very popular and very effective means of providing technical and customer support. The question is, how frequent does a question need to be before it can become part of the FAQ? How often is the FAQ updated?
The truth is, most FAQs aren’t updated continually. They are created once and then left alone. Creating the FAQ page is a project. Once the project is completed then it isn’t revisited unless absolutely necessary.
Let me suggest a better approach. Don’t create a FAQ. Create a FUA (Frequently Updated Answers). Just changing the title causes you to rethink the way you approach it.
Here are the principles behind a good FUA:
Our documentation for ScreenSteps basically functions like an FUA for our products. And it saves us hours and hours in decreased support time. The place where we need to do better is in our policies. We don’t have an FUA for things like, “What is the difference between ScreenSteps Workgroup Connection and ScreenSteps Workgroup Concurrent?” or “Do you accept purchase orders?” These answers are spread out around our website which means neither we nor or customers can remember exactly where to go to find the answers. The result is that we spend a lot of time answering those same questions over and over again. It is something that we are going to be looking at improving in the next couple of weeks.
Free eBook: 5 Keys to Successful Documentation
Last week I had to take my car in for service. I don’t know about you but this has been my experience at every car service place I have been to:
Despite their promise to call me when my car is ready I have never received a call back. And this isn’t just a at one service station. It is at every one I can remember going to. That is why I don’t feel any loyalty to any one particular service station – they have all broken their promises to me.
I really believe that 80% of providing great customer service is about keeping your promises. There have been times when we haven’t been able to solve a customer’s issue. They may have been disappointed but they were never upset. Breaking a promise to a customer is pretty much guaranteed to make them upset.
Here are few steps that will help you set expectations for your customers and keep your promises:
It is much better to tell your customer that you can’t get an answer for another three days than to make a promise you can’t keep. Sometimes companies want to seem “bigger” than they actually are so they make promises that they can’t possibly fulfill. Do you have the staff to guarantee that a customer support request will be addressed within one hour? If not then don’t promise that you will. Adjust the customer’s expectations to what you are reasonably able to deliver.
Don’t try to keep all of your promises in your head. Eventually one of them will fall out. Use some sort of task manager where you can set due dates to make sure that you don’t forget the promises you make. I use OmniFocus. As soon as I make a promise to a customer I create a task in OmniFocus with a due date. That helps me make sure that even if I forget the promise I made, OmniFocus will remind me about it.
Processes and Systems help you keep promises. Have a return policy. Document the steps to process a return. Use a help ticketing system. That will help you make sure you have responded to all support requests in a timely fashion. The more processes you have in place the better you will be at consistently keeping your promises. Choose software tools that help you establish these systems and your life will get much easier.
This a principle that I just learned recently. Open ended promises are much harder to keep then ones with a specific due date. So instead of saying, “I will get you that proposal to you,” say:
“I am going to try to get the proposal to you in 3 days. If I can’t get to it by then I will let you know.”
The promise has a due date. Both the customer and I know what is expected and when it is expected. At least in my case, promises without due dates tend to slip through the cracks.
Have you had a time when an organization didn’t keep their promise? Or, even better, when a company went out of their way to keep a promise? What was the experience like? Please share your experiences in the comments below.
Learn how to get better results out of your software documentation:
Your customer help desk is probably one of the most poorly used groups in your organization. Your help desk has more contact with actual, paying customers then anyone else in your company. But too often organizations limit the role of the help desk to simply closing out help tickets or answering support calls. Here are three suggestions for getting a lot more out of your help desk:
Your help desk team talks with customers all day. They will often speak with customers who are trying to use your product to do a job that it wasn’t designed to do. If your help desk gets enough similar requests it might be a sign that there is an opportunity for a new product. Have your help desk team enhance your existing product or create a new complimentary product that will work for these customers.
The help desk has to hear customers complain about bugs in your software all day long. If you put the help desk in charge of fixing bugs in your software the most important bugs will get fixed first.
Your help desk knows what questions customers have. They know how to answer those questions. Let them write your documentation and you will get help files that are more useful to your customers.
By this point in the article you are probably thinking:
“Is he crazy? You can’t have the help desk develop products, fix software bugs and write software documentation.”
No, you probably couldn’t with most help desk teams. But what if you had someone from your product management, software development and documentation teams “man the phones” once a week? Each one of those people would go back to their teams with an amazing amount of insight. Your products would be better. Your most important bugs would get fixed faster. Your documentation would be better.
It’s not about making your help desk people do things they weren’t trained to do. It’s about getting everyone in your organization on the help desk team.
Think this is crazy? Freshbooks has been doing this for awhile with what appears to be great success.
Learn how to get better results out of your software documentation:
About a year ago we hosted a webinar on software documentation. During the webinar we showed an image annotation technique that is very common and, in our opinion, very ineffective. One of the participants in the webinar said they called the type of image an “Octopus graphic”.
An Octopus graphic is a screenshot that has been abused by the ScreenSteps sequence tool or other image annotation tools. Look at the graphic below:
Octopus graphics have many, many labels describing different buttons (obviously we have exaggerated a little in the example above). This seems to be a popular approach among technical writers which we feel delivers very little value to end users.
Listing the names of buttons is of little use. This function can often be handled by a well placed tool tip in the interface. It is much more important to teach your users how to accomplish tasks. If you are teaching tasks then you will very rarely need octopus graphics.
With so many labels on the screen it is impossible to process what is going on. If you really feel that you need to label every button in the interface at least break up your labels into different graphics. Try to group the buttons into meaningful collections. People are better able to understand and retain information when it is put into smaller chunks. I would suggest limiting yourself to no more than 5 labels on a single screenshot. A single graphic with a bazillion labels on it presents information in a way that is hard to understand and even more difficult to retain.
If you use octopus graphics you run the danger of “documenting” your entire application without delivering any real value to the end user. Once you have labeled everything you may think that you are “done” with your documentation. But your documentation won’t deliver any business value to your organization. Your documentation shouldn’t be “done” until you have helped users accomplish real-world tasks. Octopus graphics don’t help people accomplish tasks.
Do you have a lot of screen captures that look like this in your documentation? It is probably a sign that you aren’t taking the right approach to writing your docs. You are spending too much time talking about buttons and labels and not enough time talking about tasks. Start creating more “task based” documentation and you won’t feel the need to create any octopuses.
We obviously believe that adding screen captures to software documentation makes a huge difference. We would go so far as to say that it is the difference between software documentation that produces business results and software documentation that creates door stops.
But simply adding pictures isn’t enough. You have to add the right pictures in the right way. In the upcoming weeks we are going to post a series of tips for capturing images that improve the effectiveness of your documentation.
When we add screen captures to our software documentation we have one goal in mind: clarity. Clarity is all that matters. I want my reader to be able to quickly glance at the screenshot and move on. I want them to only have to process as much visual information as is absolutely necessary. Too much visual information will cause them to have to “study” the screenshot. Not enough visual information will force them to hunt through the application interface.
There are a variety of factors that can contribute to clarity, but in this article we are going to focus on size. If you get the size of your screen captures right then you will make big improvements to the effectiveness of your software documentation.
First, let’s talk about the goal for our documentation example. In this example we want to show the user how to export a lesson to the clipboard in ScreenSteps. To do this they will need to click on the Clipboard icon. An example is shown below.
Size errors come in two flavors, too big and too small. Let’s look at both.
Screen captures that are too big communicate too much information. By showing too much information it makes it difficult for the reader to discern what is important.
This first example captures my entire desktop.
The problems with this image are obvious. I have captured so much of my screen that the Clipboard icon is hardly visible. The extra data doesn’t add any value to the screen capture. It doesn’t add clarity. It just adds confusion.
The type of screenshot shown above is much more common. Capturing an entire window is easy and it looks nice and clean. But the only thing I need to show in my documentation right now is the Clipboard icon so this is still way too much visual information.
This approach to adding images to software documentation is very common:
What is the problem with this? You are asking your user to play “Where’s Waldo” with your software documentation. No context is given to help the user know where the Clipboard button is in the interface. Depending on the complexity of your application interface, finding the icon you are documenting can be like hunting for a needle in a haystack.
Why do authors do this? To save themselves the hassle of having to update their screenshots when their application changes. The thinking goes: “If I only have a picture of the Clipboard icon then it doesn’t matter where that crazy software engineer decides to put it. I don’t have to update my documentation.”
The amount of frustration you will cause your users simply isn’t worth the time savings. Don’t do this.
This is better but still not ideal. There is a little more context given around the Clipboard button but not enough to instantly communicate where the button resides in relation to the entire application interface.
Here is what I feel is an ideal size for the screen capture:
Notice two things:
We haven’t cropped the application window to remove the desktop background. Showing the borders of the interface help the user quickly orient themselves. Whenever possible, I like to get a corner of the interface in the screenshot. Including corners helps the user know if they should be looking top-left, top-right, bottom-left or bottom-right when following my instructions.
We include surrounding interface elements. Once again, we are trying to provide context. By including the surrounding elements I can give the user more “guide posts” that will help them locate the Clipboard button when actually using the ScreenSteps application.
I have worked with many technical writers who don’t like the look of this type of screenshot. They would prefer that the edges be tightly cropped for a nice, clean appearance. They are worried about aesthetics. I am mostly concerned about clarity.
Aesthetics will give you a very nice presentation piece to show your friends. Clarity will decrease customer support requests, improve user satisfaction and improve your business.
Blue Mango Learning Systems
© 2011
