A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
Say you charge a fee for users to upgrade from version 2 to version 3. How do guys handle this so as to avoid new users buying the upgrade for half price? I'm talking about non 'dial home' software.
Should the upgrade license key be a stand alone license key? Should it only work if an existing key is already in place? It seems to me that the second option is just asking for trouble down the road. We get a lot of 'lost my key' emails. I can see these becoming a nightmare with two keys involved.
What about not making the upgrade link public? Email the link to customers when a new major version is released maybe?
This is one of those situations we should have thought of from Day 1, but most of us never think we'll get to the point of charging for upgrades.
Interested in your own stories about how you do this.
I'm assuming you have a database of users who bought version 2, correct? Only allow those users to get the "upgrade price" for version 3. Simple as that.
No need to complicate it with license files. This is entirely a database problem.
Tuesday, July 16, 2013
We do have a database of registered users. If we do a check before sending them to the payment collector, that means a lot of name matching and changed email problems that can't be automated.
Example: Mr J. Smith, email@example.com bought version 2 in 2009.
John David Smith, firstname.lastname@example.org now thinks he's entitled to a discount on version 3.
It doesn't sound that straight forward to me, unless I'm missing something obvious. It seems like you'd need to eyeball every upgrade purchase before allowing it through.
If you have license keys, just generate different style license keys for version 3. When the people go for an upgrade, ask them to input their old license for the 2->3 discount. Then have some backend code that updates the 2 license to the 3 license once payment has been made.
I actually did this. The workflow was like this:
1. Set up a simple upgrade.html page with a form that had an entry to put in the version 2 license.
2. The user POSTed this form to /somecgi which verified that it was a valid version 2 license
3. If it was valid, the user was redirected to the payment processor *passing along* the old license
4. Once payment was processed the payment processor called my license generator *passing back* the old license.
5. The server validates that the license is a) a v2 license, b) has not already been renewed (simple md5sum(license) + file on filesystem.)
6. Generate version 3 license
It was painless and I think altogether took me about 10 hours to do a few years ago. I later modified this workflow to also allow people to renew using the same logic.
I am a cowboy but it works.
I've got a maintenance plan as part of license. Licensed users can take any release and update whenever they feel like provided that release date fits into the maintenance plan coverage. When maintenance plan expires, the software keeps working but it won't allow updates. Every issued license is automatically triggering a reminder in my user base - I send an email 30 days before maintenance plan expires and then one day after the expiration. Once maintenance plan is payed for, the new license is sent to the user with new coverage.. and so it's going on in circles. This simple system works very well, the only problem I haven't thought about is that sometimes I raise prices, so there is a bit of a manual labor involved to check the original price payed so that upgraders don't get extra charge and stay flat because maintenance plan goes as a percentage of the listed price. Embedding maintenance coverage into a license is much more robust than a simple key. I often asked to give extended maintenance coverage upfront, like several years, to save the enterprises ordering hassle. So it works.. Just keep a reasonable pace of upgrades.
Tuesday, July 16, 2013
I construct a web page that allows people who want to upgrade to enter an old registration code or email address. If they enter a valid value it forwards them to a purchase page with an embedded (and unique) coupon code to give them their upgrade discount. Then they are emailed a new registration code as per normal.
I tell users of upgrades via mass mail-outs. I also tell them about it when they upgrade the software to the latest version. And (obviously) they can find the upgrade pages direct from my website.
This system has worked very well through the last 3 major upgrade cycles. I've tweaked the process somewhat each time to improve results. For example, when I used to mail previous users they had to click a link and then enter their details into a web page. Now, I embed those details directly in the email link and forward them directly to the purchase page (one less step means less abandonments).
Tuesday, July 16, 2013
A quick and dirty solution:
- set up a single-use promo code for your upgrade
- mail each eligible user a unique code
- on your Web site, write "if you are eligible, check your inbox and junk folder (!) for the upgrade coupon; if it's not there, get back to us and we'll re-send".
Dmitry Leskov @Home
Tuesday, July 16, 2013
Validate the previous license as a coupon to an upgrade discount. And this is very important, once the license is used for an upgrade, mark it as an invalid license/coupon in your database otherwise people will pass it to others to get a free discount.
Yes you will get people asking you for their licenses because they lost it, but that's the cost of doing business.
Depending on how you create the license, you may also be able to use their email to look up the previous license. We're playing with this idea. Sure there will be some fraud where someone uses someone else's license, but really that will be pretty rare. Not enough to really worry about it. Worse case, it can only happen once because the license discount is invalidated after the first time. So someone basically just gets an extra license at half price. And you know who they are ;)
But really, just validate based on the previous license. If they forget it, you can have them enter in an email address to have it re-send to them. Even doing it manually is not that big an issue. We have quite a lot of customers and the numbers of license requests is pretty small. I would guess that maybe 1 in 200-500 will lose their license. So until you have about 10,000 customers, that's maybe 1-2 license requests a week.
This is one of those scaling issues that you can postpone until later. Focus more on your product and don't worry about people forgetting their licenses. It's not a big enough issue to worry about until you get pretty big. Like I said, we have quite a few customers and we still haven't taken the time to automate the license retrieval. It's easier for our support person to respond on a case by case basis than it is for us to implement it.
Also people's email addresses will change over time, so quite a few will still need manual assistance. And I suspect most won't use this functionality when it's just easier to send an email. The same people that would rather contact you than read your user manual will do the same for a lost license ;)
Wednesday, July 17, 2013
Remember your goal here is to sale so you need to make it easier for your customers. I would take the users directly to a page where they enter their payment information:
1. The application informs the user there's an upgrade available
2. The user selects to upgrade
3. They're sent to a page that takes the serial number as a parameter from the app
4. The page gets the user profile based on the serial number and also validates it's the right version for the upgrade
5. If everything is ok, ask for payment
6. After payment, modify the license information for the serial number: change the version to the new one
7. Send the user a link to download the new version
8. Ask the user to activate the new version using the same key
As a shameless plug, you can do most of the license and customer management using our product:
Wednesday, July 17, 2013
"Mr J. Smith, email@example.com bought version 2 in 2009.
John David Smith, firstname.lastname@example.org now thinks he's entitled to a discount on version 3."
That's your problem right there. You're not assigning a unique ID to each purchaser, which you should be doing. J Smith at Yahoo should've been assigned ID #1. Then, when J Smith at Gmail tries to buy at the upgrade price, despite never having bought before, what unique ID can he provide you to qualify? That's right: none. He has to pay full price and then be assigned ID #2.
As Wyatt said, it's easy to solve this.
>That's your problem right there. You're not assigning a unique ID to each purchaser, which you should be doing.
Of course we are. But users 'misplace' emails all the time, especially when they've used a product for a number of years. Old Yahoo email addresses, along with the license key and whatever unique ID you gave them, are long forgotten.
Seriously, we get half a dozen 'lost my license key' emails a week, and that only comes into play when a new PC is purchased -- the actual number of long lost order emails (with unique ID), is probably way up in the double digit percentages.
I'm using time based upgrade protection.
My customers are directed to a personalized "store" upon purchase.
They can download licensed installers from the store any time for no cost. They always have free access to the most recent licensed install kit that has been released BEFORE the end of their upgrade protection period.
For example if XY buys the software at 2013-05-01 with the default 30 days U.P., he'll have access to any version released at or before 2013-05-31. He'll be able to download these versions anytime for free. But if he wants access to a version released after 2013-05-31, ha has to extend the protection period by paying a small amount for 1 or 2 years of extra upgrade protection.
Of course they can purchase extended upgrade protection right away when buying the software.
The downside is that some people may receive major upgrades for no extra cost if they register just before such a release. Others may not get anything useful for 1 year extra if they happen to register when the software is no longer updated with big features.
> That's your problem right there. You're not assigning a unique ID to each purchaser, which you should be doing.
There are definitely cases where we have the user's full name, address, email, and they have a purchase order number.
Then, many years later, we hear from a person with a similar name, but different address, living in a different country (often Turkey or China), and they have lost all their original materials including the box, install DVDs, license keys, etc. Sometimes they have the same email, other times it has changed. Very typically they have forgotten what their previous shipping address was.
They usually want to have a current copy, replacement install materials (complete set of which is only available on DVD), new license key, etc.
We do what we can to verify them, if they can prove in any way that it's them. But some of these guys are looking for a copy, searched on the product name, and found a person mentioning it in a forum somewhere, they then take on that person's name. Others hacked into a gmail, hotmail or yahoo account, found customer correspondence with us, and decided to try and get a copy of this thing, along with various other things they found mentioned in that account's emails.
This can be hard to verify. We'll offer, for example, to do a physical mailing to their old address with a password they can recite to say it is them. Usually that is said to be impossible since they are now in China.
Sometimes the email style matches their previous style of communication if we have emails with them before. Sometimes it doesn't match.
One big problem is these cases often take a lot of time to look into and verify them. It would be much easier for us to say if you lose your license key then you lost the product.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz