7 ms·

Because your customers are going to be more technical I would do the utility pricing. Pay per unit of usage. If you need help with pricing, email me. Our com

by ljd 14y ago

Because your customers are going to be more technical I would do the utility pricing. Pay per unit of usage. If you need help with pricing, email me. Our company does algorithmic pricing via a REST API, I'll give Keen access for free. To address your listed cons to utility style pricing: 1) Products aren't turned into a commodity because of how they are priced. They are commoditized when many perfect substitutions exist in the market. 2) I'm not sure if "not predictable" will go over well with your audience. Maybe you could use your own product to help people predict their bill with you. It would be a neat application of your software.

akavi 14y ago
You vastly underestimate the value of predictability in billing to a business's "Chief Fretting Officer". If you asked companies if they'd rather pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter. And if you don't understand why, then you've never spent any amount of time pondering a business's cash flow.
- JoshTriplett 14y ago
  If you asked them that way they'd opt for the former. However, most pricing structures don't provide such a clear-cut range; the edges feel quite fuzzy, and that uncertainty does indeed drive customers towards predictable-but-higher pricing.
- ljd 14y ago
  My above statement is actually aligned with your sentiment. I think people use data analysis to help predict future events like how many customers you'll have or how much an expense will be. I figured, since Keen is in the business of helping people with those predictions it would be a really awesome application of their own API. Customers could see their usage as part of the visualizing product and it would help them predict their bill.
- codegeek 14y ago
  "pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter" Why so ? You are perhaps referring to a business's ability to project/forecast cashflows which is critical but even then, if the number is always going to be less than or equal to 500, I would rather choose the first option.
  - patio11 14y ago
    At my old day job, my boss literally instructed me to pay $200 rather than rand(10..40) because otherwise he would have been committing to a minute of work every month updating an ERP entry. Plus, not his money, but certainly his minute...
    - grueful 14y ago
      New pricing strategy: the low-end tier is metered. That's also a big argument in favor of formulating seat-based pricing models as blocks as opposed to per seat. It reduces the update frequency.
      - ovi256 14y ago
        Metered low-end looks similar to what AWS does, doesn't it ? Spot prices are metered, but if you want to get a flat fee per month, no worries, you can get the reserved instances. Which also have a better bang per buck.
        rmc 14y ago
        reserved instances aren't totally flat fee. Reserved instances allow you to pay a fixed cost up front for a reduction for the rest of the month.
    - codegeek 14y ago
      "not his money" In that case, totally agree with you. If, however, it was his own money, I am sure it would be a different story.
- bduerst 14y ago
  Nope. You can use accounting to absorb the volatility.
- runako 14y ago
  I agree, but only because in practice the choice is usually a little different: - always pay $500 vs. pay a random amount between $100 and $500, except when you have a really heavy month and you pay $3,000. Utility pricing without the ability to set caps is problematic.
- kirkers 14y ago
  The discussion here is exactly why we started the conversation. Certainly, if we go this route, we'll make sure our users can readily monitor their usage so as to minimize surprises. Even still, we don't want our customers to have to kill the service in the middle of a billing cycle.
- bromley 14y ago
  And also the fear of an app (and consequently the API) getting hammered by the mobile equivalent of a clickbot (should such a thing exist), or some developer on the product accidentally programming in an infinite loop. Oops, there goes thousands of dollars. FWIW when I was recently involved in pricing an API, after much thought I decided the best option was tiered pricing with different rate limits (requests per hour) at each tier. At least with that structure you don't have to worry about angry customers with huge bills or customers bankrupting you with usage gone wild that they'll never be able to pay for. The other risk of pure usage based pricing is that it attracts a cost-minimization approach to usage. That was my original plan but speaking to prospects put me off when I realized that many were willing to forgo all business sense and invest crazy amounts of development time to minimize API costs. And you still have to support them. (NB Yes you can have a base charge but many seem to think that inherently unfair when they have to pay for usage on top.)
lunaru 14y ago
I've always found Mailgun's pricing intuitive yet technical friendly. There's some tiering involved, but it's just a nice wrapper around utility pricing that doesn't feel like you're negotiating in cents.

by ljd 14y ago

akavi 14y ago

You vastly underestimate the value of predictability in billing to a business's "Chief Fretting Officer". If you asked companies if they'd rather pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter. And if you don't understand why, then you've never spent any amount of time pondering a business's cash flow.

JoshTriplett 14y ago
If you asked them that way they'd opt for the former. However, most pricing structures don't provide such a clear-cut range; the edges feel quite fuzzy, and that uncertainty does indeed drive customers towards predictable-but-higher pricing.
ljd 14y ago
My above statement is actually aligned with your sentiment. I think people use data analysis to help predict future events like how many customers you'll have or how much an expense will be. I figured, since Keen is in the business of helping people with those predictions it would be a really awesome application of their own API. Customers could see their usage as part of the visualizing product and it would help them predict their bill.
codegeek 14y ago
"pay a random amount between 100$ and 500$, or always pay 500$, 9 out of 10 would opt for the latter" Why so ? You are perhaps referring to a business's ability to project/forecast cashflows which is critical but even then, if the number is always going to be less than or equal to 500, I would rather choose the first option.
- patio11 14y ago
  At my old day job, my boss literally instructed me to pay $200 rather than rand(10..40) because otherwise he would have been committing to a minute of work every month updating an ERP entry. Plus, not his money, but certainly his minute...
  - grueful 14y ago
    New pricing strategy: the low-end tier is metered. That's also a big argument in favor of formulating seat-based pricing models as blocks as opposed to per seat. It reduces the update frequency.
    - ovi256 14y ago
      Metered low-end looks similar to what AWS does, doesn't it ? Spot prices are metered, but if you want to get a flat fee per month, no worries, you can get the reserved instances. Which also have a better bang per buck.
      - rmc 14y ago
        reserved instances aren't totally flat fee. Reserved instances allow you to pay a fixed cost up front for a reduction for the rest of the month.
  - codegeek 14y ago
    "not his money" In that case, totally agree with you. If, however, it was his own money, I am sure it would be a different story.
bduerst 14y ago
Nope. You can use accounting to absorb the volatility.
runako 14y ago
I agree, but only because in practice the choice is usually a little different: - always pay $500 vs. pay a random amount between $100 and $500, except when you have a really heavy month and you pay $3,000. Utility pricing without the ability to set caps is problematic.
kirkers 14y ago
The discussion here is exactly why we started the conversation. Certainly, if we go this route, we'll make sure our users can readily monitor their usage so as to minimize surprises. Even still, we don't want our customers to have to kill the service in the middle of a billing cycle.
bromley 14y ago
And also the fear of an app (and consequently the API) getting hammered by the mobile equivalent of a clickbot (should such a thing exist), or some developer on the product accidentally programming in an infinite loop. Oops, there goes thousands of dollars. FWIW when I was recently involved in pricing an API, after much thought I decided the best option was tiered pricing with different rate limits (requests per hour) at each tier. At least with that structure you don't have to worry about angry customers with huge bills or customers bankrupting you with usage gone wild that they'll never be able to pay for. The other risk of pure usage based pricing is that it attracts a cost-minimization approach to usage. That was my original plan but speaking to prospects put me off when I realized that many were willing to forgo all business sense and invest crazy amounts of development time to minimize API costs. And you still have to support them. (NB Yes you can have a base charge but many seem to think that inherently unfair when they have to pay for usage on top.)

lunaru 14y ago

I've always found Mailgun's pricing intuitive yet technical friendly. There's some tiering involved, but it's just a nice wrapper around utility pricing that doesn't feel like you're negotiating in cents.