Employee/Customer Onboarding, Training and Enablement

Come to ScreenSteps blog to learn how to onboard, train and support your employees and customers.

Blog Feature

Miscellaneous

By: Greg DeVore
April 22nd, 2011

As you have probably already heard there were some problems with ScreenSteps Live and ScreenSteps.me over the past 36 hours. ScreenSteps Live is hosted on an Amazon Cloud infrastructure and Amazon had some major problems yesterday which are still going on as I write this. The problems they had affected a lot of sites, including Reddit, Quora and Foursquare just to name a few.

Blog Feature

Customer Support

By: Greg DeVore
March 16th, 2011

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.

Blog Feature

Customer Support | Customer Success | Entrepreneurship

By: Greg DeVore
January 5th, 2011

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.

Blog Feature

By: Greg DeVore
October 22nd, 2010

This week, Trevor left on vacation and won't have much access to email. But he has support tickets that have been assigned to him in Zendesk. If a customer responds to a pending ticket, we didn't want them to have to wait for Trevor to get back for us to reply to them. But Zendesk doesn't have a way to "send an agent on vacation." So this is what we came up with. Create a New Trigger We set up a new trigger in Zendesk. Use These Search Settings We are going to set the trigger to process any ticket that is assigned to Trevor and that is updated. When a user replies to a ticket that was assigned to Trevor this trigger will be activated. Configure Actions In the actions we are going to: 1. Assign the ticket to me. 2. Send an email to Trevor so that when he gets back he can quickly see what tickets were taken over by me. Just hit Update trigger and we are done. Now I just need to remember to turn this off when he gets back.

Blog Feature

Customer Support | Entrepreneurship

By: Greg DeVore
October 13th, 2010

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.

Blog Feature

Customer Support

By: Greg DeVore
October 6th, 2010

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.

Blog Feature

Customer Support

By: Greg DeVore
September 14th, 2010

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:

Blog Feature

Software Documentation Tips | Documentation Managers

By: Greg DeVore
September 13th, 2010

We obviously talk a lot about using images in software documentation. When I speak to technical writers I will often get a response that is something like this: Pictures work for certain learning styles. But some people are auditory learners and some people do better reading text. Bunk! It simply isn't true. I, like everyone else, have heard about this theory of "Learning Styles" for quite some time. Turns out this is one of those "truths" that we all accept but that doesn't have much proof to support it. Here is a quote taken from a recent New Your Times piece: Take the notion that children have specific learning styles, that some are "visual learners" and others are auditory; some are "left-brain" students, others "right-brain." In a recent review of the relevant research, published in the journal Psychological Science in the Public Interest, a team of psychologists found almost zero support for such ideas. "The contrast between the enormous popularity of the learning-styles approach within education and the lack of credible evidence for its utility is, in our opinion, striking and disturbing," the researchers concluded. By claiming that there are many learning styles and that some people learn better by reading, technical writers claim that a text-only format is an acceptable form of software documentation. Take a look at the documentation example in this post. Can you show me one person who would prefer the text only version to the version with pictures? The Real Issue: Work Talking about "Learning Styles" in software documentation is really just a red herring to move our focus away from the real issue: work. Adding images to documentation takes extra effort and can add complications to the delivery process. Some of the problems include: Technical writers may not be comfortable with image capture and image editing software. Adding images to documents is often clunky and cumbersome (though we believe we have a [pretty good solution for this][3]). It is more difficult to translate a screenshot than an xml document into multiple languages. Updating your documentation with changes takes more time and effort if you use screenshots. The Benefits Outweigh the Costs But the benefits far outweigh the costs. By adding images you add a level of clarity that is simply not possible with the written word. And clarity delivers real business results. I spoke with one of our customers the other day who estimated that they had already saved $10,000 by creating a single visual document. All this document did was show his customers a checklist they had to go through before they returned a very expensive piece of equipment for repair. The document had pictures for every step of the checklist. Guess what happened? Their return rate dropped. Customers found out that their equipment wasn't broken before they sent the equipment back, saving the company shipping costs, expensive tech time as well as downtime at the customer site. If you aren't using visuals in your documentation then stop hiding behind this false notion of "Learning Styles." Address the real reasons you or your organization are avoiding visual documentation. Most of them are solvable if you just rethink your workflow, delivery system and your documentation software. It's 2010. Your primary tool as a technical writer should be a camera, not a typewriter, regardless of your learning style.

Blog Feature

Software Documentation Tips | Documentation Managers

By: Greg DeVore
July 8th, 2010

About a year ago we hosted a [webinar on software documentation][software-webinar]. 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".

Blog Feature

Software Documentation Tips | Documentation Managers

By: Greg DeVore
June 24th, 2010

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. 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.