4 ms·

Definitely wrong. Vendors like predictable revenue. Pricing based on actual usage doesn't provide this.

TillE 5y ago
Yeah, the ideal is to get customers (business or consumer) on a monthly subscription regardless of how much they use the software. There's just no advantage to this in the vast majority of cases.
- ramoz 5y ago
  Ideal is multi-year for enterprise software
- pbuzbee 5y ago
  Yes, to me this incentivizes customers to use your software as little as possible, which seems like the opposite of what you would want to encourage: lock in.
mushyhammer 5y ago
Is AWS the proof you’re wrong or just the exception?
- bawolff 5y ago
  In aws, if you aren't using it someone else could be. With SAAS office software, this is not the case or at least capacity is much more divorced from usage.
- alpaca128 5y ago
  AWS isn't a software product as defined in the post though. It goes more along the lines of Office 365 or Adobe's tools, but those are just standard subscriptions and I doubt that'll change any time soon.
- charcircuit 5y ago
  The difference with AWS (eg EC2) is the people who run their workload in a few hours on an instance is the minority. Most people are going to have a base amount of servers. The hourly billing tries to encourage customers to spend more to scale their resources with demand of their service. Maybe having an extra N nodes on stand by isn't affordable for a customer, but you they could afford those extra N nodes during peak hours.
- jerf 5y ago
  For most or all AWS resources it makes sense to bill by relatively small time increments because you really are using hardware for those defined time increments. AWS charges by time increments because that is exactly what they are selling. Most software runs locally. "What you say, jerf? It's 2022, man, keep up." By that I mean, in terms of resource consumption, most software uses mostly local resources. Your Slack server footprint is tiny compared to the resources eaten by your slack client. Websites explode in RAM and CPU compared to what it took to serve the resources to your browser. Streamed video is expensive to encode once, but will be decoded somewhere locally millions of times. Especially for systems large enough to be worth optimizing and where they're not some guy's first Ruby on Rails project (built before he really got how not to make 15,000 queries per web page) or something. Servers for Slack or Office 365 or a streaming video service are certainly Big Iron and expensive, but compared to the sum total of resources sitting on the client side they're tiny. Charging by the second for Office 365 wouldn't be smart, because their marginal costs aren't all that related to how many seconds of use there is. (They're certainly correlated, obviously, but I can find you signals that are much more strongly correlated than simply seconds of use, like document size and how many times they reload the page.) So you get all the disadvantages of your user sitting there thinking "How fast can I get this done? Every second I delay I'm paying more!", but you're not saving the resources or anything. Pure time-based costs make sense if you're selling truly time-based resources, but are questionable in other places. For a lot of services, if not the majority, the true nature of the marginal costs are really hard to divine, and the users don't much care anyhow, and the marginal costs are much smaller than you want to charge anyhow, so it's much easier to just charge them $10/month and get on with it, rather than do all the complicated math to discover that this user's marginal cost was $0.33 this month. (If my choice of example numbers confuses you, be sure you know what a marginal cost is: https://www.shopify.com/encyclopedia/marginal-cost https://www.shopify.com/encyclopedia/marginal-cost . There's a lot more to pricing a cloud service than marginal costs. With modern hardware, networking, and even a cursory stab at some optimization by the developers, the marginal cost of a lot of useful cloud services can be tiny. There's useful cloud services out there where the marginal cost of a user is probably less than a penny per month. All the other costs can be quite non-trivial, though!)
  - mushyhammer 5y ago
soared 5y ago
Agreed. The division of Oracle I worked at had revenue that was close to impossible to predict and they ended up making huge cuts to revenue just to convert it from usage based to monthly recurring. At the time they also did not know if the division was profitable or not because it was so difficult to track usage based revenue. Spoiler alert, they were gushing losses and had lay offs/reorgs for a long time.

Yeah, the ideal is to get customers (business or consumer) on a monthly subscription regardless of how much they use the software. There's just no advantage to this in the vast majority of cases.

ramoz 5y ago
Ideal is multi-year for enterprise software
pbuzbee 5y ago
Yes, to me this incentivizes customers to use your software as little as possible, which seems like the opposite of what you would want to encourage: lock in.

mushyhammer 5y ago

Is AWS the proof you’re wrong or just the exception?

bawolff 5y ago
In aws, if you aren't using it someone else could be. With SAAS office software, this is not the case or at least capacity is much more divorced from usage.
alpaca128 5y ago
AWS isn't a software product as defined in the post though. It goes more along the lines of Office 365 or Adobe's tools, but those are just standard subscriptions and I doubt that'll change any time soon.
charcircuit 5y ago
The difference with AWS (eg EC2) is the people who run their workload in a few hours on an instance is the minority. Most people are going to have a base amount of servers. The hourly billing tries to encourage customers to spend more to scale their resources with demand of their service. Maybe having an extra N nodes on stand by isn't affordable for a customer, but you they could afford those extra N nodes during peak hours.
jerf 5y ago
For most or all AWS resources it makes sense to bill by relatively small time increments because you really are using hardware for those defined time increments. AWS charges by time increments because that is exactly what they are selling. Most software runs locally. "What you say, jerf? It's 2022, man, keep up." By that I mean, in terms of resource consumption, most software uses mostly local resources. Your Slack server footprint is tiny compared to the resources eaten by your slack client. Websites explode in RAM and CPU compared to what it took to serve the resources to your browser. Streamed video is expensive to encode once, but will be decoded somewhere locally millions of times. Especially for systems large enough to be worth optimizing and where they're not some guy's first Ruby on Rails project (built before he really got how not to make 15,000 queries per web page) or something. Servers for Slack or Office 365 or a streaming video service are certainly Big Iron and expensive, but compared to the sum total of resources sitting on the client side they're tiny. Charging by the second for Office 365 wouldn't be smart, because their marginal costs aren't all that related to how many seconds of use there is. (They're certainly correlated, obviously, but I can find you signals that are much more strongly correlated than simply seconds of use, like document size and how many times they reload the page.) So you get all the disadvantages of your user sitting there thinking "How fast can I get this done? Every second I delay I'm paying more!", but you're not saving the resources or anything. Pure time-based costs make sense if you're selling truly time-based resources, but are questionable in other places. For a lot of services, if not the majority, the true nature of the marginal costs are really hard to divine, and the users don't much care anyhow, and the marginal costs are much smaller than you want to charge anyhow, so it's much easier to just charge them $10/month and get on with it, rather than do all the complicated math to discover that this user's marginal cost was $0.33 this month. (If my choice of example numbers confuses you, be sure you know what a marginal cost is: https://www.shopify.com/encyclopedia/marginal-cost https://www.shopify.com/encyclopedia/marginal-cost . There's a lot more to pricing a cloud service than marginal costs. With modern hardware, networking, and even a cursory stab at some optimization by the developers, the marginal cost of a lot of useful cloud services can be tiny. There's useful cloud services out there where the marginal cost of a user is probably less than a penny per month. All the other costs can be quite non-trivial, though!)
- mushyhammer 5y ago

soared 5y ago

Agreed. The division of Oracle I worked at had revenue that was close to impossible to predict and they ended up making huge cuts to revenue just to convert it from usage based to monthly recurring. At the time they also did not know if the division was profitable or not because it was so difficult to track usage based revenue. Spoiler alert, they were gushing losses and had lay offs/reorgs for a long time.