TOPIC:

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 This email address is being protected from spambots. You need JavaScript enabled to view it. 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
This email address is being protected from spambots. You need JavaScript enabled to view it. 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 This email address is being protected from spambots. You need JavaScript enabled to view it. 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 This email address is being protected from spambots. You need JavaScript enabled to view it..
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 This email address is being protected from spambots. You need JavaScript enabled to view it..
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.

 

Brian wrote:

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.

Personally, I think it is more appropriate to say that it will never have list server features such as are found in MailChimp or Constant Contact.  We do say that it is a list server in our Terms of Use because we do process email distribution lists, so we need to be very careful about making blanket statements that may be deemed to contradict what is in the Terms of Use document, which we are essentially distributing as "official policy". 

Most of the lists we process are fixed/defined by the system and established by selections users make in the Membership Management module.  The ability to define arbitrary lists (e.g. Custom Groups) is intentionally limited because that is not a big priority / focus for the system.  So, yeah, it will never be the likes of MailChimp or Constant Contact.  Also, once you get to about 400 or so contacts in the Membership Management module, it gets really slow to use--again, not really usable for setting up large numbers of contacts for club marketing.   I know because I have checked this with some of the club websites for clubs in China, Japan, etc.  some of those clubs are huge.
 
Everything in FreeToastHost is a balancing act... we give users a balance of some functionality and features, none of which is intended to be really advanced.

Thanks again for the helpful clarification to manage expectations given I've been using FreeToastHost to replace web content and customer relationship management systems (e.g., Wordpress, Salesforce) and complement them with social media platforms that are designed for event management (e.g, Eventbrite). 

Perhaps, advanced user is not the appropriate adjective.  It may be akin to empowering typical users with too many choices/options that aren't known and/or used instead of focusing and training on a few key processes that members (including officers) and leads (e.g., prospects, guests, former members) value for growing more leaders with results and impact using industry best practices.

I noticed all the design rules were explained in terms of technical specifications.  However, I wished that the design rules could be visualized with Toastmasters marketing processes and/or user workflows (e.g., venn diagrams, flowcharts) to clarify how FreeToastHost works for users to align easily using a graphical table of contents to click on and ask more applicable questions instead of guessing why and how it works.

If you have the time and money to produce those we will be glad to help you with the raw data definitions

Jenny, the only caution I would offer is that we would want to make sure it does not lead to someone copying our code or potentially leading to hackers having a better sense of how to get into areas of the system that they should not be in,