Your ticket buyer is not your attendee list

For reliable nonprofit event attendee tracking, keep the person who paid separate from the people who plan to attend. Attach the order to the buyer, attach each ticket to an attendee when individual follow-up matters, and record check-in as its own fact.

That split prevents a common group-order failure: one person buys four tickets, so the export shows one familiar contact and hides three people who may actually walk through the door.

Start with the buyer–attendee split

An event purchase answers at least two different questions: who completed the transaction, and who is expected at the event? One person can fill both roles, but your records should not assume that they always do.

Humanitix distinguishes an order from an attendee: an order is one transaction, one order can contain several tickets, and an attendee is a ticket holder. That distinction is a useful operating model even when your platform uses different labels.

Give each part of the event record one job:

1. The order owns the buyer, payment status, total, and receipt path.
2. The ticket owns admission, ticket type, and any reassignment.
3. The attendee record identifies the person expected to use that ticket.
4. The check-in state records whether that person actually arrived.

Do not use a completed order as proof that every ticket has a named attendee. Do not use a registration as proof that the person attended.

Collect individual details only when they change the work

Requiring a full profile for every guest can make registration heavier than the event needs. Collect a field only when someone on your team can name the action it controls.

A named attendee matters when your team needs to:

• prepare a badge or check-in list;
• send an individual ticket, reminder, or schedule;
• honor a meal, accessibility, session, or seating choice;
• preserve participation history across events; or
• follow up with the person who attended instead of only the buyer.

If none of those actions applies, the buyer and ticket quantity may be enough. Do not create individual contact records merely because the form can collect them.

The choice can vary by ticket type. A purchaser buying a table at a gala may not know every guest at checkout. A registrant choosing a workshop may need to supply their own email and session choice immediately. The Events Calendar documents no, optional, and required individual attendee collection, including separate names and email addresses for tickets bought together. The useful lesson is the decision range, not that one setting fits every event.

When the details are not needed at payment, mark those tickets as unassigned and give the buyer a clear deadline and path to add attendees later. Keep the minimum required fields aligned with your organization's data policy instead of turning the ticket form into a general survey.

Preserve the buyer when a ticket changes hands

A ticket reassignment changes who is expected to attend. It does not rewrite who paid.

Suppose Lina buys two tickets and later gives one to Omar. Keep Lina on the order and receipt. Update that ticket's attendee to Omar, then send Omar the information he needs. If your system links contacts, link both roles to the same order without merging them.

This separation also keeps service actions legible. GoFundMe Pro documents attendee details such as name, email, ticket type, and RSVP status, while refunds are handled from the transaction record. Exact screens vary, but an attendee edit and a money movement should remain different actions.

If your current tool stores only the purchaser, do not invent the missing guests after the event. Record that limitation. For the next event, add individual attendee collection or a linked registration step with stable order and ticket identifiers.

Run five cases before registration opens

Test the handoff with records that expose different roles:

1. One buyer purchases one ticket and attends.
2. One buyer purchases four tickets for four named attendees.
3. A buyer purchases a ticket for someone else and does not attend.
4. One ticket is reassigned after purchase.
5. A named attendee registers but does not check in.

For each case, confirm that your team can answer five questions without editing payment history:

• Who paid?
• How many valid tickets exist?
• Who was expected?
• Who arrived?
• Which person should receive the next event message?

The test fails if one contact is duplicated four times, a reassignment changes the receipt owner, every registrant appears as attended, or staff must combine unrelated spreadsheets to answer the questions.

Keep the records connected and the roles distinct

CharityStack event forms include ticketing and attendee fields. Its event workflow connects Event Forms, Checkout, and Contacts so a lean team can keep revenue and participant records in one fundraising system.

Connection should make the roles easier to see. The buyer can be a donor, sponsor, parent, host, or colleague. The attendee may be a different person entirely. Preserve both facts, and your post-event report can show who paid, who was expected, and who participated without guessing.