You need to understand the goal of your product, and what drives its adoption. You also need to understand the goals of your business at the given time. If you place any barrier in the way of a user realizing the benefits of your solution, you risk them not finding it valuable enough to continue using it. Initial adoption and success during the implementation period is critical.

Yves approach is beautiful. If you have the ability to meter and bill based on usage, and you tell your customers that would benefit that they can save money by switching, you’ll most likely gain the difference back in the long run. You’ll also have created a bonafide promoter of your company/product.

I think we need some shakeup in the pricing models for SaaS apps. I’ve not seen too many really creative pricing models lately.

So, as Yves

If you’re creating a project collaboration service like BaseCamp, you want *people* to collaborate. So restricting the number of users (by charging per-user) makes no sense – either people will be left out of the projects, or people will ‘cheat’ and merge user accounts together to stay under “the limit”, which means they don’t get the best out of the product. And people have thoughts like “if I left David out, we’d stay under 15 users and don’t have to pay another $100 – he’s not on many projects anyway…”. Charging per-project (as they do) means that BaseCamp can be at its full potential for a small team, and grow to cover different areas, with pricing going up as it becomes more valued.

CRM apps like Salesforce.com/Highrise are different. We have 12 salespeople, lets get 12 accounts. If you charged per-client or per-opportunity or per-contact, you’re encouraging people to leave contacts out of the CRM to avoid paying more: immediately making it less useful.

I would also add that, just as said by Coghead’s CEO here : http://blogs.zdnet.com/SAAS/?p=559, it will fit whit the needs of certain customers to have the comfort of a packaged pricing too if they want it.