Monetization and upgrading/downgrading plans

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.

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

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

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

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.

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

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.

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.

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

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

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

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

We will announce any changes on this, of course 😁

Cheers,
Matias

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

Hello @anon29275264 and thank you for the feedback!

It was shared with the team 😁

Cheers,
Matias

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

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

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