How did you justify moving to subscriptions for on-premise version?
What fraction the subscription price is of the ownership price?
Do you enforce the on-premise subscription license, and if yes - how?
How did you justify moving to subscriptions for on-premise version?
What fraction the subscription price is of the ownership price?
Do you enforce the on-premise subscription license, and if yes - how?
Essentially the on-prem version was very close to a subscription to begin with in that there was yearly support. You could not pay it, but then you got no upgrades or support and for most businesses thatās not desirable for a critical system like this.
That said, some people would wait to pay until they needed those things which was a bit annoying. The subscription now will turn off their installation so they do have to pay (via license file), but really thatās in both our best interests as having people on old unsupported installs is bad for them and for us.
The subscription is tiered and so is hard to directly compare but overall we moved the pricing to be a fair bit cheaper on average especially if you fall near the top of a tier.
For example, if you have 20 agents. Previously it would have cost you $4,000 in license costs first year and $1,580 in support yearly. Now itās $2,000/year.
I should note that that is cheaper but thereās some method to the madness which seems to be paying off (itās still early, only moved to this last summer). That is that part of the goal of the pricing and the tiers is to get more users into the system.
The per user pricing really causes companies to limit access to only people who need it for daily work. The idea with affordable tiers is to open them up to adding more users. So, in the past you would have only purchased the 20 users who are front line support. But really, the help desk works best when managers and second level folks are also in there. So you may actually buy the āup to 50ā tier at $4,000 in order to fit all them in and still be at a reasonable price.
This is better for them because they get everyone who has any interactions into the system. Itās great for us because A) it will work better for them B) More users are exposed to HelpSpot and then move it to other departments, to new companies when they leave, etc.
Do you have warning screens before and a grace period after the license is expired? Or it is just a hard-stop at the expiration date?
Yes, I agree.
Iāve heard Spolsky argument that providing an unlimited license to entities like Oracle is not smart; but in fact it is not Oracle who buys a license, it is some department or even a work group that gets it. And that department is not sharing their installation with other departments, because that would mean accepting the costs that other groupsā usage may cause.
So the unlimited license is not really unlimited, but it permits a free familiarization of more users with the product, and in the long run ā more licenses bought if the users like what they see.
Yes, of course grace screens lot of emails, etc.
Unlimited licenses are bad We used to have them and def donāt suggest them.
The tiered system is better. Just have huge tiers if needed.
Did you get burned by them in practice, or it is just a cautious general approach?
Def made less money and in general creates a lot of oddities if youāre trying to keep things simple and not doing custom contracts. Where is the line for a company like Oracle? For $8000 do they literally get to use it in every company, department and subsidiary?
Big coās like that honestly wouldnāt even try but āsmallerā ones do. Say a college with 10 schools within it. Do all 10 of them get to use it under the unlimited license? Contractors? Consultants? Partner organizations?
Hey, just a shameless plug here. I recently launched a closed beta for a product licensing API that helps to streamline doing feature-based licensing like youāve described, with support for more simplistic licensing models as well: https://keygen.sh. It can be integrated pretty easily with Stripe using webhook events.
Let me know if youād like to take the beta for a spin.
@ian With tiered pricing is there not a danger of people feeling like they are āwastingā money? E.g. lets say there is a 10-15 person tier, but I only have 10 people - arenāt I going feel like I am wasting money on 4 users I donāt need?
That is true, but we have seen basically 0 pushback on that. I think for a few reasons. First, if you look at the per user pricing even at 10 users (so if you calculate a monthly or yearly cost there) we still compare very favorably to competing systems.
Second, for a help desk app itās actually pretty rare to have that scenario of exactly X people need access. Thereās always more people youād like to have in the system, just that youāre not willing to pay for them.
For example, if you have a help desk of 10 people you likely are a company of at least 50 or often much more. So when paying per person you might only buy 10, but if you have an extra 5 itād be great to have the ops manager in there and the CEO always likes to nose around in the reports, etc etc.
Iām most fearful on the other end where you hit 15 and now have a ābigā cost to move up a tier. That said, at least itās one point of resistance we can sell them on vs every single sale being a point of resistance. That said, since we havenāt been doing this that long we havenāt had that many companies move up tier yet so weāll see.
The goal of my suggestion is to address the concern of expiring licenses (which you will need to use to support a subscription model): āWhat happens if you go out of business? I can no longer use my license, and I canāt buy a new one.ā
My approach is a method to operate a subscription model, but allow the user to continue to use the software.
sorry I meant hitting 25 yeah.
It is a wide range, but without a somewhat wide range you end up back in people having to come back a lot to buy another 5 another 5, etc. It might be too wide weāll see
On the flip side of that argument, Atlassian sells billions of dollars with even wider tiers.
Not sure of the specifics of your accounting app, but Reckon Accounts (what used to be Quicken Australia) offer both perpetual & subscription licences on desktop. Their Home & Business version sells for $195/year or $685 perpetual, for example.
Personally I prefer a perpetual license, my accounting data is the last thing I want to lose access to. But I know plenty of businesses are happy using Xero or Quicken Online or other cloud SaaS providers.
Did you consider read-only users?
A typical scenario for me is when another group requires my input on a issue they have, and the easiest would be to give me an access to their ticketing system. They arenāt, however, usually willing to create an account for everyone - to avoid running out of license users count. And so I get a mind-numbing copy-paste from the ticket, usually hard to parse.
I feel read-only users would greatly simplify the āspreading the word within the corporationā goal , while not breaking the license buckets.
Isnāt Quicken updating the ruleset in their application every year in accordance to this year laws? If yes, this is what they charge the subscription for.
On the other hand, if we can position subscription as installments, it possibly can be used even for applications that do not get data updates regularly. User will see a lower price, early cancellation policy (āit is OKā), and the high price barrier is removed, no? But functionally it is still the same subscription, only with a final date (which should be above average use period).
Thatās part of it, and the subscription includes automatically downloading share price data from trading exchanges. But if you opt for their subscription license and donāt renew, the application stops working and āyou may not be able to access the Software at all (including printing out or viewing any of your data or records)ā, to quote the terms and conditions.
Note Iām referring to Reckon Accounts, which had the Quicken license in Australia until 2012. Looks like Quicken Desktop in the US doesnāt have the same pricing model.
It could be just a liability prevention from their side. If someone does not update the data, and then make financial decisions based on those data, it could mean some bad publicity for Reckon, even tho they are not at fault. So it is better to brick the application.
Another option is to prevent updating after the license has expired.
In my market, SQL Server tools, the most common approach is a perpetual license with a support & upgrades subscription. Varies whether all upgrades are halted immediately after the subscription expires or at the next major release, but itās a hard cutoff.
Iāve debated going the feature-gating route, but this way is definitely simpler. If the user runs into an issue thatās been fixed in a later release, the response is āplease upgradeā. Downsides: Feels less nice, and you have to maintain download links for earlier releases.
My policy for old versions - if user wants something to work better - he has to upgrade. However if itās a bug then I just give them free upgrade for latest version. In my case itās not worth to implement bug fix twice if payoff is 1-2 upgrade licenses.