Got it, and it makes sense because even $30/month is a bargain, and I suspect it will not last long at that price if we want the models to perform reliably.
For now we’ve been focused on “monetizing” the expertise to create and maintain a GPT, which is owned and hosted by the client under their account. In other words, using a project model as opposed to a SaaS model.
Hopefully I won’t hear from OAI’s lawyers for doing this
Thank you everyone for all your comments, I really appreciate it. I certainly do not wish to do something that is in contradiction to OpenAI’s terms and conditions.
Perhaps for the moment I will focus the consultancy on education only of how to use ChatGPT, rather than promoting custom built GPT’s.
@sps and @anon22939549 could i then charge a fee to access the solution that I have built using the API? Or am I more looking at charging for my time to build and maintain the solution?
OpenAI should build an “ISV” program, where we develop our SaaS solutions using the GPTs infrastructure and publish them to our customers. The way it is organized is a mess, and I see the GPT’s potential, but the lack of a true north makes it very difficult to invest time to build those.
Without a granular control for distribution—there’s a need for roles and profiles where any basic enterprise system has—that could bring segregation of duties and also imply better visibility and management of a multi-customer solution.
The ideal would be for us—“ISVs”—to build a sleek solution using the GPTs and replicate it to as many customers as possible. We would then have a partnership program where we pay a membership fee plus what our applications consume as tokens. On the other hand, we would decide the value of that GPT to our customers.
Instead of this chaos of mainstream users, we’d have another tier - between the enterprise - but for a more closed and monitored situation, with controls in place to make this available to our customers who can benefit from our ideas but using the OpenAI’s AI as SaaS.
But we must have segregation of duties. In an organization, you can’t give someone access to functionalities to create a payment record, approve it, post it, and receive it.
Indeed, if you want to build enterprise-grade GPTs inside an organization, segregation of duties is a must.
I’ve been exploring all sorts of interactions with ERP systems, from Purchase Order approvals to Supply Chain activities like checking inventories and cycle counts. Without specific management, it will be tough to implement GPTs in organizations.
There are so many great use cases, but without a proper role-based model for the GPTs delivery, it’s a great tool without purpose.
The problem here is the magnitude of the difference between a pre-built UI that can handle multimodal inputs and output charts and images and building something from scratch. We should be able to take ownership of the GPT idea, sell it to a customer, pay the supplier (OpenAI), and make a profit. It’s a simple aspect of selling the value to our customers and fairly paying for the AI engine.
When you mentioned building a solution using API to sell the way we want, we have to consider all the other elements - from security standards (SOC2) to hosting, coding, and all the elements already available in the GPT’s UI, ready to be used. This foundation is already built. It is just a matter of organizing and monetizing.
It would be awesome to leverage GPTs as an ISV model and use them as a SaaS, where we could pack our ideas and spread them.
What’s available now?
I can create a neat GPT but can’t distribute it. I’ll have to share my IP with my customer so they can pay OpenAI directly - perhaps I can charge for the IP, but once the customer gets the first, they’ll replicate it on their own. If I could protect my IP by delivering the GPT to specific customers based on their particular roles, we could exponentially grow the services, and control who can use/see what.
Hello - I’ve created a custom GPT but I don’t understand how to charge users to use it, can you pls tell me how to? thanks for your help"Thanks for this information"
I’ll have to share my IP with my customer so they can pay OpenAI directly - perhaps I can charge for the IP, but once the customer gets the first, they’ll replicate it on their own. If I could protect my IP by delivering the GPT to specific customers based on their particular roles,
I’m not really sure to understand that part.
My cofounder and I made paid GPTs and the way we monetize them is by leveraging custom actions.
So we create one or many custom actions that provide value to the users.
Then we secure them with OAuth using kobble.io
So everytime a users will want to use the custom action :
they will have to sign-in to our user base
then we can distribute free quota for free users and extended quotas for paid members
Could you please point out why this kind of scenario does not work in your case?
I don’t think this is a tough question. It’s a matter of organizing and applying a partnership model. The software industry has had this method for years. I don’t see why is tough. The variable costs for tokens? What makes it different from any SaaS? The scale? Why this barrier?
Look to a single GPT as a SaaS product and the current models for partners and ISVs available. We could build, maintain, market, and distribute the GPTs. OpenAI would love this revenue stream.
Where is your list of users - paid and non-paid - and how do you charge them? I’m sure you’re charging your customers, right?
There are some questions to be answered:
Who has access to what?
Who can run a GPT that creates a payment?
Where are your controls - do you have audits?
What I mean is there’s no governance in your model. Perhaps this works for certain types of industries…
Where is your list of users - paid and non-paid - and how do you charge them?
When you use kobble.io your users are stored in your Kobble dashboard and authenticated using the Kobble OAuth flow.
Your customers are synced between your Kobble account and your Stripe account. You charge them with Stripe.
Who has access to what?
In Kobble you define paid and free products. You can assign quotas and limits to each product. When a user hits the limit, Kobble make the GPT redirect to the pricing page.
Who can run a GPT that creates a payment?
Anyone. Not sure to get this question.
Where are your controls - do you have audits?
Kobble is in process of getting a SOC2 cert. But this question could be asked for absolutely any startup or company out there so it’s not specific to GPTs.
I can create a GPT to show all the payments due to a supplier and then send the payment to the bank. This accounting operation happens hundreds (perhaps thousands) of times a day in enterprises.
Imagine creating a GPT that does that for the users, with a nice interaction and the ability to upload CSV files with the payments and submit them. This can be done in a GPT.
Now, creating a payment in accounting needs to be secured because of the risk of fraud.
Now, what controls and mechanisms do I have to ensure that I deliver the GPT to the right user inside an organization?
You’re securing at the endpoint level, and that can be a liability—a serious one.
You’re looking at the product level; I’m looking more at the functionality and multi-user level. That’s the difference. Well, I hope these GPTs mature enough so that OpenAI creates an environment where I can closely manage my users at a hierarchical level and bring the paid users to our control, and we pay OpenAI for their services. I think that will be the way to go anytime soon.
Since the user is authenticated using OAuth, the endpoint is secured at the user level. So it works on a GPT as it would for any other SaaS out there, wouldn’t it?
This is what we’re trying to figure out here. How OpenAI could open a partnership model so we could sell independently and being charged by the use of their services.