Tiered membership only works if the tiers actually differ. When your Family level gets free general admission but only your Patron level gets half-price tickets for a guest, Altru has to know the difference at the point of sale. Otherwise every member ends up with the best discount you offer, or staff override prices by hand and hope they picked correctly.
This guide covers how membership discounts generally behave in Altru, where the setup tends to fall short for level-specific benefits, and the workarounds organizations use to keep each tier’s perks attached to that tier.
Start by testing what your Altru discount does today
Altru lets you build discounts and connect them to membership, so that a member’s status can qualify a sale for reduced pricing. What matters for this question is how narrowly that qualification can be drawn. Depending on how your discounts and membership programs were configured, a “member discount” may apply to anyone with an active membership in a program rather than to specific levels within it.
We are not going to guess at the exact options in your version, because they vary with configuration and updates. Instead, confirm it directly:
- Pick two test constituents in a sandbox (or two staff records you can safely reverse) and give each an active membership at a different level.
- Ring up the same ticket order for each in daily sales and see which discounts become available or apply automatically.
- Repeat the test through your web forms, since online sales and desk sales do not always behave the same way.
- If both members receive the same discount and you can’t find a level-based restriction in the discount setup, ask Blackbaud support whether level-specific qualification is supported in your environment before building a workaround.
If the test shows each level getting only its own discount, you’re done. Document the setup so nobody “simplifies” it later. If not, one of the approaches below will usually get you close.
Workarounds that hold up in practice
1. Separate programs for tiers with different ticket benefits
When discounts can be restricted by membership program but not by level, some organizations split tiers into separate programs. A basic program covers the entry-level tiers, and a premium program covers the levels that carry extra ticket benefits. Each discount then points at the right program.
This is the cleanest option for automatic pricing, but it is not a small change. Renewals, upgrades between programs, reporting, and any queries or smart fields built on program membership all need a second look. Treat it as a project, test it in a sandbox, and plan the timing around your renewal cycle rather than switching mid-season.
2. Level-specific price types
Another approach skips discounts and uses dedicated price types instead, such as “Member Guest – Patron” priced at your Patron rate. Staff choose the price type after looking up the member and confirming their level.
This keeps your program structure intact and makes revenue reporting by tier straightforward. The weakness is that it depends on staff judgment. It works best with a short price list and a lookup step that shows the level clearly on screen.
3. Restricted manual discounts with a verification step
If you only have one or two tiers with special pricing, a manually applied discount limited to supervisors or trained staff may be enough. Pair it with a rule: the discount gets applied only after the membership level is confirmed on the constituent record, never on the guest’s word or an old card.
4. Separate handling for online sales
Web purchases are where level-specific benefits most often leak. If your online forms can’t tell levels apart, options include a members-only form or ticket offering for the higher tier, or keeping the premium discount desk-only until you have a reliable online setup. Whatever you choose, make sure your member communications say where each benefit can be used.
Check that the benefit is being used correctly
Whichever route you take, build a query of recent ticket sales with a member discount or member price type applied, and include the constituent’s current membership level. Sort by level and look for mismatches, such as a Family member receiving the Patron guest rate. Run it weekly for the first month after any change, then monthly.
Mismatches usually point to one of three things:
- Training gaps at the desk, especially with seasonal staff.
- A configuration leak, where a discount qualifies more broadly than you intended.
- Expired or downgraded members still being treated at their old level.
Before you change anything
Write down each level’s ticket benefits in one table: who gets free admission, how many guests, at what price, and whether it applies online, at the desk, or both. Most level-discount problems begin with a benefit that marketing promised and nobody configured. Once the table exists, you can compare every row against what Altru actually does in testing. That makes it obvious which tiers need a workaround and which already work.
Quick answers
Can one discount give different percentages to different levels?
Don’t count on it. The usual pattern is one discount per benefit, each restricted as narrowly as your setup allows. Confirm in a sandbox before promising tiered pricing to members.
Is splitting membership programs worth it just for ticket discounts?
Only if the pricing differences are significant and frequently used. For a single perk on one top tier, price types or a supervised manual discount are usually less disruptive.
