Last month (on 28 May 2021) Orderla just launch Orderla Pro. The next plan after Plus.
This is after 1 year 2 months after the initial Orderla launch to the public. And about 1 year after Orderla Plus on the market.
So it was taking quite a while to bring Orderla Pro to the market.
At first I assume can deliver Orderla Pro after 5-8 months after Plus launched. But actually building multi-plans was harder than I was expected.
Multi-Plan in Mind & Code
Before we could do the Pro. We have to make sure our code is Pro friendly.
We have to make sure our code is future proof to support multi-plan right from the middle.
Not from the start, because it was written with just Plus in mind. So there was the transition time where we just make the adjustment to think Pro in mind when we write our code.
Why we need to have Pro? Of course we want a better reward when offering more incredible features.
We had tried our best to just put many cool features to just Plus. But sometime to add another feature, requires additional charges from the third party provider, in this case is Google.
So it's not feasible, and financially advantage to put this kind of feature at lower cost. If it would be used by many people, it eventually will put our financial to red, because it may cost us more.
Strip-ing Pro & Multiple Terms
We are using Stripe to manage our SaaS business. Just the right time Stripe came when we launched our Orderla Plus last year.
Now we wanted to evolve the business by offering the next tier- Pro plan.
Of course Stripe knew this kind of model business. We just need to learn what Stripe API can offer and can be used.
There is something cool for monthly subscription, when you already subscribing on Plus, you can upgrade to Pro seamlessly. Stripe will take care of how to charge accordingly with pro-rate.
Pro-rate means when we are in the middle of Plus, when we want to jump to Pro, the Plus days remaining will be converted to days of Pro. The pricing by adding the difference of day Pro and day Plus.
All of this is handled by Stripe.
However for yearly basis, we have to do the calculation by ourselves. If you already purchase Yearly, then you want to upgrade for Pro. We have to calculate the pro-rate price to upgrade then charge it via Stripe.
So this one is just need some extra coding to get it right.
Jumps meaning let subscriber to change their plan, but in this case just can upgrade their plan.
To downgrade, however, to simplify managing the feature-and-plan, we just only can let customer to cancel with remarks and resubscribe with lower plan.
Track those Journeys
Since they will be multi-jumps between plan and term (monthly / yearly), we have to track them properly.
This is quite crucial to make sure we can manage the features towards the customer's current plan. And we just need how the movement of plan for a particular user.
On top of that, we can use for tracking our affiliate. We can know the customer from which affiliate and how much money they already spent. We can track which commission has been paid or not.
Bonus: Upgrade Yearly for the Next Year
Orderla Plus for yearly also almost a year for us to get our first customer.
So we also have to remind the customers that their yearly plan will be ended within 60 days. And of course we have to provide with proper CTA.
We have to let them to upgrade for their next year.
This option is new feature to be implemented. It's not like at the first subscription where it starts immediately. This one is a purchase to be started right after customer's yearly subscription ends.
Plus, we also let customer to purchase yearly for Pro.
Last words, the journey was not short, and we just take enough ( or more than enough ) to plan and develop Pro plan. yet we still found some minor issue when executing Pro plan in term of managing subscription. For example on webhook. We wanted to get info about user's subscription plan when receiving webhook. However the plans return is in array. So at first we just simply use the first item. Because in all our test, it's only has one item.
But when do for case that customer is using Pro-rate, the plans position in array is different.
After analyze and understand the data structure then I upgraded the code.
So we are just keep monitoring that our system is capable to handle things like this in the future without any problem.
So thats it for now. Happy Ordering.