There’s a massive difference between “AI tools”, and “Using AI tools in your service”.
MidJourney (if it does, never used it), OpenAI API, and Google Colab can charge based on computation because that’s a massive slice of their cost.
ChatGPT is a monthly service because it is an aggregation of services, for example.
Most services are an aggregation of services.
Transparency and simplicity usually don’t mingle very well together.
The moment your service requires multiple other services, is when transparency becomes complexity. So, if your simple service simply returns data, and that’s it. Sure.
If you have a database for the user to retain their data and other reasons, for example. Yeah, no.
If ChatGPT is a example for aggregate services it’s also a example that one could offer a flat fee for a set of services with a maximum number of requests per month.
But in marketing we can use menu pricing to differentiate customers based on their willingness to pay to extract higher margins.
We can be completely transparent about this and offer a simple package to the user. If you have more services in the mix, up the price for those who need them.
Agreed, which they do with their limits of messages per hour.
100%. Almost always we see this with “Small/Pro/Enterprise” tiers, the magical number of 3.
Even restaurants follow this magical number (low-quality prices low, meh-food expensive, and then the real profit/preferred selection in the middle )
Well… maybe not completely transparent. Too much information can be overwhelming. But I think it’s always nice to have some sort of metrics that scale to the price.
That would be an overcomplication if your service charges a flat $10 a month and 75% of your customers are going to stay in your budgeted cost range. But, if 75% of your customers are likely to exceed that budget, then it becomes a bit more untenable.
So, in the model I’m thinking, you charge a flat fee + credits to cover usage, but instead of you pre-determining what that usage will be, it is now on the customer to make that decision. “Shall I add $5 credit, $10 credit, etc…”
So, the only question remaining is: Do you rollover the remaining credits at the end of the month or not?
So, in initial tests with a potential client, he said flat out, “I don’t know what tokens are, and I don’t want to hear about them. Just tell me how much it’s going to cost.” So, the thin line I find myself on is the fact that the “metrics that scale” the pricing ARE tokens.
Good point. But I think this would just be an error with the monthly cost.
Ideally your monthly cost would reflect how much a typical user would use your service per month. So if you charge $10 / month but 75% of users are exceeding this limit you have priced it incorrectly. This could be broken down into a 2-tiered pricing system (with an soft-cap alert if the user is about to hit the cap and if they want to upgrade maybe?)
Definitely not. As mentioned you don’t want to be holding people’s money for them. This just opens a huge can of worms. Google Colab is a monthly service but offers 90-day retention of credits though which is nice.
This is another reason why credits can be a bad idea. It makes people feel obligated to spend them and not be wasteful.
Exactly! Most people (especially high-level business people) want these plans to make their life easier, and less complicated!
I feel like some fundamentals of hosting a marketable web page can transfer over to pricing. If it takes more than 3 seconds to load (into the persons head) they are already moving onto a competitor!
I truly do not give a shit about saving pennies. I truly DO NOT want to have to fumble over “how many credits I have right now”. I want a service, I want it to be stupid simple, and I don’t want to do anything more than I have to. But, of course, if the service is a large component to my business potentially costing thousands then I would obviously appreciate a granular price scheme.
The metric that scales is tokens for you. The metric that should scale for them should be something much simpler such as “requests”. If your service is. Let’s say a poem-generator it is much easier just to price a single request as the max tokens (or max tokens, and then storage space), and then charge based on that.
Good point. And that’s what I’ve been sort of circling back to, using “Searches” and “Queries” as the metric based upon my calculation of how many tokens on average each Search/Query takes.
Yes as Ronald says, no user is going to care about tokens unless you are offering services to a developer already using OpenAI API. Imagine explaining to a general user what tokens are, how prompt/completion is batched into per 1000 tokens, how prompt/completion differ in cost, how that is related to your product, etc. Total nightmare. You need to setup pricing in a way that the user cares about, that is the big challenge, the marriage of “front facing” price to “backend” cost, and how to communicate the front facing part of that to users without requiring them to read a whole essay
I definitely wouldn’t mention “tokens” to end users. You’d just make them aware they pay only for what they consume, and that they can buy more credit if they run low. Always show remaining credit in USD, not tokens. In the subscription agreement you can say something like, “On average, $1 buys about N pages of text worth of conversational content”.
One crucial aspect that hasn’t been addressed yet is the need to compare your app with others in the market. When there are numerous apps offering similar features, it becomes essential to carefully consider your pricing strategy. Competition serves as a catalyst for transparency and comparability, especially when you’re vying for new customers.
For instance, if your app offers specialized knowledge compared to a basic app that simply duplicates features or content from a standard source, you can potentially justify higher prices until competition enters the scene.
How do you assess the competitive landscape? The market is undeniably expanding rapidly, but given the affordability of basic code, what are your plans for further app development and refining your pricing strategy moving forward?
The pay-as-you-go model some of us have been describing is the most competitive pricing strategy, because you can set monthly service fees as low as you want (the reason I used the $1/mo example), and not have to overcharge your customers for API consumption they never use.
And I recommend just using “Pages of Text” as the unit of measure. So when people prepay for a certain amount of service, they know up front some factor like how many pages of text one dollar buys, and they can prepay whatever amount they want accordingly.
Using a non token unit of measure is fine if your entire customer base is using a single language in a single way, if some of your customers are using symbolic languages such as Japanese or Chinese or your customers make use of scientific notation or programming syntax then the token estimations can be as much as a factor of 8 out, I would not recommend this as a standard to follow.
Thanks for sharing!
Personally I wouldn’t advise for low prices because this means the profit is dependent on volume which is likely capped when using OpenAI APIs.
It also implies that the added value is not high but admittedly this is more of a perceptual thing and may be different in each case.
On a positive note, low prices are a classical way to introduce customers to all the possibilities in the higher priced tiers.
Yes, the “Pages of Text” one is just for a specific type of thing. But whatever “thing” you are selling you would generate a similar “rolling up” of costs into a larger average price similar to “pages of text” and just say how many of those “things” one dollar buys.
It’s about being able to convey to the customer roughly what they are getting per dollar without mentioning tokens. You might have a big pricing page of how many X a dollar buys, how many Y a dollar buys, how many Z a dollar buys, etc.
When the difference, depending on the customers language, can be from 1 page to 8 pages of text and when trying to adjust costings down to a single dollar, I do not see this as viable, if it works for your particular use case, great, but I would not recommend it on a global userbase forum.
Exactly, I prefer high(er) prices for innovative services but that’s not the point here.
Well, zero and infinity, are not usual terms to be used when setting up a pricing strategy.
If each language needs it’s own pricing that’s perfectly consistent with everything I’ve said, and belongs on the “pricing page” I’ve already mentioned.
)