moderated Samuel's Paid User Proposal #suggestion
|
Hi All, Thank you all for the vigorous but respectful discussion on the planned pricing changes. I'd like to discuss Samuel's proposal for paid users, as outlined here: https://beta.groups.io/g/main/message/27515. I'm less interested in specific details, and more about the overall concept, which if I can summarize, is:
There are other aspects, but that's the general outline. One could also imagine that paying the yearly fee to Groups.io would unlock additional per-user features at some point (like the ability to star/save messages, or the ability to delay the sending of a message to a group for a few minutes in case you want to change it, for example). I think it's an interesting idea, although I am concerned about how to explain and present it clearly. I also think getting the implementation right would be tricky. Questions for the group:
Thanks,
|
|
|
|
Quite honestly, if this were to happen, I'd have to leave groups IO completely. All of my followers are low income and if they have to pay just to recieve email updates from me, they will leave. I'll have to leave too. I'm more than willing to pay for premium features, but I can't justify this idea at all.
|
|
|
|
Glenn Glazer
On 01/07/2021 14:16, Robert Kingett
wrote:
Quite honestly, if this were to happen, I'd have to leave groups IO completely. All of my followers are low income and if they have to pay just to recieve email updates from me, they will leave. I'll have to leave too. I'm more than willing to pay for premium features, but I can't justify this idea at all. What if existing groups were grandfathered? Best, Glenn --
PG&E Delenda Est
|
|
|
|
On Thu, Jan 7, 2021 at 2:16 PM Robert Kingett <kingettr@...> wrote:
Please read the original proposal and also understand, as previously stated, that existing groups would be considered legacy and not subject to per-member charges. Mark
|
|
|
|
I sort of liked Samuel's idea when I first saw it, but I see problems with it. All of the below pertain to when the group has reached 100:
-Is the group owner supposed, or is groups.io going, to maintain a wait list? -What about restricted groups with a questionnaire - are people requesting admission supposed to complete the questionnaire knowing they won't be admitted immediately, or perhaps not even knowing at first? -Is the 14-day pending member limit (before deletion) going to be removed? -In general, how and at what point, would or should requesting members be notified that the group is temporarily full? -How, and this is not a technical issue, but how are group owners supposed to figure out whom to remove (and how to inform them) if and when a "more desirable" person requests admission? -"Try before you buy" also sounds very tricky. How many people will be allowed in on that basis? How would it be kept track of (in case someone tries to repeatedly try), and other issues... And that's just off the top of my head. When I saw the proposal I liked it at first. But I'm not so sure it's reasonably workable. -- J Messages are the sole opinion of the author, especially the fishy ones.
|
|
|
|
p.s. Re the waitlist, some sort of waitlist would seem necessary to prevent people from having to apply over and over again or just give up.
-- J Messages are the sole opinion of the author, especially the fishy ones.
|
|
|
|
Hi Mark,
On Thu, Jan 7, 2021 at 10:11 PM, Mark Fletcher wrote: It's a complex arrangement and as well as you try to explain it, I think there will be lots of people that just don;t get it. One of Samuel's opening comments in his message was that your current proposal puts the onus on group owners to manage membership fees. I think with his proposed solution group owners will spend even more time trying to manage group subscriptions and determine whether members are active or not so they can potentially remove them and free up so called 'free slots' (and there have been recent topics either here or on GMF asking about tools to determine active users - no easy solution exists). If 'free slots' are not released by cleaning out redundant subscribers then pretty much anyone else joining Groups.io will end up paying and I'm sure that will increase the financial admin somewhat. There''s already a simple mechanism in place for taking payments per group so I'd say use that, charge a nominal fee for basic groups which will mean they're not being subsidised (as much) by Premium and Enterprise groups. it's simple, almost certainly less coding and certainly easy to explain. Regards Andy
|
|
|
|
txercoupemuseum.org
I think Samuel’s idea is flexible enough to explore as to practicality.
toggle quoted messageShow quoted text
Instead of focusing on the 100 person “limit”, how a 100 “active participant” limit instead. Most email-based groups have the great majority of their “subscribers” as functional “lurkers”. If a subscriber posted less than 3-5 times annually, that, to me, is an “inactive participant. Yes, these get all the “redistributed” emails from “active participants, but their presence does not substantially increase that traffic. It is common for software companies to offer a “free trial” period. On Groups.io, I suggest one appropriate for persons who want to set up a group. As for their subscribers, they would have a choice of “inactive participant” (who “settles for the give and take of others") or "active participant”, free to participate without limitation (for a fee)? These parameters may be “tricky” to sound out and properly define so as to be practical, but that’s a “one-time deal”…not an ongoing administrative burden (once defined and agreed). I think the concept has infinite potential in the context in which it has arisen. In particular, I wish to thank Mark for his open mind on this pivotal subject; all too many in his position have a terminal “not invented here” ego problem. No complex proposal is “reasonably workable” until properly investigated and fully defined. Best, WRB —
On Jan 7, 2021, at 5:02 PM, J_Catlady <j.olivia.catlady@gmail.com> wrote:
|
|
|
|
I like the concept of paid users conserving the number of free (or group-paid) slots for other users who can afford it. However, here are some other things that need to be thought about:
Easy: Any group requiring approval for new members needs an indicator that an incoming member is paid, so they know approval won't cost anything. More difficult: What happens if someone stops paying? There are multiple complications with this. You'd think for a free group, if there are enough free slots available, they can stay, otherwise remove them automatically. But what if the newly non-paying member is an owner? What if they're the group's only owner? Maybe that situation is rare enough that it'd be OK for groups.io support to clean up any resulting mess if the non-payment was accidental. For premium groups, there may need to be an option for this: Start paying for the user (if they're over the limit), or kick them out? I don't think there needs to be a free trial period as long as groups like beta and GMF exist and allow unlimited free members. If someone wants to join a group that will require a fee but isn't sure they like groups.io, they can be directed to one or more of these to get the hang of what groups are like. Alternatively, you could allow a one-time refund if a user is dissatisfied within 5 days. You may have someone wanting a "family plan" where several household members could be paid from one account, but that wouldn't have to be available right away. Once again, just because I come up with issues doesn't mean I don't think it's a good idea. :-) JohnF
|
|
|
|
Oh, one more thing: What happens if someone pays expecting to get into a particular group, then can't get in for whatever reason (not approved), and gets mad?
JohnF
|
|
|
|
Glenn Glazer
On 01/07/2021 15:53,
txercoupemuseum.org wrote:
I think Samuel’s idea is flexible enough to explore as to practicality. In programming, flexibility is the sibling of complexity, opposed to practicality (of implementation). Best, Glenn --
PG&E Delenda Est
|
|
|
|
txercoupemuseum.org
An inflexible idea is about as sellable as an inflexible proposal. Much of the structure of a house or other building is flexible and relatively weak until complete. That weakness is accepted because it is unavoidable and temporary.
toggle quoted messageShow quoted text
The natural progression is idea, concept, proposal, contract, construction. While flexibility in a completed program may, indeed, be complex, such is unlikely to be intentional unless important to the purpose intended (and thus economically justified). Best! WRB —
|
|
|
|
Hi Mark, Truth be told, I'm not a fan of that Jan-2021 group membership
cap plan, that's why I didn't participate in that topic then, I'm
more in the additional pricing tiers vs features camp (as far as generating income out of groups
themselves). Similarly as far as this idea is
concerned, I'm also not a fan of it, even if it does have merit
and I can see it work in some ecosystems/scenarios, I'm not
convinced Groups.io is one of them. There's quite the complexity
(cost) involved; here's another complicating scenario not already
mentioned as of me writing this: When someone gets unsubscribed
due to spam, if they are a free-slot member, the code must
maintain that slot available, for a while at least, because we
wouldn't want that member to click on the resubscribe link only to
be told, "sorry, you now have to pay". But then, how long do we
keep that slot reserved?? Glenn alluded to it, complexity
introduces costs in both the short and long runs, and we know
complex business rules, even if properly understood, designed, and
implemented, still always make for complex code to write and
especially maintain. I'm not crazy about these per-user group
pricing schemes because they invariably become a complex rules
migraine. I prefer simpler/less complex approaches if at all possible, and
maybe I should start a new topic, but IMO, since you want to also
tap the income-generating potential of the GIO membership itself
due to their large number, maybe trying to do that using the
groups as the "middleman" may not be the best way, I don't know; I
get this image in my mind of a large lot of firefighters trying to
enter through a single door to fight the fire inside, and none of
them uses their axe to break down that second padlocked door
nearby and allow twice the firefighters to enter simultaneously.
In the same vein, there is only some much that can be squeezed out
of groups as it is without resorting to complex schemes, if the
Jan-2021 plan (or this) doesn't work as hoped-for, what then? Why
keep using the group "entrance" exclusively as a way to generate
income when you could start another Groups.io account-based
pricing-tier vs feature concurrent "entrance" and offer it to the
members directly? You may want to explore pursuing your account-based
pay-for-bonus-features idea but offer it directly to the members and
leave groups out of it; you still are getting to your
end goal of generating income from the membership count itself, no
extra work for group owners, try-before-you-buy would be very easy
to implement on such a system and overall, implementing a
Groups.io account-based single or tiered pricing structure that
gives extra value/user experience in exchange for a yearly
account-based [$/donation/sponsorship/"VIP"/Enhanced
membership/subscription/callitwhatever] in the form of goodies
like you mentioned, should be simpler to design and implement than
the aforementioned per-user group schemes I'd think. If that extra value/experience you have in mind is stuff that
people really would love to be able to do/use in their everyday
Groups.io interaction, and/or it's something (user-experience
related) that has been requested a lot in the past but hasn't been
implement, this could be a good opportunity to roll these into a
user account-based "account+" feature upgrade pricing tier
structure. Some research on beta may reveal some suggested
user-experience features that if implemented could be offered to
the users using this feature; a quick example, and I may catch
flak for this, but the translation/foreign language
display/similar requests for example may fall under this plan and
are offered to users for a yearly $. Or similar
user-experience/convenience/value enhancing abilities to the ones
you mention. Maybe start at $2.50, then have $5, $7.5 and $10 tiers and
arrange & offer features accordingly. I suspect that if the
value of the features is such that they create a very enhanced
user experience in every day use/interaction, some percentage of
people would gladly pay even $10 a year for the convenience and
features, and because the Groups.io membership is pretty-large,
even if only a small percentage of users opt for this, it could
still generate some respectable numbers; a simple example, ~
1,300,000 users, if only 1% of them get just the cheapest $2.50
yearly feature upgrade, that comes to 32,500$ yearly; I have no
clue whatsoever of your costs and 32K is most likely a tiny amount
in the bucket, but change that 1% to 5% and it now becomes 162K
yearly income, a respectable contribution from just this plan,
hopefully it can be a larger % and income in actual use. Cheers,
|
|
|
|
On Fri, Jan 8, 2021 at 02:25 AM, JohnF wrote:
Oh, one more thing: What happens if someone pays expecting to get into a particular group, then can't get in for whatever reason (not approved), and gets mad?My immediately idea for a solution was: an e.g. 30-day (or 90-day) risk-free no-questions cancellation period. However, then I remembered that with Groups.io, new member applications are silently dropped after 14 days (unsuccessful applicants are not informed that they were not added to the list, nor are they told that the reason why they were not added was purely because of moderator tardiness or owner absenteeism). This means that a person who bought membership on the assumption that he'd be allowed in would not be notified on time that he needs to cancel his membership. It must be considered whether this suggested system would potentially increase the number of support requests, especially if those tickets are worth only $2.50 each. Samuel
|
|
|
|
On Fri, Jan 8, 2021 at 12:13 AM, Andy Wedge wrote:
One of Samuel's opening comments in his message was that your current proposal puts the onus on group owners to manage membership fees. I think with his proposed solution group owners will spend even more time trying to manage group subscriptions and determine whether members are active or not so they can potentially remove them and free up so called 'free slots' (and there have been recent topics either here or on GMF asking about tools to determine active users - no easy solution exists). It is unclear from Mark's original announcement (which I will call the "status quo") whether premium groups can set a cap on memberships (so as to prevent moderators from adding 500 new members even though the owner only has enough money to pay for 200 new members when the year-end invoice arrives), though I get the impression that there would be no cap, and group owners would have to actively, and carefully, manage the actual numbers, to protect themselves from unpleasant financial surprises.
With the status quo, there would be a lot of additional administration by group owners anyway. For free basic groups, once the magic number is reached, the owner would have to perform this same task: figure out which members to drop. For premium groups, under the status quo, IF owners are allowed to place a cap on membership numbers, the same thing applies: once the cap is reached, the group owner has to choose between paying extra himself or figuring out which members to remove. Or, if there is no cap, the group owner would still have to do this, but also keep track of how many members there are. (In both cases the owner can also post a request to his list for some members to donate (or, in my suggestion, to become paying members)). Samuel
|
|
|
|
On Fri, Jan 8, 2021 at 12:02 AM, J_Catlady wrote:
All of the below pertain to when the group has reached 100:(I assume they also pertain to when a premium group reaches its free-member cap.) -Is the group owner supposed, or is groups.io going, to maintain a wait list?I think the waiting list should simply be a useful way for the group owner to see and keep track who had tried to join and may still be willing to join, or who used to be joined as a paying member but then stopped paying. I don't think its a good idea for people to automatically move from the waiting list to subscription status (e.g. when a free slot opens up). The group owner should be notified when free slots have opened up (and have been open for, say, at least 7 days), but then it's up to the group owner to decide what he wants to do, and he would have to do it manually. For example, he could go to the waiting list page, select a member and then either add them directly, send them an invite, or send them a personal message first. Group owners who are even a little bit organised should be able to maintain a "waiting list" offline :-) But having a waiting list on Groups.io would certainly help group owners keep track of people who had wanted to join. (Also my original suggestion for the waiting list included the option that people on the waiting list would be allowed to view messages on the web, in case of a group with restricted archives). Samuel
|
|
|
|
I have not read Marks' proposal in detail but from what I have it seems
incredibly complicated. Although existing groups are grandfathered I can well imagine the case where an owner starts a new group which has to operate under the new system and gets totally tangled up with a mixture of groups with the different arrangements. Remember many of us are members of 20-30 groups and owner of perhaps up to 5, it will soon get unmanageable. I can see I will no longer be recommending GIO to others. Dave http://davesergeant.com
|
|
|
|
I have to agree with Dave. Way too complicated. I recommended groups.io to someone a few days ago. I unfortunately and reluctantly have to say that with things getting so complicated, I will have to rethink that. Or maybe tell people to rush and get their group in before the grandfather date.
-- J Messages are the sole opinion of the author, especially the fishy ones.
|
|
|
|
And by the way, if implemented, Samuel’s proposal (and in fact, any proposal in which members, rather than group owners, have to pay) woukd affect the entire system, not just groups created after the grandfather days. Members could or would be confronted with a tangled mish-mosh of different types of groups: grandfathered vs nog grandfathered.
toggle quoted messageShow quoted text
I think the worst feature of any proposal wherein members, rather than owners, pay is actually that. The new structure affects 100% of the membership, old as well as new. Essentially nothing and nobody is untouched. The grandfathering doesn’t really affect anything.
On Jan 8, 2021, at 3:04 AM, J_Catlady via groups.io <j.olivia.catlady@...> wrote:
--
J Messages are the sole opinion of the author, especially the fishy ones.
|
|
|
|
On Thu, Jan 7, 2021 at 04:11 PM, Mark Fletcher wrote:
I am concerned about how to explain and present it clearly. I also think getting the implementation right would be tricky.I may be going off on a tangent, but thought I should toss this in. How about offering an annual membership to anyone that wants it, regardless of which groups they may be in or join. Even different levels if it might someday be tied to additional features. (Or a minimum charge to make sure the Stripe fees are covered and there's some income, but allow additional payment, for those existing owners that want to support the site without upgrading their group to Premium.) Their account would store the expiration date, so that could be used when determining whether they would use a 'free slot' on any new group. On Premium/Enterprise groups, it would keep the owner cost from increasing with 'extra' members unless they exceed the 'free slots'. One thing I'm not clear on is whether this Paid User Proposal would be a per group fee or a per account fee. Thanks, Duane
|
|
|