3 ms·

Simplicity in pricing structure is a feature. Spare your users the burden and charge them a consistent amount. Prorate this, discount that, and you'll quickly c

by lunaru 16y ago

Simplicity in pricing structure is a feature. Spare your users the burden and charge them a consistent amount. Prorate this, discount that, and you'll quickly confuse not just your users, but your billing code (if you're handling it in-house) as well as your legal documents. For example, with our app, the TOS specifies you're paying for a monthly interval with no refunds for unused time. Feel free to take a look at the TOS for our app. IANAL, but I'm willing to help. That said, I'm not so sure what I've said can be classified as "best practice", but I think it's a fairly common way to run SaaS billing for a small shop.

matt1 16y ago
Thanks, your Terms of Service are excellent [1]. For others, here's the applicable section: Service of the Applications is billed in advance on a monthly basis and is non-refundable. There will be no refunds or credits for partial months of service, upgrade/downgrade refunds, or refunds for months unused with an open account. What if a customer signs up for your Solo plan ($15/mo), and then immediately upgrades to Agency ($49/mo). How much is he charged and when? And what about the other way around: Agency to Solo. They don't get a credit for $34 when they downgrade to apply to future payments? With a service like Recurly, they're credited that $34 and that's applied to future bills. In your app, it seems like they'd pay the $49, then $15 when they downgrade and then $15/mo thereafter, correct? [1] http://www.roninapp.com/site/tos http://www.roninapp.com/site/tos
- lunaru 16y ago
  Let the user win in the normal case. If they pay for the smaller plan, and the next day they upgrade, they'll happily receive the larger plan until the next billing cycle. This also means they can cheat the system by paying, the next day upgrading, then downgrading right before the next billing cycle. Oh well, we've got bigger fish to fry. If they love your service enough to live with the pain of having to time their upgrades and downgrades, you have a gold mine in your hands and you're probably not hurting from being unable to collect your $34. As for the downgrade case, the TOS applies in this case. Fortunately, very rarely do our customers downgrade. After all, we've built a service that helps them build their company (and I gather jMockups is much the same). It hurts us more than just financially to see them shrink in size. At the end of the day, we're running on a streamlined billing system that doesn't take more than a paragraph to explain. And this helps because we also put up an explanation right on the account upgrade page. More importantly, we're not wrestling with unmanageable amounts of code or fretting about a third party vendor meeting business needs - more time to spend improving the product in more important ways.

by lunaru 16y ago

matt1 16y ago

Thanks, your Terms of Service are excellent [1]. For others, here's the applicable section: Service of the Applications is billed in advance on a monthly basis and is non-refundable. There will be no refunds or credits for partial months of service, upgrade/downgrade refunds, or refunds for months unused with an open account. What if a customer signs up for your Solo plan ($15/mo), and then immediately upgrades to Agency ($49/mo). How much is he charged and when? And what about the other way around: Agency to Solo. They don't get a credit for $34 when they downgrade to apply to future payments? With a service like Recurly, they're credited that $34 and that's applied to future bills. In your app, it seems like they'd pay the $49, then $15 when they downgrade and then $15/mo thereafter, correct? [1] http://www.roninapp.com/site/tos http://www.roninapp.com/site/tos

lunaru 16y ago
Let the user win in the normal case. If they pay for the smaller plan, and the next day they upgrade, they'll happily receive the larger plan until the next billing cycle. This also means they can cheat the system by paying, the next day upgrading, then downgrading right before the next billing cycle. Oh well, we've got bigger fish to fry. If they love your service enough to live with the pain of having to time their upgrades and downgrades, you have a gold mine in your hands and you're probably not hurting from being unable to collect your $34. As for the downgrade case, the TOS applies in this case. Fortunately, very rarely do our customers downgrade. After all, we've built a service that helps them build their company (and I gather jMockups is much the same). It hurts us more than just financially to see them shrink in size. At the end of the day, we're running on a streamlined billing system that doesn't take more than a paragraph to explain. And this helps because we also put up an explanation right on the account upgrade page. More importantly, we're not wrestling with unmanageable amounts of code or fretting about a third party vendor meeting business needs - more time to spend improving the product in more important ways.