I think bundling is a great and very useful feature! When adding a contact to a bundle, I would like the option to inherit the address info (or, more generically, any fields) from the bundle administrator. This is useful when the different bundled contacts live under the same roof (e.g., a couple or a family membership) so I don't have to re-enter all the address info for each contact.

Different members of a family may have a different Membership Level, each individually priced and very likely having different Renewal dates and intervals (there would annual membership for the parent versus a Semester membership for the children). A common discount should apply across all members based on number of members in the Bundle.

Current system does not allow for separately priced memberships within the Bundle.

One suggestion I'd seen elsewhere was using a Username vs. Email field to establish "unique" entries. In fact, child members might not even have an email address separate from their Parents', as per the request (https://forums.wildapricot.com/forums/308932/suggestions/8827555).

Sarah, thanks for so detailed comment.
Any information valuable for us and will help to adjust functionality.

The bundle membership itself is a big area, and working on small changes could solve problems one-by-one.
Some of your notes already correspond to other existing suggestions, smaller than this one. For example, about fields for bundle administrators only (https://forums.wildapricot.com/forums/308932/suggestions/8827555) or adding contacts to bundle (https://forums.wildapricot.com/forums/308932/suggestions/8826889).
I copied your comments to these requests. But we still appreciate your comments.

Another one note: "Only the bundle administrator would pay and all of the contacts associated with the bundle would be free. I am not seeing a way to do this." Probably you meant something different, but it's already in our product. Only bundle admin pay for application and renewal membership, not bundle members. See more details here - https://help.wildapricot.com/display/DOC/Bundle%20administrator%20guide

Katya, Astra crew
Membership management features @ Wild Apricot

It is interesting reading the comments because I believe one of the issues is that we all use the system somewhat differently. I am currently testing the system for my association and have been testing out the bundle example. We actually have two different overall types of members where I would want to adjust how the bundle option works.

Group 1 - Sponsors
These individuals are companies that become members as sponsors. Only the company pays and then there could be multiple contacts for that company. We also have multiple levels and have limits on each level. The functionality issues I am running into include:
-I want to sent a limit on the bundle but because it included all of the contacts that will not work for me. I would like it to only count the bundle administrators.
-Only the bundle administrator would pay and all of the contacts associated with the bundle would be free. I am not seeing a way to do this. One thing to consider is being able to add contacts to a bundle. When you do add a contact to a bundle it turns them into a member.

We would also like to see an option where certain fields are only available for the bundle administrator. If the bundle administrator is changed those field values would carry over the new administrator. For an example we have a company description, logo and industry. We would prefer to not have each contact see those fields in their profile.

Our second group is our members and they are individual memberships so we will probably not use the bundle option. Some members work at the same company so we were hoping to figure out a way for the where someone could login and renew memberships for all of the individuals or register them for an event. This could be done with the bundle feature but I can't have multiple cost levels within the bundles.

Hope that information helps to see other ways to adjust the functionality.

Values entered into selected bundle admin fields should automatically populate the corresponding fields in bundle member records. This should be turned on and off on a field by field basis.
Other than that the bundle concept is working well for us.

We do listen, just not working on this yet. No nearest plans too, but this is important for us.

We have searched and searched for a membership system that works with corporate membership and whilst WA is one of the best systems we have reviewed, the lack of being able to handle a corporate structure is a serious downside.

I run an association that has international members and small regional offices. There are contacts in both the head office and and the regional office. It is very difficult to be able to administer the membership and the distribution of benefits in the current module and, one day, we will move away from WA to a platform that can handle this.

This thread seems to have been open for a long time and as a new user of WA I hope that the management are listening to the user feedback to develop the enhancements the users want.

I wish Wild Apricot would escalate this feature in their development pipeline. As a Wild Apricot partner, I always have to highlight these limitations for prospects considering moving to the platform; I think they need to be aware of these limitations and make the decision to accept them and workaround them OR move to another system that would better support their membership structure (not what I like to see).
For Wild Apricot clients with corporate membership implemented with a bundle; they're having to create inconvenient workarounds to deal with the limitations outlined here.
I would like to see a different membership level for organizations (bundle) vs. organization members (individual). This would allow having different membership fields and privacy setting (plus application and renewal) for the parent record (organization) vs its members.

This is the primary feature stopping us from using WA. I have a completely different approach to these bundles that makes them a bit more generic.
(1) bundle administrator is just that, an administrator. They aren't a normal member but a special member type. They may not even be paid themselves, but they manage the membership of the bundle (imagine an administrator for a company who is not him/herself a member)
(2) the individual members have their own membership accounts, which they could manage themselves, paying dues, registering for events, etc... They might be a special membership type that acts like a nor.al member type, but with the added feature of belonging to a bundle.
(3) the third type of "member" is not a member at all but just a category of that indicates association between members. It shouldn't have special fields that normal members don't have, but it could store values that can be prefilled for all members (eg. Company name, address, etc...). Any new member can create a new membership group, to which they can assign one or multiple administrator(s). Those administrator have the ability to create other administrators for this membership group category. The administrator for a group has the ability to pay for any any member of the group, or register any member for an event, etc...
When a new member signs up, they can select to be part of an existing bundle group (they must know the name, and an administrator must approve their membership to their group) or they can create a new one, or not have a bundle group at all.
Any existing member had the ability to change their association from one group to another (imagine an EE switching companies), notifying the administrators of the group that is being left and requesting approval of the group it's going to.
I look forward to seeing an amazing implementation of bundles as you have done with other features!

Adding account module that contacts from same organization can be associated with.
Enhancing the contact management module and adding new common lookup field to relates to other fields in the database

I agree with the option for bundles to add additional members for an additional charge. Our memberships are for kids and we would need to create multiple bundles in order to make it work for the parents. this also causes the issue for a family not being able to use multiple memberships for different levels if they wanted to.

We would like to be able to add additional members to the bundle membership at an additional charge for the members. If they pay $500 for a bundle membership for 20 people, they could add additional members for $20 per person over the 20 included.

Our members are paid subscribers to our e-newsletters. We offer company subscriptions and bundle the company's members together, and designate a "bundle administrator" who receives the invoice for the company subscription. But we have a BIG problem managing these subscriptions and tracking payment history when companies change bundle administrators, since invoice records in W.A. are NOT attached to the company name, but to an individual bundle admin. (And if we delete the old bundle admin, we lose the record of past payments on the account.) Right now we are archived old bundle admins and marking them with an "X-INV" before their name, so their name is grayed out but past paid invoices stay in the system. But this is far from a satisfactory solution. We would really be so pleased if W.A. would have an option for a "group" or company membership where invoices would "stick" with the company name, not with the individual receiving them. Thanks!

I fully agree. When using bundles for a family or parent organization type situation, collecting the same details for each member if redundant and very time consuming for the members to provide. It would be very simple feature to add by simply having a checkbox on the membership field edit options called “Include in bundle members” for fields that are used in bundle memberships. Then just restrict those fields display on the bundle member screens.

One thing that has not been done well by any online membership CRM, is corporate memberships.

I would like to charge a company one fee, for all of the staff in the organisation to become members of my organisation. This means multiple members get online access etc, but in a tree like structure it is managed from one invoice.

this is a very popular way to sell bulk membership, at a discounted price and is very good for firms looking to expand their database for selling other products.

Have the option to automatically copy administrators company information to added bundled members

Our members are children, so we would definitely benefit from having parent-level info entered for the bundle admin vs. bundle member. This would solve a lot of problems for us, including having to use distinct emails for each child in a single family.

We are a club with "family" memberships, which include the primary member, spouse/significant other, and children under the age of 22.

We need to be able to add the spouse & children as "bundle members" but with a reduced information form, and different required/optional specs.

When registering for an event, the primary member should register, and be presented with something like check boxes for the other bundle members, so that they can be charged the "member price". Also, the primary member should be able to register other members with registering himself.

In the Directory, we would like the ability to group the bundle members together under the primary member.

Yes, I made this separate suggestion some time ago: http://forums.wildapricot.com/forums/308932-wishlist/suggestions/8827576-change-the-name-bundles-to-corporate-or-organ :)

But so far only 2 votes. :(

Ideally this would be part of a wider macro facility. And in fact if "Bundle" became user-configurable it would be good to have macros for {Bundle name} and {Bundle membership name}.

But I would be happy with a quick and simple implementation. :)

Walt, yes for sure we can in general - but it would require planning into development roadmap which is completed for this year, unfortunately. I think that your comment deserves a separate suggestion, as it's much easier to implement than redesigning all bundles.