User Role in SaaS pricing models
SaaS pricing models may be based in a number of factors, or even combination of factors. For example, an ERP application may be priced per seat (per user) while a retail banking application may be priced on a transaction basis. A Sales Force Automation application may be priced on a generated-revenue basis etc.
I can’t help thinking, though, that even the simplest business application has different “user roles”. Perhaps, an advanced role that does most of the tasks and a lighter role that only executes a few trivial tasks. There may be another “super user” role that has access to the system parameters. There are more examples like that, but I think you get the point.
Having said that, I would – as a SaaS buyer – go into the temptation to ask for special discounts for those “low level” roles. The reasoning behind this is that I will activate some users that a) add no significant load on the system and b) give my enterprise relatively low value (compared to high authority, “do-it-all” users). Therefore, I would not be willing to pay the same amount of money for these users and you (the SaaS vendor) should not ask for the same amount of money.
Right? I’m not sure… See, while adding the “significance” of the user role in the SaaS pricing scheme seems logical, it can backfire on you: You have to be clear as to what your pricing tiers are; which kind of users fits in what tier. Precisely define the fine line between role “A” and role “B”. And you have to be precise, otherwise the potential customer may argue that “John Doe can’t be considered a high user because he…” and “Jane Doe is surely not a system administrator since she…”. See what happened? In your effort to establish a more “fair” pricelist, you have opened doors for prospects to challenge your tactics, your reasoning, your very pricelist.
For the above reasons, I would suggest that applying “user role tiers” in your pricing policy may not be a good way to become competitive. You may want to consider other, simpler pricing schemes but, surely, schemes that are based on undisputable entities, such as “number of users”, “number of modules”, “Gigabytes used” etc.
I can’t help thinking, though, that even the simplest business application has different “user roles”. Perhaps, an advanced role that does most of the tasks and a lighter role that only executes a few trivial tasks. There may be another “super user” role that has access to the system parameters. There are more examples like that, but I think you get the point.
Having said that, I would – as a SaaS buyer – go into the temptation to ask for special discounts for those “low level” roles. The reasoning behind this is that I will activate some users that a) add no significant load on the system and b) give my enterprise relatively low value (compared to high authority, “do-it-all” users). Therefore, I would not be willing to pay the same amount of money for these users and you (the SaaS vendor) should not ask for the same amount of money.
Right? I’m not sure… See, while adding the “significance” of the user role in the SaaS pricing scheme seems logical, it can backfire on you: You have to be clear as to what your pricing tiers are; which kind of users fits in what tier. Precisely define the fine line between role “A” and role “B”. And you have to be precise, otherwise the potential customer may argue that “John Doe can’t be considered a high user because he…” and “Jane Doe is surely not a system administrator since she…”. See what happened? In your effort to establish a more “fair” pricelist, you have opened doors for prospects to challenge your tactics, your reasoning, your very pricelist.
For the above reasons, I would suggest that applying “user role tiers” in your pricing policy may not be a good way to become competitive. You may want to consider other, simpler pricing schemes but, surely, schemes that are based on undisputable entities, such as “number of users”, “number of modules”, “Gigabytes used” etc.
Comments
Post a Comment