Hi guys, I read Ulrich's book as I have an enterprise focused collaboration solution (AI) being developed. I think it makes sense for us to price for usage, infra and some services. I have a good contract lawyer who can draft pretty much any legal agreement but a question lingers: how do you guys do it operationally? (what tech stack do you use from "quote to cash" to implement complex pricing structure? Any stack that would scale from startup to more mature state?). On a separate but related topic : what license server/engine would you recommend for an AWS BYOL approach? Thank you!

For those of you with experience using credit based price models, I'm curious what you're perspective is on how packaging fits into the broader monetization strategy. I ask because if you're using a credit based price model, you presumably have a lot of flexibility with monetizing the usage of various areas of your solution. In that world, limiting access to features through packaging doesn't seem like it really has a place. I'd much rather focus on giving my customers access to all the features they need and encouraging adoption/usage to drive up credit consumption. Am I thinking about this correctly? Thanks! Steve

You've designed and tested the new pricing, the client has given the green light, you have aligned on a roll-out plan, and the last step is communicating the change to customers. Our go to recommendation was sending out an email a month in advance to each customer affected (the February cohort would get this in January): 1. Clearly state in the email title that the pricing is going to change 2. Inform the client of the value you are providing (as framing of the value was likely to change during the pricing project) 3. Inform o the new price (and possibly new plan) and when it will change 4. If applicable, inform about a loyalty discount 5. Explain what is the reason of the change (adding more value to customers is an evergreen) How do you approach it? Is there something missing here? Do you think there is a need to send additional communication? Personally I think that there is no upside to a price-hike forewarning, as the only action we incentivize for the client is reviewing alternative solutions... But I might be completely wrong, so please share your experiences!

I'm writing a guest chapter on AI pricing for another authors upcoming book. So I'm thinking about this a lot lately, and wanted to give you a sneak-preview of a linkedin post that will come out later next week. - I've done maybe 10 pricing projects involving significant AI functionality this year. Here is how I think about it. AI should be considered a 2-layer stack: 1️⃣ The AI compute 'fuel' (i.e. token pricing at OpenAI) 2️⃣ The AI solution (i.e. the value you add on top of AI) The dilemma with AI pricing is that currently: ◾ Fuel is expensive - at least way more so than traditional SaaS. ◾ Solutions are immature and early stage, not yet adding a lot of value. So any AI pricing model needs to both work today AND tomorrow. AI PRICING TODAY: 🔹 Charges usage-based on fuel consumption to ensure costs are covered, as usage patterns of customers is often unpredictable. 🔹 Is mostly focused on low barriers to entry to get users onboarded in order to develop the solution layer and get data on behaviour and cost patterns. 👉 This is unsustainable as fuel costs will drop and 2025 customer will refuse to pay a price-per-token (or token equivalent) that is based on 2024 token costs. This is especially true for enterprise. AI PRICING TOMORROW: 🔹 Charges based on the outcome created by the solution layer and just factors in fuel costs in the use case. 🔹 Protects against cost-downside of over-usage with 'fair usage limits'. HOW I SOLVE FOR THE TODAY-TOMORROW PROBLEM IN AI PRICING 🔸 Focus on speed: just get usage and adoption as fast as possible. You likely have a core non-AI product that monetizes just fine. Consider AI a 'development budget' and focus on profitability later. 🔸 Tell customers you are BOTH charging for fuel and for a solution outcome. Educate them. But keep it 90% fuel and 10% solution early on. 🔸 Over time: shift $$ from fuel to solution pricing. Cut Fuel pricing aggressively, even anticipating future cost reductions. Consider solution pricing separately and from a value perspective.

Hi Everyone I wonder if you have experiences or opinions about the importance (or not) of having copyrights or patents (or alike) finding funding for a B2B SaaS startup. I understand it is "better", but is it a necessity? Or.... it depends. My case is scaling something that is working. The application enables pricing/selling more value based in traditional industries, extremely fast, tested/used in Field Service. Scaling means getting people on-board (further development, marketing/sales), and financing. If very valid, any sources where I can learn more about Intellectual Property? Should this be one of my top priorities? Is there any other alternatives? With a Smile, JJ