Best practices for new versions of a product

[LANSRAD]

I have some questions about the best way to setup and manage our digital product sales.

We come out with new versions of our digital products every year or so.

So the “core” product for sale will always be the latest version.

But we will also have an “update” to that product (which is typically a reduced price for existing customers only).

Currently we have it setup with two “products” in the WP eStore such as:

Great Product (full version)

Update to Great Product

The problem I see that we can run into is that with the method above when we come out with a new version of the product, anyone could just refresh their update links and get the latest version.

So I assume in part that we need to add updates to our products as “new” products with something like:

Great Product Full Version 2

Update to Great Product Version 2

Along with this we would have to use new names for the downloadable files that reflect the version.

That would keep the download links straight and prevent someone from grabbing the new versions of the files.

However when we release version 2 of something, we don’t want version 1 to be for sale anymore.

So if we delete the product “Great Product Full Version 2” above and add a new product as “Great Product Version Full 3”, what happens in the shortcode that e-mails the download links (or in the admin feature for it)?

Is the system still going to resend old links?

Also is the method above the best practice or is there a better way to do it?

Finally is there a way to link a product so that a customer could not buy the upgrade for a product unless they had already bought the full version?

Thanks!

[wzp]

********** Let us suppose you have a “1 free upgrade” policy…

Imagine Product ID 100 for: Great Product version 1.00

You charge full price for Product ID 100.

Then, 3 months later, you come out with: Great Product version 1.50

1. You stop selling Product ID 100, but upgrade Product ID 100 to the version 1.50 download.

2. You begin selling version 1.50 as Product ID 150 for full price.

The consequence of this, is buyers of version 1.00 can get version 1.50 for free, by requesting new download links.

Then, next year, you come out with: Great Product version 2.00

1. You stop selling Product ID 150, but upgrade Product ID 150 to the version 2.00 download.

2. You begin selling version 2.00 as Product ID 200 for full price.

The consequence of this, is:

1. Buyers of version 1.00 can get still version 1.50 for free, by requesting new download links.

2. Buyers of version 1.50 can get version 2.00 for free, by requesting new download links.

Now, in “real life,” eStore does not allow you to pick what Product ID numbers you use. You must keep track of whatever numbers get assigned. And, the more you “scale up” the upgrade policy, the more complicated this can get. At some point, like Microsoft, you must make “end of life” decisions for older version downloads.

********** Let us suppose you have a “reduced cost” upgrade policy.

Imagine Product ID 100 for: Great Product version 1.00

You charge full price for Product ID 100.

Then, 3 months later, you come out with: Great Product version 1.50

1. You stop selling Product ID 100, and do not update the download file.

2. You begin selling version 1.50 as Product ID 150 for full price.

For those who bought version 1.00, you want to offer version 1.50 at a reduced cost. You prepare a “special upgrade 1.50 version” that omits a critical code file, that is ONLY PRESENT in the version 1.00 code. So, in order for version 1.50 to work, the buyer must first have a previously installed version 1.00 download.

3. You begin selling the version 1.50 upgrade as Product ID 101 for a reduced price.

The consequence of this, is buyers of the version 1.50 upgrade must have a previously installed version 1.00 product. Companies like FileMaker have been doing this for years.

[LANSRAD]

Thanks for the feedback.

We already have an established method of handling upgrades and when buyers get a free upgrade to the next version (basically for one year).

The actual filenames are different, so that is not a real problem either (and our products are installed by a code signed installer created by SetupBuilder).

We do have end of life cycles on our products.

Having a code dependency (you must have V1 to install V2) is not practical as the files installed by SetupBuilder are ultimately source files and there is no way to do that.

My question about linking it here was simply to restrict the purchase of an upgrade to someone who had already bought the full version, but it appears that will not be possible.

Currently we handle this by NOT automating delivery of upgrades – they have to be checked manually and we were hoping to avoid this.

I am still interested in an answer about whether or not the self-service shortcode to resend links would still send out links for deleted products that no longer existed (I could test this, but it would be nice just to know the answer).

Thanks!

[wzp]

My question about linking it here was simply to restrict the purchase of an upgrade to someone who had already bought the full version, but it appears that will not be possible.

In your “other thread,” you mentioned that you have eMember. Using “Multiple (Stacked) Membership Levels,” you could add a validation level to a user’s existing membership; when they purchase the base product. Then, place the ability to purchase the upgrade in a protected section that requires the user to be a member of that validation level.

https://www.tipsandtricks-hq.com/wordpress-membership/how-to-use-multiple-membership-levels-per-user-291

I don’t think it can get any simpler than that.

[LANSRAD]

Thanks for the suggestion.

I looked at it and while I think it would be easy to setup on something like a bronze, silver, gold membership level set of products, how would that work in our case?

We have about 50-60 products (plus some combos) and each of these gets a paid update every year or so.

It seems that we’d have to create multiple levels in the membership plugin for each of the products we have (plus setting them up in the eStore plugin).

That is a lot to setup and maintain unless I am missing something here.

[Author]

Posts