You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At Tampere Hacklab, paying for tilankäyttöoikeus (space access) is done monthly, but we don't want people to treat it like a Netflix subscription where they only pay it when they use the lab, because this would not be financially sustainable. This is an eternal point of confusion to some members. I have thought of a change to Mulysa that could help with this issue.
Change
Add a new setting to subscriptions that allows members to disable and re-enable the subscription themselves, but with a cooldown. The cooldown would start ticking down from the re-enablement of the service. While the service is disabled, the user's paid days towards it should not decrease.
In practice we could use this for the Tilankäyttöoikeus subscription to allow members to take breaks from paying it, but not too frequently. Our administrative policy already is that taking long breaks (exact length undefined) is fine, but currently the board has to handle this manually. With this system, members won't have to contact the board themselves, and we don't have to define an exact length for the break -- they can be of any length so long as a year passes between them.
The cooldown period should of course be configurable per-service.
The text was updated successfully, but these errors were encountered:
Possible issue: users could abuse the system by coming back for exactly a month once per year.
While I doubt this would be exploited in reality, it would be nice if there was some way of detecting when this happens. Maybe count the number of times a service is paused, and have a table somewhere in the admin panel that allows sorting users by this number to find pause-happy users.
If I understand correctly: Is the intention that when a member cancels their space access, they can't enable it again until some time has passed? For example 90 days. They would essentially be forced to take a longer break. Knowing this, a member would have to think twice about cancelling their space access in case they might want to come back during the 90 days.
Or is it the inverse you seek, that when the user signs up for space access, they can't disable it until some time has passed? This would be like a phone plan with a minimum amount of months you have to keep paying for the plan. I think this is covered by mulysa's current subscription model, so I would assume this is not what you mean.
The first situation, yeah. At Tampere, we would like to discourage members from treating space access "like Netflix", i.e. subscribing for one month at a time only on the occasions that they need to use the workshop.
But we also can't (and don't want to) force members into fixed-term contracts like a phone plan.
Background
At Tampere Hacklab, paying for tilankäyttöoikeus (space access) is done monthly, but we don't want people to treat it like a Netflix subscription where they only pay it when they use the lab, because this would not be financially sustainable. This is an eternal point of confusion to some members. I have thought of a change to Mulysa that could help with this issue.
Change
Add a new setting to subscriptions that allows members to disable and re-enable the subscription themselves, but with a cooldown. The cooldown would start ticking down from the re-enablement of the service. While the service is disabled, the user's paid days towards it should not decrease.
In practice we could use this for the Tilankäyttöoikeus subscription to allow members to take breaks from paying it, but not too frequently. Our administrative policy already is that taking long breaks (exact length undefined) is fine, but currently the board has to handle this manually. With this system, members won't have to contact the board themselves, and we don't have to define an exact length for the break -- they can be of any length so long as a year passes between them.
The cooldown period should of course be configurable per-service.
The text was updated successfully, but these errors were encountered: