In our previous article we talked about how we and some of customers use ScreenSteps Live to scale our support services through online chat. In this post I wanted to give you a few tips on getting started with online support chat. Following these tips have made offering chat support to a customers a benefit instead of a burden to our business. Getting Started 1. Prepare your documentation If you have your help resources set up correctly then you don't need to be intimidated about getting started with online chat. Just make sure you have a list of urls that point to common questions your customers have. Have this list handy so that you can easily paste the urls into your support chats. If you are using ScreenSteps Live for your documentation then be sure to set up all of your support agents with the ScreenSteps Live Support Client. The Support Client will save your agents hours of time when responding to support chats. 2. Don't worry about always having it on You don't need to feel like you always need to have the chat service on. If things get too busy or you need to step out it's not a big deal. All the chat services we have seen will let the user leave a message that will get emailed to you. Chat is a tool to help your customers and help your business. Don't become a slave to it. Also, be aware that many chat services will let you limit the maximum number of simultaneous chats an agent can run. If all agents are busy then new chat requests will just go to your dropbox where they can leave a message.

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.

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.

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.

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:

In his post, “'Digital Natives' and the end of traditional hotline support”, Ellis Pratt describes how the model of support has changed from the 1990's. In the 1990's users would seek immediate support from people who were geographically near them (usually in the same office or workspace). With the advent of social media, geography is no longer important. Users, especially younger users, are first turning to Google, Twitter, email, instant messages and other forms of social media to get answers to their support questions. These forms of communication are almost uniformly text-based. Where does traditional software documentation fit in this new process? Quoting from Ellis:

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: