Howdy pricing people! Huge thanks to everyone who joined our latest Office Hours, and a big thank you to @Ulrik Lehrskov-Schmidt of Willingness to Pay for answering 30+ of your questions on one of the messiest topics in pricing right now: what to charge for when the thing using your product might be a machine. The whole session basically resolved to one distinction — are you pricing the door, or the work that goes through it? Breaking down my 5 top takeaways below for those who couldn't make it: 1️⃣ Don't price the door. Price what gets carried through it. Your API, your own interface, and an MCP endpoint are all just doors into your product. The mistake Ulrik sees teams about to make is pricing the door — charging for the privilege of connecting, as if the connector were the product. It isn't. The value is whatever the customer carries out through it, and that's the thing you meter. The practical upshot: don't build a separate price list per channel, or you'll re-run this entire exercise the day you ship the next door. Pick one underlying value metric and let every channel — interface, API, MCP — debit the same thing. As Ulrik put it, meter the water, not the tap. 2️⃣ Decide whether you're selling an input or an outcome. This is the fork everything else hangs on. An input is a token, a call, raw access — you price it like a utility, thin and on volume, like electricity. An outcome is a job the customer actually wanted done — and you price that on its value. The cleanest example he gave: Intercom charging for a resolved support ticket rather than a message, at a fraction of what a human resolution costs. The customer knows exactly what they got and exactly what it was worth. Tokens are where you start, not where you finish — and if you contract your price to the compute bill, every future cost saving belongs to your customer instead of you. 3️⃣ Wrap it in a unit the buyer can actually budget. Nobody budgets tokens. Raw MCP calls are a dense, technical metric your buyer can't forecast and your salesperson can't explain, which turns every renewal into a physics lecture. Put credits (or whole workflows) between your raw usage and the invoice, keep the dollar-to-credit ratio simple enough to do in your head, and carry the per-call complexity in the terms where it belongs. And if you already run credits for in-platform AI — don't build a second economy for MCP. One wallet, one unit, debited wherever the work happens. If an agent costs more to serve for the same job, put that in the credit weight of the action, not a separate subscription the customer has to reason about.

According to Google, the majority of SaaS companies today selling contracts worth over $100K use a version of MEDDPICC as their sales method. I'd like to ask this community whether they use MEDDPICC at their company. If so, what influence does that have on your pricing?

Working with a customer to implement RevTurbine (revturbine.com). We are implementing a reverse trial which is triggered by the key onboarding action (connecting the user's trading account), and used as an incentive to complete it. The trial is on a separate hidden tier (subset of lowest paid plan features) which provides great flexibility: play with limits to control AI costs, segment however you like (e.g. higher limits for stronger prospects), etc - which is all in line with the customer promise: 21 day trial (no tier specified). And you have usage/feature based upsells to the paid tier during the trial (on top of the time limit as a conversion moment). This feels like it could be applicable to other folks, so thought would share. Happy to hear any comments/questions also.

80% of responses said they’ve added AI features and either haven’t changed pricing or customers haven’t cared. https://forstarters.substack.com/p/for-starters-83-the-monetization This suggests to me the NRR squeeze is less about absorbing variable token costs, and more about a misalignment between product and commercialization.