#nikolay_best-practices
open atlasBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1415608005717790780
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hoary dust
For context, this is the goal for the initial release. I've been thinkering around these options, but not sure which is the best way to do it:
Single stripe product per plan with multiple flat prices indicating the different employee tiers.
- a single product indicates a single plan in the system, easier to reason about
- not working well with the Stripe Billing Portal, for example if a customer wants to upgrade to a different pricing tier. for example from 1-50 employees to 401-500 employees, Stripe doesn't show that on the portal
Multiple stripe products (teams_1-50, teams_51-100, etc., enterprise)
- works with the Stripe Billing Portal
- multiple products indicating the same plan, needs abstraction in the application layer to connect the different products to the same plan (would need to set up custom attributes on the product with a plan_key so that then can be mapped to the same plan)
Single stripe product with tiered pricing
Seems to be meant for this type of pricing, but it adds a tier "501 - or more", which is something that I don't want to offer. Mainly want to push the customers to contact us for a custom offer if they have 500+.
So far, I've been leaning towards multiple products per "tier", so 6 products for the basic "Teams Plan" with pricing for yearly and montly alongside currency GBP and USD
river walrus
Even if you model this as tiered pricing you'll need to set quantity on the subscription item(s) to mirror the actual number of employees. Then we'd bill according to the tier and the set quantity
e.g. 1-50 employees = $100, quantity: 34 would bill for $100
Generally from what you're describing I think you'd model this as a single product, which varying prices. Overall the product in Stripe to mirror a product/service in your application
hoary dust
Your suggestion is something like this I assume? That would mean that we can't use the billing portal to allow customers to upgrade to a higher employee tier, due to this limitation - "Customers can’t define multiple Prices with the same product and recurring.interval values. For example, to offer a magazine for 4.00 USD per month standard price and 3.00 USD per month for students, create a separate student magazine Product version.", correct? The customer experience I'm trying to achieve is for the users to pick basically max count of employees, if they want more seats they'll need to manually upgrade to a higher tier pricing, e.g from 51-100 employees. to 101-200 employees for which we will charge a bit more. My understanding with the single product with a volume-based pricing model (the think you are suggesting I believe?) would mean that they will automatically be upgraded to a higher tier if they exceed quantity (employee count for a speicific tier).
river walrus
Then you'd need to model the 'enterprise' plan as a separate product yes
The customer experience I'm trying to achieve is for the users to pick basically max count of employees, if they want more seats they'll need to manually upgrade to a higher tier pricing, e.g from 51-100 employees. to 101-200 employees for which we will charge a bit more
There's no way to do that in the portal AFAIK as it'll require them to provide an actual quantity number, and then we'd bill the tier according to that
hoary dust
For the enterprise plan, would every custom offer to a company be a new price inside the Enterprise product, or a new product altogether with some custom attribute indicating that it is for enterprise?
river walrus
I guess that's up to you and your business requirements? If the only differentiator is that it's for 500+ employees the I don't understand why it needs to be overly complex