After hearing some pricing complaints about how adding a team member could jump their monthly price up $20-30 / m, I have decided that it might be better to move onto a base + per user $ billing model.
I have some questions with how to implement this though. I'm going to be using Stripe and I might even use Stripe billing, but what I questions with is:
Ideas?
Prorating seems like a good approach, but honestly, I think whatever you do will probably be fine as long as you're not ripping people off.
For example, my company does just about the simplest thing possible: Each month when it comes time to charge a customer, we just look at how many users they have right then. It doesn't matter how many they had during the previous month, or whether they've been adding and removing people. We just take their current number of users and multiply it by $10 (that's our only price point).
You might think customers would abuse this by removing a bunch of users before their billing period and then re-adding them right after. That literally never happens (and if it does, I can just email them and be like, "hey, stop doing that"). You might think people would complain about paying for a user that they were about to remove. That never really happens either, and if it does, we just refund them for any users they were about to remove. Basically, no one even thinks about this, and it's a non-issue.
I'm not saying you should copy this exact model necessarily. My point is that if you treat people fairly and keep things simple, you probably won't run into all the weird edge cases you can imagine. Probably the best option is to just do something easy to explain/implement, and move on to more important things. If problems arise in the future, worry about it then.
My model is charging customers for the minimum number of users that were active between billing periods. I'm sure I'm leaving money on the table, but I've also never had to respond to emails with a customer claiming to be overcharged.
Yes. With stripe, you can prorate the charge so they aren't paying for a full billing period.
If they remove a user, update the user count on Stripe. When they hire a new person, update the user count on Stripe.
Nothing stops them from doing this. I'd say it's a bigger hassle for them and they wouldn't be the ideal customers anyway. But proration takes care of that they pay for most of the usage when additions or removals are made.
Here's the documentation you should look at if you're going to use Stripe. https://stripe.com/docs/billing/subscriptions/quantities
Hey Phillip, good job with VisualBonus! I think you are taking the right approach for charging per user assuming every user sees different data when they login, if they do not definitely do not charge per user.
I would prorate them based on when they added the user during the current billing cycle if you can (Stripe lets you). If they fire, I would also prorate but only charging them for how long that user was on during that month. It is definitely complicated so if you want a more simple approach you could not prorate and only start charging them the next month, but you could lose out on a lot of money here depending on volume.
I've given this some thought for my own products, and I'm leaning towards a monthly charge for peak active users.
For instance, a company can onboard 100 people, but if only 10 people log in during a given month, that's what they pay for that month.
You'd want to keep an eye on shared logins though (checking for lots of different user agents, or sessions that overlap), and the only real way to handle a hire/fire situation would be for the customer to lodge a billing dispute, then you refund/credit on the next invoice.
That's still better than juggling active/inactive users manually. And since you're determining activity automatically, they can't just cheat and disable everyone the day before the billing cycle.