Suggestion: "Topaz Update"

With the addition of apps, and the increased frequency of updates, I think now is the time to consider creating a “Topaz Update” program that can be optionally run alongside one or more Topaz products.

At present, each program needs to be updated manually, and the update notice typically comes when you launch the program and the application checks the Topaz servers for a new version. There are two issues that present itself with this approach…

First, it means that if a user launches a program and needs to work on a project—they have to choose whether to skip the update to complete their work, or delay their work to complete the update. Second, they aren’t able to start the update while they are using the program, since the program needs to be closed to update. (Which of course is understandable, but is still a nuisance.)

I’d like to suggest a new “Topaz Update” application be created. This small-footprint program would launch on start-up and run in the background—checking Topaz servers periodically for updates to any Topaz software that is installed on that machine. The software could collect and encode the product serial numbers of installed software into its data, and send that encoded information to your servers when it checks for updates.

When an update has been downloaded, the executable will run and complete the upgrade. (If UAC permission is needed, perhaps see if the permission can be granted by nature of giving UAC permission when installing the update program or such. I’m not up to date on these programming practices.)

As one can imagine, creating new products comes with a cost, and since this program would update software programs that are already paid for—how would you cover the development costs? The answer would be to tie this software to ‘upgrade licenses’.

One of the challenges in getting users to ‘buy in’ to an upgrade license is that you are asking them to pay for something that they haven’t received. You say that the fee will cover upgrades, but what if no upgrades are released in a given year? Has the user ‘wasted’ the money they spent on the upgrade license? Most people want to get ‘something’ for their money up front.

Well with ‘Topaz Update’, you give users the ability to purchase a tangible product alongside the updates that they will receive via the product. They’re not paying ‘for nothing’, they get software that will keep all of their software up to date—whether they are running the Topaz program in question or not.

The update program could include options to download updates overnight (or at set hours) in order to manage their bandwidth. It could allow a user to disable updates of Topaz programs while the computer is being used, and only install updates when the computer is idle. Or it could allow a user to choose whether to update all the software they have installed, or perhaps to only update certain titles that they specify.

When launched, the interface would display a list of all installed Topaz Products, and show the status of each program. (Up to date; update in process; update available—click to download—if they have set it for manual updates, etc) However, it would be optional software. If a user would prefer to use the update tool within each program, things will stay as they are. They don’t have to install the update software to get updates.

However, this could become a promotional tool. The list of Topaz products could include ALL software presently available. While obviously only installed/licensed programs would be updated, you could include a ‘buy now’ button for other titles, and highlight the program if it is currently on special etc.

For users not receiving promotional emails, this would be a low key and non-invasive means to upsell to your customers. So if the program runs in the background, how would they see this page? Have the ‘Topaz Update’ program popup the interface UI after any program updates are completed, to let the user know that an update has been completed. (This would be enabled by default, but could be disabled in the options if a user really wanted a silent upgrade.)

However, when they look at the interface UI, they could see special prices that they may not have known about otherwise. So not only does the program support the purchase of an upgrade license, it gives you another means to reach customers with sale offers.

Since all users get a one year upgrade license free, the software would be available to all users. If they decline to purchase an upgrade license after their free year expires, you could turn the software into a ‘free version’ which would not run automatically. So they are still able to use it to update their programs, but they will have to launch it and click ‘check for updates’. This seems like a fair compromise. They would still have a simple option to keep all their software updated to the extent that updates are supported.

Those with an upgrade license would have the program check automatically though—and pop up a notice to install an update as soon as it becomes available. This enables you to serve those with upgrade licenses in a timely manner, and is the key feature selling point for the upgrade license. They’ll always know they have the latest version of the software installed. While this would be true if they ran the program, why delay? An ‘upgrade license’ user will likely be keen to explore new features as soon as they are available.

Additionally, you could use the software to help manage server load by having it delay an update for a short period of time if the server is busy. Since the user is unaware of an update unless they were to check manually, having their software wait an hour before downloading is not an hardship. Given the size of some updates, this could be a welcome addition to help manage the activity and bandwidth of your update servers.

Last but not least, updated software means fewer technical support requests for problems that have been fixed in recent updates. Heck, you could even take it a step further…

Say you have a client with a problem using the software. If you identify the issue, and a software patch is needed, you could ‘tag’ the serial number of the client’s program and have the update server deliver them a special version of the software to fix the issue. This would enable you to resolve their issue, without releasing a patch to the entire user base. You would of course need to do this at some point, but it would give you time to test the change before releasing it—while being able to resolve the problem for the client right away. Otherwise, you are forced to make the client wait until the next patch.

In any case, I could go on and on listing ways you could turn this into something that would add value to your suite of software. Give it some thought.

1 Like