Monetization and upgrading/downgrading plans

monday Apps & Developers
,
1

Hi everyone.
I would like to know your opinion about the upgrading/downgrading process of a plan under the monetization system.

First question
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.

Second question
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.

What do you think?

1 Like
2

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.

3

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.

2 Likes
4

I confirm that the downgraded_plan_id is passed to any requests as soon as the user downgrades.

1 Like
5

@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)

1 Like
8

Hello everyone,

What @anon29275264 said is correct. When an account downgrades, they are immediately downgraded without a refund.

Having said that, I have shared your feedback with the team. I think your use cases are very interesting and of course, all feedback is welcome and helps us improve, so thank you for sharing this.

Cheers,
Matias

1 Like
9

Nice suggestion, @anon29275264.
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.

1 Like
11

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).

12

Thank you.

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.

2 Likes
15

No, it doesn’t.
The period doesn’t reset.
Here’s a sample webhook we receive on downgrade.

(object) array(
  'type' => 'app_subscription_changed',
  'data' =>
 (object) array(
    'app_id' => 8031,
    'user_id' => 000,
    'user_email' => 'xxx@xxx.com',
    'user_name' => 'xxx xxxx',
    'user_cluster' => 'project_management',
    'account_tier' => 'enterprise',
    'account_max_users' => 15,
    'account_id' => 000,
    'account_name' => 'xxx',
    'account_slug' => 'xxx',
    'version_data' =>
   (object) array(
      'major' => 2,
      'minor' => 2,
      'patch' => 0,
      'type' => 'minor',
   ),
    'timestamp' => '2023-09-28T06:35:53.886+00:00',
    'subscription' =>
   (object) array(
      'plan_id' => 'gc_plan_s',
      'renewal_date' => '2023-10-07T00:00:00+00:00',
      'is_trial' => false,
      'billing_period' => 'monthly',
      'days_left' => 5,
      'pricing_version' => 1,
   ),
    'user_country' => 'DE',
 ),
)

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.

16

Hello again @rob

I deleted the other post just to avoid confusion since I had checked with the team prior to sending it but it seems like the information I got might not have been accurate.

I am sorry about that.

I asked our monetization team to check this again so that I can give you an accurate answer.

Again sorry for the confusion.

I will let you know as soon as I hear back from them.

Cheers,
Matias

1 Like
18

Hello again @rob,

I checked again with the team.

  • If there is a downgrade monthly->monthly or yearly->yearly, the renewal date does not change.
  • If there is a downgrade monthly->yearly or yearly->monthly, the renewal date changes to the date of the downgrade.

Sorry again about the miscommunication that lead to the inaccurate information of the other post.

Cheers,
Matias

19

Thanks for your feedback, @Matias.Monday.
Is there a planned fix to this behavior?

20

Hey @rob the flow is being reviewed but nothing final yet (or ETAs).

We will announce any changes on this, of course :grin:

Cheers,
Matias

21

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

2 Likes
22

Hello @anon29275264 and thank you for the feedback!

It was shared with the team :grin:

Cheers,
Matias

1 Like
24

+100 on this.
Balance carry over for the unused period and having the amounts shared in the webhook.

2 Likes
26

@Matias.Monday - Is there any update on the current behaviour of downgrades?

Ideally, I’d like downgrade to be applied from the next billing cycle, so that there is no need to refund anything, and customer also doesn’t feel that its unfair.

27

One year and a half has passed.
No changes or fixes in sight…