A family buys a dual or family membership on your website. The purchaser types in their own name, adds a spouse and maybe a grandparent, pays, and leaves. In Altru you now have a membership with several people on it. What you may not have is a household tying those people together. That gap shows up later: duplicate renewal mailings, two “Dear Member” letters to the same address, and giving reports that split one family into separate donors.
This article covers what to check in your own database, how to close the gap after online sales, and how to keep the cleanup small.
Membership members and household members are different things
It helps to separate two relationships that look alike on screen:
- Members on a membership are the people entitled to the benefits: who can show a card, who gets admitted. That relationship lives on the membership.
- Household members are constituents grouped under a household record for communications, recognition, and revenue rollups. That relationship lives on the constituent side.
A person can be on a membership without being in the purchaser’s household, and the reverse is also true. When staff sell a family membership at the desk, they often build the household by hand as part of the sale. Online, nobody is there to do that step, so whether a household appears depends on how Altru processes the web transaction for your configuration.
Find out what your setup actually does
Don’t rely on what someone remembers from a training session. Test it:
- In a sandbox or test environment if you have one (or with a clearly labeled test constituent in production, refunded afterward), buy a multi-person membership through your live web form.
- Use a new email address and a new last name for the purchaser, and add a second person with a different first name.
- Open the resulting constituent records. Check whether the second person was created as their own constituent, whether a household exists, and whether both people sit in it.
- Repeat with a purchaser who already exists in Altru. Matching to an existing record can behave differently from creating a new one.
If the results are unclear, or you expected a household and didn’t get one, ask Blackbaud support how web membership transactions handle additional members in your version. That answer is worth having in writing before you design a process around it.
Close the gap with a recurring query
Whatever the test shows, a standing query catches the cases that slip through. Build a membership query that returns:
- Memberships sold through the web in a recent date range (the last week works for most sites)
- With more than one member on the membership
- Where the additional member is not in a household, or is in a different household from the primary member
Exact field names vary, so expect to spend some time in the query designer finding the right membership member and household fields. Once it works, save it and give one person ownership of reviewing it on a set schedule.
Working the list
For each row, decide which of these applies:
- Same address, clearly family: create the household (or add the second person to the purchaser’s existing household) and set the primary member as head of household if that is your convention.
- Second person already exists in Altru: merge or link to the existing constituent first, then add them to the household. Creating a household around a duplicate just moves the problem.
- Not actually family: a friend, nanny, or caregiver on a membership that allows a named guest. Leave them out of the household. Membership benefits still work without it.
Reduce the cleanup at the source
A few changes make the weekly list shorter:
- Label the web form fields clearly. “Second adult in your household” gets more consistent data than “Additional member.” If your membership level allows non-family adults, say so, so people don’t feel forced to list a friend as a spouse.
- Ask for the same last name only when it is true. Don’t pre-fill the second person’s last name with the purchaser’s. Blended families and different surnames are common.
- Keep your duplicate checks current. Online buyers often already exist from a past ticket purchase or donation. Regular duplicate review keeps household building from creating a second copy of a person.
- Write the household rules down. Decide who counts as a household member, who is head of household, and how to handle adult children on a family membership. Desk staff and the person working the query should follow the same rules.
When it is worth the effort
If your membership levels are mostly individual, this may be a short monthly check. If family and dual levels make up much of your base, households drive real costs and goodwill: one renewal notice per home instead of two, combined giving history for major gift prospects, and accurate “member since” recognition. In that case a weekly review of the query is time well spent, and it is worth revisiting each time Blackbaud releases changes to web forms or memberships, since behavior you tested once can change.
Quick answers
Does a family membership need a household to work at the door?
Generally no. Admission and benefits follow the members on the membership. Households matter for communications, recognition, and reporting.
Should I create households automatically for every multi-person membership?
Only if your levels are strictly family-based. Levels that allow a named guest or caregiver will put unrelated people together, which causes its own mailing and reporting problems.
