Pricing per seat is a better model for all parties.
- It's more predictable for the business (you can model what you'll pay in advance), so the business can model their total expenses and make a budget. I don't see how a customer could accurately predict how many mobile notifications per month they're going to generate for a product they're not using yet -- it depends on the personal preferences of every employee what notification settings they choose. Any business with a procurement function is going to look very skeptically at unpredictable costs.
- It's more predictable for us -- metered per notification would have all sorts of weird seasonality.
- A per-notification fee would have perverse incentives for us, like "we made the product really spammy with push notifications and it doubled our revenue". We would try very hard to resist that, but incentive structures are powerful, and we want our financial incentive to be to maximize the number of people who are happily self-hosting Zulip, not some other weird metric.
- A per-notification fee would have perverse incentives for the business, like the manager asking people to toggle their settings to save money rather than to choose the settings that make them most productive.
Are you using Zulip exclusively for paid team members in a first-world country? It's hard to imagine this pricing being a significant expensive if you are.
(In any case, our sales team would be very happy to discuss your or anyone else's individual situation -- specific situations are very helpful for figuring out gaps in policies where it might make sense to introduce a new plan)
> Are you using Zulip exclusively for paid team members in a first-world country? It's hard to imagine this pricing being a significant expensive if you are.
The problem is not that it’s expensive, it’s that it was sold as free, and that was a major component in getting the go ahead to use it. As soon as money becomes part of the equation the process of me ‘just using tulip’ becomes 100x more involved, and the balance swings heavily towards ‘just dealing with Teams’.
Of course that doesn’t really mean anything from a business perspective since we weren’t –and won’t be– paying either way. Just wanted to make it clear.
- It's more predictable for the business (you can model what you'll pay in advance), so the business can model their total expenses and make a budget. I don't see how a customer could accurately predict how many mobile notifications per month they're going to generate for a product they're not using yet -- it depends on the personal preferences of every employee what notification settings they choose. Any business with a procurement function is going to look very skeptically at unpredictable costs.
- It's more predictable for us -- metered per notification would have all sorts of weird seasonality.
- A per-notification fee would have perverse incentives for us, like "we made the product really spammy with push notifications and it doubled our revenue". We would try very hard to resist that, but incentive structures are powerful, and we want our financial incentive to be to maximize the number of people who are happily self-hosting Zulip, not some other weird metric.
- A per-notification fee would have perverse incentives for the business, like the manager asking people to toggle their settings to save money rather than to choose the settings that make them most productive.
Are you using Zulip exclusively for paid team members in a first-world country? It's hard to imagine this pricing being a significant expensive if you are.
If not, check the sponsorships and discounts section of https://zulip.com/plans/#self-hosted
(In any case, our sales team would be very happy to discuss your or anyone else's individual situation -- specific situations are very helpful for figuring out gaps in policies where it might make sense to introduce a new plan)