With Family Membership need to have multiple email

Our organisation allows for family membership with multiple family members having a login. At the moment all we have is added a custom field for a second email contact.

The first issue we have i that when people are renewing they may try their secondary email for renewal and so it actually starts a new member setup.

1. Do you have the concept of multiple email addresses in the standard product.
2. If not can how can we modiy the renewal process to ensure the email address is not a secondary email address but rather a primary member email address.
3. I see that other users have requested a family membership but cannot see any information on this. Do you have a family membership setup?
4. Is there an documentation manual for the whole membership Pro setup that I have not seen? Where can I download it?

Thanks,

George Egan

Dear George

I think your solution with family membership is not quite correct. I think a better solution is that we only allow one subscription record for family membership. Then users can then access to his profile page to add other members from his family (just need to enter username, password and email....) and these accounts will have same access with the main account.

Does this solution sound OK for you? If so, I think our team will go ahead to add support for family membership with this direction.

Tuan

I too need this feature and your implementation would work well, but we need to be able to restrict the amount of family members a family plan can have.
Has this feature been implemented?
Thanks.

I also need this functionality - preferably with the option to limit the amount of 'child' accounts. Will this be available soon?

I also need this feature for companies that buy a licence from us. When will it be implemented?

The Family membership isea is a great idea. I want to weign in on this before it is designed.

It should be called Family or Group Plan. This how it should work:

1) Setup a Plan called Group/Family Plan
2) Lets call the Group/Family Plan above: Tuan's Family Plan
The rest of members should called:
a) Child 1 >>> Tuan's First child
b) Child 2>>> Tuan's 2nd child
c) Child 3 >>> Tuan's 3rd child
d) ,,,,,,,,,,,,,,,,
z) Child n>>> Tuan's nth child and last.

So n = the Liniting number as small as 5 up to infinity (say 1K, 1M or 1b or 1Zillion)

---

The above should be used for companies with several departments or schools with several students.

Payment Structure:

A plan with 1 person (parent) and 99 children oe departments or students or licences can be priced at $100 (thets $10 per person).

At expiration, the entire plan dies unless there is a renewal according to the renewal rules.

But if a few members which to continue under the sme umbrella, the prize needs to adjust to accomodate the original finacial integrity of the original plan. That means if only one person stays, the remaining person will have to cough out $100 to keep the plan going. If only four people want to keep the plan going, then each will cough out $25.

Note in this scenario, no new person will be allowed into the system. Only the original members. New members will have to form a new Group or Family and pay the Family/Group price which is setup to be chaeper than individaul plans.

In my own setup, I called it Sponsorship Plan. I labeled them as follows:
1) Ruby Sponsorship >> $200 for 10 beneficiaries (individuals)
2)Emeral Sponsorship >>>$400 for 30 beneficiaries (individuals)
3) Quartz Sporsonship >>> $600 for 50 beneficiaries (individuals)
4) Diamond Sponsors >>> $1,000 for 100 beneficiaries (individuals)

How is payment done?
People can get together to raise the money for a given plan say Ruby for $200
$200 is paid by one person.
Then a Discount Coupon Code for 100% is issued to the head of the "Ruby Sponsorship Group" (say code = Tuan10) to Denote Tuan and his 0-member group. Each persons uses the coupon code to setup an individual account.
The limit is set at ten(10). After 10, the coupon expires.

I hope, I have shaded a light on multiple membership idea.

Looking forward to its implimitation.

I have this need also and am just coding it myself inside of Membership Pro. Here is how I am approaching it:

I have set up three different types of plans:
Individual Plans
Family Plans
Subfamily Plans

Individual and Family plans follow the normal Membership Pro workflow.

If someone picks one of the Subfamily plans, then they are asked for less info - only their username, password, email and username of the primary family member. The price for this plan is zero. A subscriber record is established as normal as is a user record but it is kept in a disabled state.

Then an email gets sent to the primary family member (after doing a lookup in users table based on their userid) asking for their approval to add this person to their plan. The approval email goes to our membership coordinator. When the membership coordinator gets the approval email, he/she will go into the subscriber record and make it active. The member who registered as a subfamily member gets an email saying their membership is approved and they can log in.


This keeps things fairly simple and didn't require a tremendous amount of customization. Since I use Community Builder, I'm also doing some custom work their too. For example when family membership is processed, I check to see if this is a renewal and if their are sub-family members registered under this same membership number. If so, I update the key fields for all subfamily members in the CB table as well.

I would like to see this implemented in the core Membership Pro system so I can pull my customizations out, otherwise I'll have to re-apply them when I need to upgrade Membership Pro.

Your appraoch is neat. But I have a problem with that style. Here is why.

If you have a program that many people want say in thousands. don't you see you'll need an army of worjers to be going back and fort to send e-mails for permission and then go an activate and send activation notice to the subfamily member.

With no aspersion cast; this is not automation. It is called manual intervention. That's why approach is better so that the component does the work.

You send one Family Coupon or one Coprate coupon to ome person. the at the time os sending it, you have programmed the total number to use it in the back end. the head sends coupons to those under him/her and they use it and sign in with their own email credentials. At the check out point they insert the coupon for a zero payment abd bingo thay are activated.

That's auhomation.

Thanks for your imput and for sharing your thoughts. together we can get a solution.

Your appraoch is neat. But I have a problem with that style. Here is why:

If you have a program that many people want say in thousands, don't you see you'll need an army of workers to be going back and fort to send e-mails for permission and then go and activate and send activation notice to the subfamily members.

With no aspersion cast; this is not automation. It is called manual intervention. That's why my approach is better so that the component does the work.

You send one Family Coupon or one Coprate coupon to ome person. At the time of sending it, you have programmed the total number to use it in the back end. The head sends coupons to those under him/her and they use it and sign in with their own email credentials. At the check out point they insert the coupon for a zero payment and bingo thay are activated.

That's auhomation.

Thanks for your imput and for sharing your thoughts. together we can get a solution.

I too am looking for that feature in a membership component. Some of the businesses I deal with have multiple users from different departments that need access. I would like it possible for the primary membership holder to be able to add/remove employees to the membership and they would be billed on a per user basis. It would be great if that invoice could be generated on a monthly basis and either have a fix cost per additional employee or a sliding scale ($100 for the first additional employee, $75 for the next, $50 for the next, etc.)

I this type of feature on the roadmap for your membership component? Is this something that you could be hired to do?

Thanks,

Francois