A board member registers for your spring gala and brings two guests. You know one guest’s name and that the other is vegetarian. Neither of them will ever give you another dollar, and you’d rather not add two thin constituent records that someone has to clean up next year. Where does that information go?
Altru wasn’t really designed to store detail about a person who doesn’t have a record. Every way around that is a compromise. The useful question is which compromise fits the situation, and the answer depends on whether you’re dealing with an event, a group visit, or a walk-up sale.
Start with the right question: will you need this person again?
Before you pick a workaround, sort guests into two buckets:
- One-time context. A name for a place card, a meal choice, an accessibility need, a chaperone’s phone number for the day of a field trip. You need this until the event or visit is over, and then it doesn’t matter.
- A potential relationship. Someone you might solicit, invite again, or thank later. If you’d ever want to email them, look them up, or see their history, they need a constituent record. Squeezing them into a note means you’ll lose them.
Teams often resist creating records because they’re worried about duplicates. That’s a reasonable worry, but it’s a data-entry habit problem (search before you add, use consistent name formats), not a reason to hide real prospects in free text.
Event guests
Events are where this comes up most. Altru’s event registration lets a registrant bring guests, and depending on how your event is set up, those guests can be recorded without being tied to their own constituent. That keeps your headcount, seating, and pricing accurate. The catch is that an unnamed guest has very little room for descriptive information of its own.
Practical places to put guest details:
- Notes on the host’s registration. Something like “Guest 1: Jordan Lee. Guest 2: vegetarian, no name given.” It’s not reportable in a clean way, but it travels with the registration and staff checking people in can see it.
- Registration-level fields or options, if your event uses them. If you already collect a meal choice or similar selection during registration, check whether it can be set per guest or only per registrant. Test this in a sandbox or on a test event before you rely on it, because the behavior depends on how the event and its registration options are configured.
- A working list outside Altru. For a seated dinner, many teams keep a seating spreadsheet anyway. Pull registrants with a query, add guest names and meal choices in the sheet, and treat the sheet as disposable once the event is done. Just don’t let it become the only place a future donor’s name is stored.
If an unnamed guest turns out to matter, say they make a gift at the event or ask to be added to your newsletter, create the constituent then. If your version of Altru supports replacing an unnamed guest with a named constituent on the registration, use that so attendance shows up in their history. If you aren’t sure it does, ask Blackbaud support before your next big event, not the night of.
Group visits
School groups, tour operators, and camps are a different case. You usually have one organizer and a headcount. Altru’s group sales are built around the group and its contact, not around each person in the bus, and that’s how it should be. You don’t want thirty fourth-graders in your database.
Put day-of details where the group record lets you: notes, the itinerary, or whatever comments field your team uses on the reservation. Typical entries are “2 wheelchair users,” “chaperone lead: Ms. Patel, cell on file with teacher,” or “1 severe nut allergy, lunch area only.” Agree on one place for this so the person printing the arrival sheet knows where to look.
Walk-up admission and store sales
Daily sales don’t require a constituent at all. An anonymous ticket sale is normal and expected. Problems start when staff try to capture something about the buyer anyway, like a ZIP code or how they heard about you, and invent a different method at each register.
If you want visitor information without building records, decide what you need in aggregate and capture it the same way every time. Whatever your sales setup allows for transaction-level detail, use one method consistently so it can be counted later. If you can’t find a clean field for it, don’t stuff it into a generic “Guest” constituent. That shared placeholder record piles up thousands of unrelated transactions and skews any report that touches it.
Habits that keep this from becoming a mess
- Write a short rule card. “Event guest with no follow-up: note on the host’s registration. Group details: reservation notes. Anyone who gives, buys a membership, or asks to hear from us: full record.”
- Use one note format. “Guest 1 / Guest 2” in the same order every time makes notes much easier to scan at check-in.
- Clean up after the event. Once it’s over, look through the guest notes for anyone who should become a real constituent, and add them while the context is fresh.
- Keep sensitive details minimal. Dietary and accessibility needs are fine for a single event. Avoid recording health details beyond what staff need to serve the person that day.
Quick answers
Can I store a name for an unnamed guest without creating a constituent?
Not as a structured, searchable field that I’d count on. A note on the host’s registration is the dependable option. If you need it to be searchable later, the person probably needs a record.
Should we use a generic “Guest” constituent for everyone?
No. It’s convenient at the register, but it makes revenue, attendance, and constituent reports harder to trust, and it’s tedious to undo.
