I would like to know your opinion about the upgrading/downgrading process of a plan under the monetization system.
As far as I know, when a user upgrades to a higher plan, monday applies a pro-rata price and the plan is immediately activated.
Similarly, when a user downgrades to a lower plan, the plan is immediately activated, but no refund is issued.
If this is the case, I think the process is not correct.
If no refund is issued, at least the lower plan should be activated at the subscription renewal.
As said, when a user upgrades to a higher plan, a pro-rata price is applied.
This is correct if your subscription model is based entirely on the time.
But that’s not correct with other models.
For example, in General Caster the small plan offers 5k ops/month (70 USD) and the medium plan offers 25k ops/month (140 USD).
If a user with the small plan consumes all the available ops on the first day and then upgrades to the medium plan, he receives a refund of about 68 USD for the unused period of the small plan and he basically pays 70 + 140 - 68 = 142 USD.
The user should pay for the small and the medium plan entirely (210 USD), without receiving any refund, as he basically consumed all the resources offered by the small plan, regardless of the time.
If your subscription model is based on the consume of some kind of resource (for example, operations/month as in General Caster), I think that the subscription should restart and no refund should be issued.
Spot on! This is exactly the dilemma we are facing at DocuGen where our pricing is based on consumption. Unfortunately this is preventing us from moving fully to monday.com Monetization.
I’ve discussed this with the folks in Monetization over a long call two months ago and they promised to look at it. Basically what we want is the ability to sell feature-based tiers (‘plans’) along with consumption quotas. Think of Zapier or Mailchimp – exactly the same. Alas, not possible in the Marketplace at the moment.
My understanding from what I’ve seen in the invoice data when an account upgrades
Original plan, unused duration is refunded. New plan is pro-rated until the renewal date of the original plan.
This results in three transactions total: one for the original plan, a refund for the remainder of the original plan, and a discounted new plan.
In this case, when upgrading, carry over the used ops from the original plan to the new plan rather than zeroing them out, but increase the quota. A customer could upgrade late in the period and get the new quota and not pay as much as they should. This assumes that the user will then use the remaining quota up before the renewal date. Entirely possible of course, but would require intent.
My understanding on down grades is that the platform is not supposed to activate the downgraded plan until the renewal date, and rebilling happens at the new plan rate. However, I do not have hard evidence this is how is actually behaving.
@Matias.Monday can you confirm this is the expected behavior? Customers who downgrade are immediately downgraded without any prorated refund of the higher plan? I would think if no refund then the effective date would be the end of the period of the higher plan. Seems like a bug to me.
In this case I would think a WorkAround™ would be this pseudocode
if (incomingPlanOps < currentPlanOps && isFuture(currentRenewalDate)) then doNothing
Basically, ignore monday until the old period expires?
All these gotchas are one reason I do very little with the monetization webhooks directly and instead evaluate what to do based on the subscription object. (Which for trial started and ended I have to replace with new objects that are correct because the webhooks can send bogus values)
Nice suggestion, @codyfrisch.
As we are moving entirely on the monetization system, this workaround, unfortunately, has a downside.
We also need to manage a subscription system on our side, while relying entirely on monday would let us eliminate the functionality on our servers.
True, but its not like you can get away from of having a database of installs, and keeping track of their subscriptions is likely a good idea still since there is no easy way to look it all up by API (short of API calls for every account).
Another question, if the customer downgrades from paid plan 100 to paid plan 50, are they charged for paid plan 50 at the time of downgrade or not until the original paid plan 100 term ends?
If the customer has paid, they should get what they’ve paid for until the next renewal date. (otherwise, from a customer perspective, their money was taken for a full month or year but they did not get the features for the full month or year).
I’m somewhat baffled as to the thinking of why it would downgrade immediately without refund. I am curious to hear the reasoning behind that choice. I’ve never seen a service downgrade immediately without crediting and almost universally services downgrade at expiration.
I bring this up, because if customers don’t understand the app developer is not setting this policy, it reflects on us.
As you can see in the timestamp and subscription.renewal_date fields, the period doesn’t restart.
The user downgraded from gc_plan_m (140 USD) to gc_plan_s (70 USD).
I agree he doesn’t pay anything for the downgrade, but the gc_plan_s is applied immediately and the period doesn’t reset.
I’m not 100% sure anything needs fixing as long as any credit for unused portion of a more expensive plan gets carried forward for the customer to use for future billing on the app. That was my primary concern
However, what I would like to see is a “details” object on app_subscription_changed webhooks that includes the details of how the billing adjustments were done - if they are purchasing quotas of usage, then getting the amounts prorated on each side of the change would let us set the new quotas accordingly.
That said, ideally the customer should have a choice if the plan change takes effect immediately or at the end of the current period. Trust me, having once worked corporate IT, the amount of grief you get from accounting… makes you want to become a programmer of one of these Esoteric programming language - Wikipedia