[makeitdouble]

This is an interesting idea but would need deeper adjustements on what the user is paying for.

For instance Netflix charges you for the next month you'll be using it. So at the time of charge, it has no idea if you'll use the service within the month or not, thus only the "cancel" part could happen. Moving to a post-usage payment can be done, but it becomes weird when the payment doesn't go through and quickly transforms into an open door for fraudulent activity.

Auto-canceling could be the best option, yet it would be an issue if the user actually expected to use the service the next month. They can still resubscribe again before using it again, but that's an extra step and also means the billing date gets reset, which might not desired by the user depending on how they manage their budget.

Basically, it's looks like a simple enough idea but the devil's in the details and it requires a decent amount of work to come out with something both the service and the user can easily understand and manage efficiently.

[yetanother12345]

Idea: You pay a fixed fee at the start of the month. This is your subscription.

With it comes a right to a certain amount of consumption. Every individual item of consumption will then have a set price.

If you use all, you've paid precisely. If you use more, you'll pay a little extra next month. If you use less, you'll get refunded next month.

This way payment follows consumption, it is transparent, and it can be implemented technically.

[makeitdouble]

Yes, it becomes an in service credit system, which is pretty clear to the user and most of us experencied that at some point.

It becomes messy when you have more credits than you could ever consume, as the service will be reluctant to emit refunds (making them harder to get also pushes the user to consume them instead...yes, dark patterns...), but I think it's a good system.

I personnaly think it works better when it's not auto renewed (so not a subscription), as it engages the user in the ownership of the credit and naturally reduces the refund part. Getting new credits can still be as simple as pressing a button, so friction can be reduced.

[ksdnjweusdnkl21]

>For instance Netflix charges you for the next month you'll be using it.

Yes, and if you didn't use it for the next month you could "freeze" the subscription for the user. Basically as if the user cancelled it on the last day. It should be easy for the user to continue it since the payment method is already setup and authorized. Send an email like "Hey, we noticed you haven't been using our service lately. We went ahead and cancelled your subscription. Welcome back anytime."

For what it's worth my perspective is for a service that is free to use, but subscribers get extra "free" stuff. Basically the purpose of subscription is to get loyal customers who do not use competitors.

[makeitdouble]

Wouldn't that work the same with an email a week before renewal day, saying "Hey, you haven't used the service most of this month, would you like to pause it before renewal kicks in ? We will let you reactivate it with a month free next time when you ask to resume."

That keeps the user in control of the situation, as a service you've been transparent, and you can still issue full refunds to users who come to you after a while explaining they actually wanted to cancel but forgot.

My basic POV in all of this is, the user enters the agreement on their terms, and it's weird to have the service acting cute and unilaterally suspend itself.

As a real world example, it would feel like leasing a car and have the dealer take it back during the night and stop the lease because you didn't drive last month. Sure you could just phone and they bring back the car, but why in the first place ?

[pintxo]

You could just re-pay the subscription fee for unused months?

Even if you’d keep the transactions fees, it would still be quite user friendly.

[BobaFloutist]

I mean we could give them a "free" month as on off ramp, pay exactly the same as we do today but if you don't use it for a full month it gets paused, and that would still be dramatically better for consumers than the status quo.

[makeitdouble]

You seem to be describing something like a credit system ?

It would be weird to get billed for December on a service because you used it a few times in November; that can be explained, but with enough time between the use and the billing it would easily look like a fraudulent charge to the user, and if they decide to cancel it at that time, they'll still be stuck for a full month.

That could make more sense if you're burning through "coins" and need to purchase new ones once you don't have any.

Come to think of it, mobile data billing system would also be close to that, except mobile ISPs can afford to require KYC documents up to a legal ID which drastically reduces the potential for fraud.

[BobaFloutist]

I'm taking about exactly our same system but it pauses (payment for) the service after a full month of no use.

[makeitdouble]

You can't put it as "everything is exactly the same, but I just change the fundamental mechanism"

[BobaFloutist]

Do you feel like you don't understand my intended mechanism? Because that language was solely intended to communicate what I was thinking. Which part was unclear?

[makeitdouble]

Yes, you're pushing an idea that has deeper ramification on how the billing works and how you explain it to the user.

It goes from a simple "the user pays every month" to "the user sometimes pays, sometimes doesn't, they have to guess by themselves when and why they 'll pay, it all depends on what happened in the past month". How you deal with the extra complexity from the user and from the contracting side is completely unclear. It might be surprising, but many users care a lot about understanding what and how they pay for.

Perhaps it's not important to your point and it's just an idea that doesn't need to ever see the light of day. But I feel we've been using subscriptions for long enough that improvement ideas could come with a clearer picture on how we deal with the change.