Why the payment model per user per month is bad
There are a lot of guys (we will not point the finger, so as not to offend 37signals, Atlassian, Zoho, Megaplan, etc.), which make various b2b services and use the per user per month payment model (per user per month). That is the point is that you need to pay monthly for each user. It has been very frustrating for me lately, but this morning, while eating yogurt, I suddenly understood everything .
The problem is that users are not the same. Let's take some task management system and compare how it is used, for example, by a spherical PR-manager and a support employee in a vacuum. Obviously, the first one may set a task once a month for the designer to draw some picture for a press release, and the second, communicating with clients, spends half of the working time in this system. That is, the importance of the system for the performance of different employees may differ significantly, although you need to pay for them in the same way! This fact is very difficult to understand for a person who makes a decision on the implementation of a particular system in a company.
Speaking of customers. Even more interesting picture is obtained if you want to let customers into the system. Sooner or later, everybody wants it, and some systems in general are initially designed for this. For customers, too, have to pay.
Consider an example. Suppose there is a company of 50 people, which serves on average several clients at the same time, so the total number of client users is ~ 200. And this company uses a system that costs $ 10 per user per month. It turns out that you need to pay $ 24,000 per year for customers, while $ 6,000 for their customers.
But as you know, the shortcomings of any system are particularly clearly visible at the limiting values of the input parameters, so imagine that there is some business model in which 5 people serve 1000 customers. Will the company introduce such a system? I guess not. Although it is necessary, because with so many customers per employee, automation is probably not enough.
')
On the other hand, it would seem that what the problem is, include payment for access to the system into account? There are a lot of difficulties that make this venture an unpleasant hemorrhoids. Firstly, in principle, it is difficult to explain to the client why he should pay for this system (let us better just write and call you by mail?). Secondly, it is even harder to make this payment fair and transparent. I will not dwell here in detail, but believe me, this is difficult. Most of the problems arise because the contract and the account are usually one (sometimes two, well, ok, three), and the client wants to add or remove his employees from the system all the time. And if there are 50 such clients, it will already be very stressful.
Many developers offer not only SaaS, but also standalone versions of their systems. The most striking thing is that for standalone it is proposed to pay in the same way - per user per month. This is even more difficult to understand, because if in the case of SaaS a developer constantly bears the costs associated with infrastructure maintenance, then for standalone there are no such expenses.
What models of payment services seem fair to me?
For SaaS - payment depending on the resources consumed. Developers should consider their costs to be fair and optimize costs. I didn’t come up with this model at all, and I think you all know the guys who use it. Look at this beauty for example.
For stanalone - a one-time fixed payment upon purchase and then an annual renewal of a fixed license again (something like the type of royalty payments). In addition, upgrades must be paid.
Whatever the misunderstandings, I’m a big supporter of SaaS and, sorry for the expression, I think that there’s a future. But it seems to me that the payment mechanisms for most of the systems present in the market and the prices arising from them seriously hamper the development of the industry. In this article I talk about the concepts and from the client, although I try to think of developers. Perhaps I am missing a number of technical issues that reduce all my arguments to nothing, so I would very much like to hear an opinion from the other side of the barricades.
The problem is that users are not the same. Let's take some task management system and compare how it is used, for example, by a spherical PR-manager and a support employee in a vacuum. Obviously, the first one may set a task once a month for the designer to draw some picture for a press release, and the second, communicating with clients, spends half of the working time in this system. That is, the importance of the system for the performance of different employees may differ significantly, although you need to pay for them in the same way! This fact is very difficult to understand for a person who makes a decision on the implementation of a particular system in a company.
Speaking of customers. Even more interesting picture is obtained if you want to let customers into the system. Sooner or later, everybody wants it, and some systems in general are initially designed for this. For customers, too, have to pay.
Consider an example. Suppose there is a company of 50 people, which serves on average several clients at the same time, so the total number of client users is ~ 200. And this company uses a system that costs $ 10 per user per month. It turns out that you need to pay $ 24,000 per year for customers, while $ 6,000 for their customers.
But as you know, the shortcomings of any system are particularly clearly visible at the limiting values of the input parameters, so imagine that there is some business model in which 5 people serve 1000 customers. Will the company introduce such a system? I guess not. Although it is necessary, because with so many customers per employee, automation is probably not enough.
')
On the other hand, it would seem that what the problem is, include payment for access to the system into account? There are a lot of difficulties that make this venture an unpleasant hemorrhoids. Firstly, in principle, it is difficult to explain to the client why he should pay for this system (let us better just write and call you by mail?). Secondly, it is even harder to make this payment fair and transparent. I will not dwell here in detail, but believe me, this is difficult. Most of the problems arise because the contract and the account are usually one (sometimes two, well, ok, three), and the client wants to add or remove his employees from the system all the time. And if there are 50 such clients, it will already be very stressful.
Many developers offer not only SaaS, but also standalone versions of their systems. The most striking thing is that for standalone it is proposed to pay in the same way - per user per month. This is even more difficult to understand, because if in the case of SaaS a developer constantly bears the costs associated with infrastructure maintenance, then for standalone there are no such expenses.
What models of payment services seem fair to me?
For SaaS - payment depending on the resources consumed. Developers should consider their costs to be fair and optimize costs. I didn’t come up with this model at all, and I think you all know the guys who use it. Look at this beauty for example.
For stanalone - a one-time fixed payment upon purchase and then an annual renewal of a fixed license again (something like the type of royalty payments). In addition, upgrades must be paid.
Whatever the misunderstandings, I’m a big supporter of SaaS and, sorry for the expression, I think that there’s a future. But it seems to me that the payment mechanisms for most of the systems present in the market and the prices arising from them seriously hamper the development of the industry. In this article I talk about the concepts and from the client, although I try to think of developers. Perhaps I am missing a number of technical issues that reduce all my arguments to nothing, so I would very much like to hear an opinion from the other side of the barricades.
Source: https://habr.com/ru/post/117407/
All Articles