Login

I’m trying to figure out how to set a price for a new SaaS feature that uses a consumption-based model, but I’m stuck on how to define a fair billing unit. It feels like if the unit is too abstract, customers will get confused about what they’re actually paying for, but if it’s too granular, the invoicing becomes a nightmare.

I spent a few weeks staring at the numbers and tried four different units. We started with per action then moved to per hour then per data burst. Customers kept asking what counts as an action and how a burst is measured. The invoicing got messy and the notes were unclear. We shipped a test bill with all three units and asked what stuck in the cards and what tripped the finance team. In the end we stopped chasing a single clean unit and called it a usage bucket that lines up with our logs

One practical path is to pick a unit that ties to value and is easy to log. If the feature is a data export bill per gigabyte exported or per API call with a simple cap. If it is heavy compute bill per compute hour with blocks of 15 minutes. Add a small free tier and a harmless monthly minimum to avoid big bills for tiny usage

Sometimes I wonder if the real problem is not the unit but how we describe value to the user. We tried a clean one liner in the docs and it only confused developers who read the logs. Then we went back to a real world example and saw people nodding. Maybe we should show a real scenario in the invoice rather than an abstract unit

Do you think a tiered approach could help avoid a single brittle unit?

Login
Username:
Password:	Lost Password?
	Remember me