Guest passes look simple on a membership brochure: “Family Plus includes four guest passes.” Then the questions start. Do they expire? Can a member hand one to a neighbor who visits alone? Does a pass cover a special exhibit or only general admission? Who used the last one, and when? Altru’s guest pass handling covers the basic idea, but many organizations find they want to record more about each pass than the built-in setup gives them.
This guide covers what you can usually adjust in Altru itself, where the gaps tend to be, and practical ways to capture the extra detail without fighting the system.
Start by listing what you actually need to track
“More fields” means different things to different teams. Before changing anything, write down the specific questions your staff can’t answer today. The common ones are:
- Expiration. Do passes end with the membership term, at the end of the calendar year, or a set number of days after issue?
- Eligibility. General admission only, or also programs, special exhibits, or events?
- Who used it. The guest’s name or email, so you can follow up or offer a membership later.
- Where and when it was redeemed. Which visit, which entrance, which staff member.
- Restrictions. Blackout dates, “must visit with the member,” or one pass per visit.
Some of these are policy decisions that need no system change at all. Others really are data problems. Sorting them now keeps you from building workarounds for things you could solve with a sign at the desk.
What Altru gives you to work with
Guest passes are set up as part of your membership program and its levels, so the number of passes a level includes is generally something you control there. Redemption happens through your sales process, typically at the point where staff ring up admission.
Beyond that, the options for adding custom details directly to a guest pass are limited, and they vary with how your program was configured. We’d rather be plain about it than guess: if you need to know whether a specific field or rule (an expiration rule, for example) can be set on guest passes in your version, test it in a sandbox or ask Blackbaud support before you promise anything to members. Don’t redesign your benefits around a setting you haven’t confirmed.
Workarounds that hold up
Put the extra detail on the membership or constituent record
Altru’s attributes are the usual place for information the standard screens don’t have. An attribute on the membership could hold something like “guest pass expiration” or “guest pass policy version.” An attribute or note on the constituent record can capture guest names when you collect them. Attributes are queryable, which matters more than anything else here, because whatever you can’t query you can’t report on.
Use a dedicated price type or discount for redemptions
If staff redeem guest passes by ringing up admission with a specific price type or discount, every redemption becomes a sales transaction you can find later. That gives you a date, a staff user, and a link back to the member’s visit. Name it clearly (“Member Guest Pass”) so it doesn’t blend into general comp tickets in your daily sales reports.
Capture the guest as a constituent when it’s worth it
For organizations that treat guest passes as a membership acquisition tool, it can be worth adding the guest as a constituent at redemption, even with just a name and email. That’s extra work at the desk, so decide whether you’ll actually follow up with these people. If no one will ever email them, skip it.
Build one query you trust
Combine membership level, guest passes included, redemptions (via your price type or discount), and any attributes you added. Run it monthly. It shows how many passes are actually used, which levels use them, and whether the benefit is driving visits or just sitting on paper. That number is what you need if you ever want to change the benefit.
Keep the desk process simple
Every field you add is something a frontline staff member has to fill in, often with a line of people waiting. A few habits help:
- Make only one or two details required at redemption. Everything else can be optional or filled in later by membership staff.
- Write the guest pass policy on one page and keep it at every register: what counts, what doesn’t, and the exact price type or discount to use.
- Print the policy in member communications too. Expiration and eligibility disputes almost always come from the member never being told.
- Review a sample of redemptions after the first month to see if staff are recording things consistently. Fix the training before you fix the data.
When the gap is too big
If your membership model depends on guest passes with complex rules (rolling expirations, transferable passes, per-guest tracking for marketing), the workarounds above will start to strain. At that point, document the specific fields and behaviors you need and raise them with your Blackbaud account contact. A short, concrete list (“expiration date per pass, guest name at redemption, report of unused passes by level”) gets a far more useful answer than “we need more guest pass options.”
Quick answers
Can I give different membership levels different numbers of guest passes?
Generally yes, since passes are tied to the membership level. Confirm the exact behavior in your own program setup.
Where should I store a guest’s name?
On a constituent record if you plan to contact them, or in an attribute or note on the member’s record if you only need it for reference. Pick one place and stick with it so queries stay reliable.
How do I know if guest passes are worth offering?
Track redemptions with a distinct price type or discount and compare them against passes issued. Low usage is a sign the benefit isn’t valued, or that members don’t know they have it.
