There was a post on the almost dead Business of Software forum last week from a poster who had recently implemented an ‘uninstall survey’ in his try-before-you-buy software product. An uninstall survey is triggered when a software product is uninstalled from the host operating system. It usually takes one of two forms, the first is a small program that asks some questions and then emails the results or posts them to a website. The second (and far more common) type of survey is triggered by popping up a webpage on the software product website.

But, I digress, the main point of the post was that the number of responses the poster was receiving was small and the number of useful responses was even smaller. I’ve included an uninstall survey with my product Time Clock MTS for several years and this mirrors my experience. I’m lucky to see a 10% response rate (10% of total downloads) and of those, not more than 1 in 10 or 20 actually contains useful information. At first glance it seems to be hardly worth the effort but the hour or two it took to implement has probably seen an ROI measured in thousands of percent. It has allowed me to save the occasional sale by responding to a user who complained of missing features in my product that were not missing at all. It has allowed me to find holes in my documentation and fill them, it has highlighted certain software features I was missing and that respondents found useful, and it has helped me fix up problems with the process flow in the software.

My experience certainly pours water on the comments of one poster on the BoS forums who suggested:

Indirectly related, the existence of an uninstaller often implies a poor architecture, such as apps that stuff random files and overwrite libraries in many places.

This is an insanely negative attitude. Knowing that a product is not perfect and can be improved is the ONLY way of being able to build a better product. And the best way to build a better product is to establish channels of communication with your customers. The software uninstall survey is one channel that is virtually free to establish and provides a means of communication that, in the case of downloadable trial software, would otherwise be impossible. Consider that a trial version of my software can be downloaded, installed, and trialed all without the user having to email me, ask me for a registration key, or even make me aware that they are using the software. Giving the user the opportunity to communicate with me once they have decided to uninstall (and presumably not purchase) my software has proven to be invaluable.

If you’re wanting to implement an uninstall survey, you sell Windows software and you’re using the very nifty (and free) Inno Setup then it’s dead simple. Just add an URL to the [INI] section of your Inno Setup script like this:

[INI]
Filename: {app}UninstallSurvey.url; Section: InternetShortcut; Key: URL; String: http://www.some-domain.com/uninstall-survey.htm

And then add an [UninstallRun] section to your script that opens the URL.

[UninstallRun]
Filename: {app}UninstallSurvey.url; Verb: open; Flags: shellexec

In my case I open an URL to present the user with questions. But there’s no reason why the [UninstallRun] section couldn’t run a small executable file that pops a window up to the user asking them the same questions. Those results could either then be emailed or POST’ed to your website. For your reference here’s the Time Clock MTS Uninstall Survey. It used to have a lot more questions but I’ve simplified it greatly based on the response of one poster in the BoS thread I referenced in the first paragraph. Respondents simply fill in the details and I receive an email contain the responses and a couple of other bits of information such as the users IP address and user-agent. The user-agent is particularly useful so that I know what version of Windows the respondent is using.

There you have it, uninstall surveys. Quick and easy to implement, zero on-going costs, and they provide you with a communication channel to software users that is unlikely to exist otherwise. If you’re selling try-before-you-buy software you’d be crazy to not be using them.