A second campus changes a lot of things in Altru: a new gate to sell at, a new price list, maybe a different membership promise. The decision that matters most for the long run is how you model admission. Get it right and reports split cleanly by location. Get it wrong and someone in finance spends every month-end pulling one campus’s attendance apart from the other’s by hand.
Below is how we’d think through the setup, with the trade-offs laid out plainly. It applies whether you run a main site plus a satellite, two separate gardens under one nonprofit, or a historic house network with several properties.
Start with three questions
Before building anything, get answers from leadership and finance, not just the ticketing team:
- Is a ticket good at one campus or all of them? If general admission is location-specific, each campus needs its own admission program. If one ticket covers every site, a single program may be enough, but you’ll lose easy per-site attendance counts.
- Does finance need revenue separated by campus? If each site has its own budget or its own GL accounts, that decision should drive your setup more than anything the front desk prefers.
- Do members get in everywhere? Membership benefits often cross campuses even when tickets don’t. Decide this up front, because it affects how admission benefits are attached to your membership levels.
The approach that usually holds up: one program per campus
For most organizations, the cleanest pattern is a separate admission program for each location, each with its own prices. Some reasons it tends to age well:
- Reporting is simple. Attendance and revenue by program become attendance and revenue by campus, with no filtering tricks.
- Prices can differ. A smaller site can charge less, close on different days, or skip a price type without affecting the main campus.
- GL mapping is direct. Each program can point at the revenue accounts that belong to that site.
- Staff pick the right thing. A cashier at the satellite only needs to see that campus’s program if your sales setup allows it.
The cost is a bit more maintenance: price changes have to be made in more than one place, and you’ll have more items to keep tidy on web forms and in daily sales.
Name things so nobody guesses
Pick a naming convention on day one and apply it everywhere: programs, price types where they’re campus-specific, events, queries, and reports. Leading with a short campus code works well, for example “DT – General Admission” and “NP – General Admission.” Sorted lists then group by site, and a query filtered on name starts with “NP” is easy for anyone to build later.
What about one program with campus-specific price types?
It’s tempting to keep one “General Admission” program and create price types like “Adult – North Campus.” We’d avoid it. Price types are usually shared across programs, so the list grows quickly, cashiers pick the wrong one, and every report has to be filtered by price type name to separate the sites. It works for a season and then becomes a cleanup project.
Combined or reciprocal tickets
If you sell a pass good at both campuses, you have a few options, and the right one depends on what your version of Altru supports in your environment:
- Sell it as its own program at a single price, and accept that attendance at the second site is counted separately (or not at all).
- Sell two items together in one transaction and split the price between them, so revenue lands on each campus.
- Check whether Altru’s bundling or combination options fit your case. Behavior here varies by setup, so build it in a test environment and run a sale and a refund before going live. If you’re unsure what’s available to you, Blackbaud support can confirm.
Whatever you pick, agree with finance on how a combined ticket’s revenue should split before the first sale, not after.
Memberships across campuses
If membership covers every site, make sure the admission benefit on each level applies to each campus’s program. Test a member check-in at each location before opening day. If only some levels include the second campus, spell that out in the level names or descriptions so desk staff aren’t deciding at the counter.
Also consider how you’ll report on member visits by site. If each campus has its own program, member admissions show up by location naturally. If they share a program, you’ll have no reliable way to tell later where a member actually visited.
Other details worth settling early
- Capacity and schedules. Timed entry, hours, and closures are almost always campus-specific. Keep them on separate programs or events so a closure at one site doesn’t block sales at the other.
- Sales locations and drawers. Give each campus its own registers or sales locations so daily reconciliation and batches can be balanced per site.
- Web forms. Decide whether online buyers pick a campus first or see one combined page. Separate pages are clearer; a combined page needs very obvious labeling.
- Constituent records. Visitors aren’t campus-specific, so don’t create duplicate records per site. If you want to know a household’s “home” campus, track it with an attribute rather than a second record.
- Reports and queries. Build a small set of saved queries and dashboards per campus at launch. It’s much easier than retrofitting after a year of mixed data.
Test before you switch over
Run a full day’s worth of scenarios in a test environment: a walk-up sale at each site, an online sale, a member check-in at each campus, a combined ticket, a refund, and an end-of-day reconciliation. Then pull your revenue and attendance reports and confirm finance can read them without extra work. If anything requires a spreadsheet to sort out, fix the setup now while there’s no history to migrate.
Quick answers
Should each campus have its own Altru database?
Rarely. Separate databases split your constituent records, memberships, and giving history, which makes it hard to see a supporter’s full relationship with you. One database with campus-specific programs is the more common choice.
Can we change our setup later?
Yes, but past transactions stay attached to whatever programs they were sold under. Restructuring later means your historical reports won’t line up with the new ones, so it’s worth deciding carefully before launch.
