Interesting article here on per-user pricing for SaaS products and what the alternatives are, specifically indexing into the number of employees in your customer’s organization or somehow tie into financial metrics, such as transaction volume.
A good question to ask and definitely worth a look, although in most cases you’ll end up staying with per-user based pricing.
Per employee only makes sense if your solution is designed to touch every single one of them (n which case it becomes almost identical to per-user).
Transaction-based is only achievable if your solution somehow directly touches the financials of the transaction itself, e.g. some kind of payment processor, and directly contributes to a measurable margin increase for that transaction.
So in most cases, especially for departmental/LoB solutions you’ll end up sticking with per-user. But don’t forget to model:
- Do we price diverse user personae differently? Might be needed if value derived is very diverse.
- Do we need to package users into bands so that annual contracts can be budgeted with no need for incremental top-ups?
- Do we account for users outside the customer’s organization (customers, partners, suppliers) that either get indirect value or that have to be pulled in in order to realize the primary value proposition?
olivergajek 