Retain Custom Group Info When Moved on Membership Management Module Tabs

When our VPM or VPPR moves prospects to the guests tab in the Membership Management module, they're warned that the individual will be removed from custom groups.  Would it help streamline the membership process by retaining custom groups/personas (e.g., Toastmaster, Parliamentarian, Unsubscriber) that the prospect belongs to when moved to the guest tab for updating as needed?  Then, we don't have to create redundant custom groups for targeting personalized mass-emails to Toastmasters, Registered Parliamentarians, etc.  

Alternatively, can someone explain the rationale for creating custom groups for prospects and guests that are different to justify this redundancy and adapt our process?  Many thanks in advance!

Virtual Parliamentarians (#7850496)

Design considerations:
1.  We only permit club officers to send emails to non-members.
2.  Custom groups correspond to email distribution lists of the same name. 

Therefore, custom groups have a lot of email considerations associated with them.  When I implemented the functionality way back when, I had to come up with simple ways to address all the considerations and potential scenarios.

Consequences:
1.  We do not support "mixed groups"  (members and non-members in same custom group).  Supporting that would only create confusion from non-officers trying to send email to those groups and then claiming we have "bugs" in our email because they did not get their email to non-member "Joe Smith" (or whoever).
2.  Keeping groups in place when moving from one list to another would become a "back door" way to create mixed groups.  Thus, explicitly not supported.
3.  To "keep it simple", we just do not support groups crossing over *any* of the membership lists.  (even though the distinction is really between member vs non-member)   Groups are really intended to be sub-sets of the established lists.

Bottom Line:  We have thought this through and beat it up quite a bit in the past.  While I may figure out some ways to improve it in the future while still keeping in mind the above considerations, It is very unlikely I am going to change it in the short term.
 

Thanks for the helpful context, which I agree with.  Some comments, workarounds, and/or suggestions to avoid mixed groups while still enabling custom sub-groups with special rights include:
1. Since members (except officers) can't access the admin console to view and email non-members, it seems that the admin can create officers as a custom sub-group of members with special privileges that extends across all groups.
2. If officers have special rights to email all groups and some guests attend events without ever becoming a prospect first, then a work-around seems for officers to make guests a custom sub-group of prospects where the targeted personas (e.g., Toastmaster, Parliamentarian) are additional custom groups within the prospects tab for personalizing mass-emails with a higher conversion rate.
3. Since former members lose the rights of members and can become members again, then officers can create a custom sub-group under prospects.

The above would seem consistent with the design rules without moving prospects to the guest tab, but also incorporate the membership process where a prospect evolves into a guest before becoming a member , and then a former member.  This is consistent with how Toastmasters teaches us to evaluate success metrics (e.g., prospect-to-guest, guest-to-member).  If this makes sense, then updating the supporting docs with this workaround may make more sense than creating redundant custom groups on the prospect and guest tabs for converting them eventually into members. 

You are looking at this only through the lens of how your particular club operates.  Time to expand your thinking. 

If I create a custom group of members called contest for club 123456, then any club member can send email to contest-123456@toastmastersclubs.org from their webmail / email agent (outside of the website).

If I create a custom group of guests called openhouse for club 123456, then any club officer can send email to
openhouse-123456@toastmastersclubs.org from their webmail / email agent (outside of the website).

If I create a custom group of guests called openhouse for club 123456, then if any member that is not a club officer attempts to send email to openhouse-123456@toastmastersclubs.org from their webmail / email agent (outside of the website), the email will be blocked. 

Also, because email addresses are case-insensitive, custom groups must be case-insensitive.  (Thanks to Pam for that subtle but important consideration way back when this was implemented.)

It is not just about sending email from inside the club website...  that is just how your club operates.  Again, you need to consider these things from beyond how just your club operates.
 

I appreciate the broadness of how FreeToastHost is designed, but it seems that most users I encounter use less than 5% of its features like Adobe Photoshop.  Thus, all these extra expanded ways of doing things that may not be used frequently and/or aligned with members' workflow and communication processes efficiently to avoid deterring most users, who seem to prefer simplicity, from using it and seeing its value unless they're a power user.

I rarely use generically addressed custom group mailing lists because of three reasons based on user behavior from marketing best practices:

1. Few people respond to emails without personalization using the variable for {{firstname}} that seems only an option for "send basic email" not when one emails custom-group-name@toastmastersclubs.org.
2. Few members use custom group emails and most don't want to guess which ones (e.g., members, officers, non-members) can send emails to whom or get frustrated with bounced emails beyond using members-club-number@toastmastersclubs.org.
3. Most members aren't detail-oriented and/or used to using case-sensitive email addresses and links.

Therefore, it seems the simplest solution for our officers (e.g., VPM, VPPR) is to create "guest" as a custom sub-group on the Prospects tab along with other personas (e.g., Toastmasters, Parliamentarians) as custom groups for personalizing mass-emails without the extra steps of moving them until they become members.  Thus, this workaround removes the need to recreate these same custom groups on the Prospects tab and what now becomes an obsolete or redundant and confusing Guests tab.

 

FTH is not nor never will be an email list server, if you need that function in your club please use a 3rd party mailer like MailChmp or Constant Contact.