A member asks to stop getting paper renewal notices but still wants event emails. Another says “no fundraising calls, ever.” A third unsubscribes from your newsletter in your email tool, and three weeks later gets an annual appeal email exported straight from Altru. Each of those is a contact preference, and each one fails in a different way when it lives in someone’s memory instead of on the constituent record.
This guide covers where member preferences belong in Altru, how to keep them consistent, and how to make sure every mailing list you pull actually respects them.
Decide what you are tracking before you touch Altru
Preferences get messy when staff invent them on the fly. Before configuring anything, agree on a short list that answers two questions for each member: which channel (mail, email, phone, text) and which purpose (renewals, fundraising appeals, events and programs, general news).
A workable starting set for most membership programs:
- No mail of any kind
- No email of any kind
- No phone solicitation
- No fundraising appeals (any channel)
- Renewal notices by email only
- Do not exchange or share name
Keep it small. A list of twenty overlapping codes guarantees that two staff members will record the same request two different ways, and your queries will miss one of them.
Where preferences live on the constituent record
Altru constituent records support solicit codes and communication-related settings that are meant for exactly this. The specific code values are configurable, so your organization’s list may already include some of the items above, or may include old codes nobody uses anymore. Review the existing code table with whoever administers your Altru configuration, retire or merge duplicates, and add what is missing.
A few practical points:
- Use codes, not notes. A note that says “doesn’t want mail” is invisible to a query. A solicit code can be filtered on.
- Record the date. If your setup allows start and end dates on a preference, use them. “No appeals until after the capital campaign” is a real request, and an end date handles it without anyone remembering to remove it.
- Mind the email address itself. Some organizations also flag individual email addresses or phone numbers as do-not-contact. If you use both a constituent-level code and an address-level flag, decide which one wins and document it.
If you are not sure how a particular setting behaves in your Altru database (for example, whether a flag on one email address affects others on the same record), test it on a sample constituent in a sandbox or ask Blackbaud support before rolling it out.
Households and dual memberships
Membership adds a wrinkle that individual donors don’t: the household. A family membership may have two adults, each with their own record, and only one of them asked to stop receiving mail.
Decide in advance how household mailings work. If you mail renewal notices to the household, check whether your household mailing query honors a “no mail” code on either member, both members, or only the primary. There is no universally right answer, but there is a wrong one: leaving it undecided so the result depends on which record the query happens to pull.
Make every list respect preferences automatically
Recording a preference is half the job. The other half is making sure it is impossible to forget when building a list.
- Build exclusion into saved queries. Create a base membership mailing query that already excludes the relevant solicit codes, deceased constituents, and records with no valid address. Staff copy that query instead of starting from scratch.
- Name queries by purpose. “Renewal mail list, excludes no-mail” tells the next person what they are getting. “Members 2026 v3” does not.
- Use Altru’s marketing and communications tools where you can. If your appeals and renewal efforts run through Altru’s marketing features, review how solicit codes are applied there. Confirm with a small test segment that excluded records actually drop out.
- Spot-check before every send. Pick three constituents you know have a preference set and confirm they are not on the final list. It takes two minutes and catches broken filters.
Keep Altru and your email platform in agreement
The most common preference failure is an unsubscribe that happens outside Altru. Someone clicks “unsubscribe” in your email marketing tool, the tool stops sending to them, and Altru never hears about it. The next time someone exports a list from Altru for a different platform or a one-off send, that person is back on it.
Set a routine to close that gap:
- Export unsubscribes and bounces from your email tool on a regular schedule (weekly is reasonable for most organizations).
- Apply the matching code or email flag in Altru, ideally through an import rather than by hand.
- Treat Altru as the place where the decision is recorded, and the email platform as one place where it is enforced.
Also be aware of the difference between marketing and transactional messages. A member who opts out of newsletters still expects their ticket confirmation or membership receipt. Make sure your exclusions apply to promotional and fundraising lists, not to the confirmations people need to complete a purchase.
Train the people who hear the requests
Preference requests usually arrive at the front desk, on the phone, or in a reply to an email, not in the development office. Give frontline staff a single, simple instruction: which code to add, or who to forward the request to and how quickly it will be applied. A one-page reference with the approved codes and what each one means prevents most of the drift.
Quick answers
Should I delete an email address when someone unsubscribes?
Generally no. Deleting the address means you lose the record of their choice, and the address may come back in on the next purchase. Flag it instead so it stays excluded.
How often should we audit preferences?
Once or twice a year, run a query of all constituents with any solicit code and review it for obsolete codes, expired end dates, and conflicting entries on the same record.
