If you get the same question from your users more than 10 times then you should have written a canned answer for it. If you get questions about your canned answer then you should have made a video for it. There’s no excuse not to. The barriers that used to be put in front of the video creator have largely been removed but I’ll address the three key objections that people put in front of themselves to prevent them from ever making videos.

The Software to create Videos is Expensive

Some is, some isn’t. Some is free. I’ve made extensive use of the completely free and incredibly useful Wink (http://www.debugmode.com/wink/). This program will allow you to capture your activity as you use your software product or webpage and capture your mouse movements. You can then insert popup messages, timed events, user triggered events, and custom slides into your recorded activity. The results can be output into a Flash (http://get.adobe.com/flashplayer/) that pretty much any web browser can display.

I Don’t Have the Voice for a Video

Then don’t do voice with your videos. Communicate what you need to via popup text windows. If you’re building a demonstration video that doesn’t need user interaction you should be careful with the pacing to ensure your viewers can read all your text before your text disappears.

Making Software Demonstration Videos is Hard

I’ve made several dozen and while I wouldn’t call making software demonstration videos hard I would call it laborious and fiddly. Learning your video production software is going to be tricky but the actual production is going to take real time. You’ll be running the video over and over to test timings, adjusting graphics to make them pixel perfect so that you don’t get things jumping around in your video, and you’ll struggle initially to develop the overall concept for each video. But, it goes get easier with time. I usually budget 2-3 hours of real time to produce each minute of my video demonstrations.

Why Videos are Better

People don’t read emails. And my experience is that the more you write in an email, the less they read. If you’re trying to explain something complex a blog article or canned email is better than nothing, but a video is better. Case in point, for years I struggled with software users who couldn’t register their software. I fine-tuned my email response explaining how to do it, I fine-tuned the blog post that was full of screenshots explaining how to do it, and I fine tuned the actual registration process within the software itself. And still I got 3-4 emails a day from users who just didn’t get it. Then I built a software demonstration video of the registration process and linked to new purchasers to that. These days I probably get one email every two weeks about software registration. Videos just explain things better than an email or a blog post could ever hope to.
There’s another big benefit to using software demonstration videos on your website. In this new age of Search Engine Optimization videos lead to more engaged website visitors. Videos capture visitors for longer than blog articles because you can’t skim read a video. More engaged customers are viewed favourably by search engines and videos may have a positive impact on your search engine rankings.

Other Tips

• Don’t forget to upload your videos to YouTube. Having a YouTube channel with all of your software video resources is a useful social channel that can be developed with very little effort.
• Brand your videos and if possible embed URL’s to your websites in them. You never know where your content is going to be shared.
• Don’t forget to include promotional opening and closing slides to your videos. Sell your product, your brand, and your websites.
• Include links to your other videos and gain more traction with your visitors.

The old adage is that the customer is always right. This isn’t true, not by a long shot. You need to know right now that your software users will be, on the whole, selfish and only interested in scratching their own itch. They don’t care if your software product is designed specifically for them and unsaleable to anyone else. They don’t care if their email is the only one you answer today. And they don’t care if you go broke, just as long as you keep giving them the service they demand. I’m telling you now, if you do assume the customer is always right you are heading into dangerous waters and there be dragons in those waters.

Don’t Change Your Software Based on What Customers Want Until…

Here’s a curly one. I am saying to you now, do not change your software product based on what your customers ask for. Up until a point. And that point is where you have been asked for the same thing, so many times by so many customers that it is the first thing you think about when you sit down to do some development work. Stay true to the vision of your product UNTIL the consensus from your user base is such that it can no longer be ignored.

I apply this rule almost fanatically these days. You see, when I got started in the software selling business I thought that I had to be all things to all men. As a consequence my first product grew new features like crazy and I had a bunch of happy customers who had customized software for basically chicken feed. And the end result of this after a couple of years was a product that tried to be all things to all men and ended up being ideally suited to no-one. I don’t even want to talk about what a nightmare that code-base ended up being to support. Continually being reactive to my customer demands caused me to lose track of my initial vision for the product lead to complexity that even I, as the author of the software failed to really comprehend.

The Squeaky Wheel Shouldn’t Get the Grease

Prepare yourself for something. If you’re going solo and planning on providing technical support you’re going to get rude customers. Not just rude paying customers but people who think they deserve to get your hard work for free and others who feel the need to critique your work in rather abrupt language. Don’t get upset by this. Don’t get reactive to it. And certainly, never, ever, make a special effort to appease such characters.

It’ll be hard because when you get a rude email because you’ll see red and want to bang out a reply defending your products (which are your babies after all), and perhaps you’ll want to engage them in debate. Don’t. You can never win. If a rude customer asks for a refund, give them one and reply with the same canned response you would use if a polite customer asked for one. If a rude customer flies off the handle at the way your software does something, respond politely using the same words you would to a civil customer. And if a customer sends an email that just makes you plain angry get up, and walk away. Email is great like that, you can just get up and do something else.
If you take these simple steps I can assure you that in most cases the customer will calm themselves down. We can never know what is going on in a person’s head when they send out poison via email and it’s remarkable how many of them realise what asses they’ve been when their emails are replied to a civil, polite and professional fashion.

Don’t Be Scared to Fire Your Users

Some users are just high maintenance. They take up your time with technical support during your software trial period, they clearly do not read the help file, or your blog, or your myriad of other technical resources. What’s even more frustrating is that they don’t even seem to read the emails you so carefully craft in response to their questions. Treat each of these high maintenance users like gold because if you can, finally, get them to understand your software they’ll become loyal devotees. I’ve had users like these that have maintained a dialog with me for years, which sounds like hard work but each year they happily pay their annual support fees. Which makes me happy too.

Sometimes though, the high maintenance users cannot be saved. You need to recognise these users during your software trial period and fire them before they can spend money on your software. If you can’t save them during the trial period you’re almost certainly not going to save them afterward and once money has changed hands these high maintenance users can get nasty. I used to close sales with all high maintenance users but too many times this lead to disputes and eventual refunds. So these days I quietly fire the users before they purchase and most of the time they don’t even realise I’ve done it. I do it by sending them this email:

Dear Joe Smith,
Before you purchase XXXXX I strongly recommend that you run the product for the full 30 day trial period. Furthermore to make sure that XXXX is a great match for your company I’ve decided to extend the trial period by a further 60 days! Just register the software with the registration codes below and you’ll be able to use XXXX for free for 90 days!
///registration codes here////

This has worked beautifully many times. The user hands over no money and when they give up trying to use your product (which they usually will) you’ll never hear from them again. A potential side benefit to this approach is that your user may actually get a eureka moment during their extended trial period, figure it all out, and buy the software. It’s a win-win situation whatever happens.

Google Experiments

I use Google Analytics to monitor the traffic on my websites. Have done since it was Urchin and Google bought them up. There’s a pretty neat feature in there called Google Experiments which allows you to perform AB tests on different web layouts pretty simply. Above you can see a test I’m running at the moment comparing two very different layouts of a page on my website. Setting up the experiment was very easy. Here’s the steps I followed:

1. Designed the new layout and uploaded it and make sure it worked OK.
2. Setup the new experiment in my Analytics account.
3. Uploaded some tracking javascript into the header of the HTML file for the new layout and old layout.
4. Decide how much traffic to divert to the experiment. In my case I chose 100% because I was confident the new layout would be at least as good as the old one. If you’re trying something radical I guess you’d direct less traffic to the experiment just in case something bad happens.
5. Start the experiment and monitor your stats. Google decides when the experiment is over and assigns a winner or a loser or decides it cannot split the difference.

It helps if you’ve got some Goals setup for your Analytics account so you’ve got something to measure the experiment by. Don’t forget to look at other things though, such as the time visitors spend on your site and the bounce rate. Right now my new layout is outperforming the old layout by 13% and has outperformed it on 7 of 11 days the experiment has been running. 13% doesnt sound like much but it works out to about 700 extra conversions a year. Not too shabby.

If you want some more information I’d suggest taking a look at the Google Analytics Experiments help page.