separate user from functionality. Price the extra capacity (integrations/api calls) separate. You are adding something to a package for which the user does not want to pay, users, while they need something else, capacity. Same as why there is no dessert in the menu at your favourite burger joint, apart for the kids menu.

@Ulrik Lehrskov-Schmidt A light went on in the last 20 seconds. Regular pricing increases make sense as it creates a muscle in the organization to get used to handling this. Makes complete sense, never realized 🙏

Hi Rob, good point. It is often hard to truly go after outcome pricing. After doing multiple repricing initiatives, I found that anchoring your price to the outcome often gets push back. If you look at all the things your customer brings into the mix to get to the outcome, let's say people, content/data, infrastructure, processes, training,... all those are easy to understand anchors for your pricing, as you can put a ROI against them and proof where you gain your clout. Anchoring your pricing on the outcome, is often felt as not correct by the customer as they themselves have worked (decided) on all those parameter, making it tough for them to accept you taking credit, thus anchoring your price against it. It is possible to do outcome based pricing. I have clients that successfully do so, they have heavily invested in sales enablement to help defend the proposals. Typical large ticket b2b sales. It is hard work, to get that extra ;)

Hi Rajesh, without knowing a lot about your solution, this springs to mind: You can do perfectly different pricing models for different businesses, as long as you can clearly draw a line (fence them). Let me give an example of a recent example of a HVAC asset management solution I did. 4 dimensions were considered: - Users (most obvious one - as everybody does this_) - features ( which expanded in a good/better/best (GBB) scenario) - installations - locations We went for 2 models Model A: locations and installations and GBB features Model B: locations and GBB features Users were not a valid metric, it would only favor the solution if the customer onboarded as much users as needed. How do we draw the line between model A and model B? Mainly on the business critical factor of the assets to the company. Business critical HVAC, means we go for model A. think datacenters - lof of HVAC - few locations, or supermarkets - business critical HVAC, critical HVAC and lot of locations thus model A. On the other hand we had retailers like shoe and clothing stores that need the solution, but the HVAC is not that business critical. Value is in somebody having all information in one place. Here we go for Model B. Only monetize on locations and GBB feature selection. On top some add-ons were defined that could be relevant for any type of customer, independent of their maturity. Think ESG reporting,... We made sure it was easy for sales to categorize the potential customer, so they can present an easy to understand proposal. I agree that having more price options potentially leads to more commercial debt, but more importantly never present your customer with your own internal complexity, too often pricing is unclear for customers, because we fail to make upfront decisions for them.

Awesome news @Ulrik Lehrskov-Schmidt. I'm very much looking forward to where @Rob Litterst and @John Kotowski will take this.