Software Trial Periods: How long before customers buy?

With the November releases of SliQ Invoicing and Quoting (Standard and MC), I made a change to the format of the product and unlock codes. The idea behind this was to simplify the process for users, making it easier to check if a product code was correct. The new format also makes it easier to generate an unlock code. The new unlock code format is also longer - meaning that people will be less likely to try and type the code in by hand. This should reduce the chances of the unlock code being mistakenly typed. On the advice of a fellow software vendor, I now use the customer’s identity - land and email addresses in the code making it easier to match codes to customers in the future.

I've always wondered how long people use my software before purchasing. People have up to 30 days free use before they need to buy but until now I've had no way of gauging how long people try before buying on average. With the change in the code format, I've been able to tell whether someone download the software before or after the change. Previously, I’d read posts from other shareware authors or marketing people advising that people tend to buy more or less immediately - within hours - if they are going to buy. The longer people leave between trying and buying, the less chance of a purchase. Although not a scientific test, in the three or so weeks since the last release, 90% of purchasers still use the old format code. I'm taking this to mean that, at least with my products, most people take pretty much full advantage of the 30 day trial period.

Of course, I could get worried by purchasers still registering with the old product codes. With the credit crunch I could assume that I’m not getting any new customers and I’m just exhausting the supply of people who downloaded a trial a month ago. However Google Analytics is actually showing an increase in traffic over the past 3 weeks and my download bandwidth has increased too. This means I'm probably getting proportionately more new trial users. The sales haven't dropped off either, which I was kind of expecting for business-related software in the run-up to Christmas.

If all this means that most people take advantage of the trial period then I’m glad. I want people to use the full trial period to make sure they are happy to purchase. Hopefully it reduces the support overhead in the long-term since those people who do buy will be more happy with the features the software provides.

CD Autorun in Windows XP and Vista

To get Windows to automatically launch an application when a disc is inserted into a CD or DVD drive you need to include an autorun.inf file on the root of the CD folder.

The autorun.inf file is a text file written in a Windows INI file format. The sections in the file tell Windows what to launch, e.g.

[autorun]
shellexecute=install-instructions.html

launches the default browser on your PC, e.g. Internet Explorer, and displays the install-instruction.html file in the root of the CD (or DVD). You can then include further instruction in the HTML file together with links to launch an installer for example.

SliQ Invoicing and Quoting 1.4 Released!

SliQTools have released version 1.4 of their invoicing software SliQ Invoicing and Quoting.

Version 1.4 is available as a free upgrade to any existing purchasers. To upgrade to 1.4, all existing owners have to do is download a new trial copy from the SliQTools website and install 1.4 on their PC.

SliQ Invoicing and Quoting can be configured for different currencies and tax rates.

A fully functional 30 day trial of SliQ Invoicing and Quoting can be downloaded from the SliQTools website.

Version 1.4 of SliQ Invoicing and Quoting is still available at the same price of £24.99.

A number of useful features have been added in version 1.4:-

• Multiple invoice templates are now supported.
• Service Invoices as well as Product Invoices are now supported.
• Discounts (% and amount) can now be applied to invoice items.
• Standard discounts can be stored.
• Remittance slips can optionally be included on invoices and statements.
• Payment details information can be stored.
• Customer and product data can now be exported and imported allowing data to be shared with other copies of SliQ or external applications.

All the useful features of SliQ 1.3 are still present in the new software release. SliQ supports a range of sales reports and includes the ability to create esimates/ quotes, credit notes and statements or ageing reports.

All items can be emailed from SliQ as PDFs. New copies of invoices or quotes can be raised and quotes can be turned into invoices with a single button click.

To visit the SliQTools site and find out more, go to http://www.sliqtools.co.uk/.

Software Bugs, Software Releases and Version Numbers

Occasionally the inevitable happens and I get a problem report on my software products. Usually this doesn't happen frequently, e.g. for the whole of March, April and May 2008 I haven't had a single problem report.

When a problem is reported I have to weigh up how serious the issue is and how many customers are likely to be affected. In one sense all customers could be affected by a software bug, the question comes down to how many people are actually likely to run into the issue.

One thing that helps is how long a software release has been in distribution before the problem is reported. If the release has been in the field for a few weeks - or hopefully months! - I can have more confidence there's no need for a knee jerk reaction. If this is the case I can avoid a global release to all registered customers.

Whatever happens, if a customer has reported a problem I will either try to find a workaround that we are both happy with or provide them with a new software release. I do this whether or not the customer has paid for an unlock code or is still using a trial copy of SliQ Invoicing and Quoting.

If I make a special release for a single customer I use an intermediate version number for my products. Normally I use 3 digits to number software versions. For example:

1.3.0

1.3.1

1.4.0

but if I do a release to a single customer I will use a 4th digit on the version number in the application's software version resource. For example:

1.3.1.1

if a problem was found in version 1.3.1.

This way, when I come to do a full public release of software, I can avoid documenting the intermediate versions in the Release History on the product website. I can just document the major, public releases: 1.3.0, 1.3.1, 1.4.0

Of course, one question will always be: what's the difference between a bug and feature that doesn't work the way a customer expects? This is a topic for a different post however.