Member vs. Non-Member Pricing, Automated: How Group Assignment Removes the Spreadsheet

If you run events for an association, a company, or a nonprofit, you already have people who should pay different prices for the same event — members vs. non-members, employees vs. customers, board members vs. general public. The usual fix is a spreadsheet that tracks who's who, plus a set of promo codes or manual overrides applied by hand during registration or at check-in. That works until your list gets big enough, or your event has enough moving parts, that someone inevitably gets charged the wrong price or is asked the wrong questions. This post walks through how Sunfish's Group Assignment feature removes that spreadsheet entirely.

The Manual Version of This Problem

Most organizers don't set out to build a fragile system — it just accumulates. You start with a spreadsheet column for "member status," then add a column for discount code, then a column for whether someone's staff and shouldn't be charged at all. Every event, someone exports the latest membership data, cross-references it against the registration list, and manually assigns codes or overrides.

The failure mode isn't dramatic, it's just constant. A member renews two days before the event and the spreadsheet doesn't get updated in time, so they're charged full price and have to be refunded at the door. A non-member finds a member's discount code shared in a group email and uses it. A staff person registers through the public link because nobody told them about the internal one, and now they're in the paid attendee count. None of these are catastrophic on their own, but they add up to awkward front-desk moments and pricing errors that someone has to notice and fix after the fact.

The deeper issue is that pricing and questions are being handled as two separate manual processes layered on top of registration, instead of being a property of who the person actually is. That's the gap Group Assignment is built to close.

How Group Assignment Automates Member vs. Non-Member Pricing

Here's the mechanism, in the founder's own words: "For the invite list, you can also assign each contact's group — member, non-member, staff, etc. That way they always get the right prices and questions when imported into an event."

In practice, that means the group label lives on the contact itself, not on a spreadsheet you maintain separately from your registration system. When you build or import your invite list, you tag each contact with a group — member, non-member, staff, or whatever categories make sense for your organization. Those categories aren't fixed by Sunfish; you define them to match how your organization actually segments people.

When that invite list is brought into a specific event, each contact's group travels with them. A contact tagged "member" sees the member ticket price. A contact tagged "non-member" sees the non-member price. A contact tagged "staff" sees whatever your staff rate is — often free or heavily discounted. Nobody has to apply a code, remember an override, or cross-check a second document. The price shown to each person is simply correct, because it's derived from data attached to their contact record before the event ever existed.

This is different from a promo-code approach, where the discount is a detachable string that anyone who has it can use. A group assignment is attached to the contact, not to a code that can be forwarded, guessed, or reused by the wrong person.

It's Not Just Pricing — It's the Questions Too

The part of this feature that's easy to undersell is that group assignment also controls which registration questions a person sees, not just what they pay. That matters because different groups genuinely need different information, and asking everyone the same questions creates its own mess.

A staff member registering for an internal conference might need to answer an internal badge question or select their department — information that's meaningless to an external customer and shouldn't appear on their form at all. A member of an association might get a chapter or region question so the event data rolls up correctly for their local chapter, while a non-member has no chapter to report and shouldn't be asked. Without group-based question logic, organizers either ask everyone every question (cluttering the form and confusing people with irrelevant fields) or manually build separate registration links per group and hope people use the right one.

With Group Assignment, the question set follows the same logic as the price: it's a property of the group, and it's applied automatically the moment a contact registers under that event. A staff contact sees the staff questions. A member contact sees the member questions. Nobody has to build and distribute three different registration URLs and hope everyone uses the correct one.

Manual Workaround vs. Group Assignment

Three Ways Organizers Actually Use This

A professional association with member, non-member, and student pricing. This is the clearest use case and probably the most common one. Members get the member rate and any member-specific questions, like chapter or region. Non-members pay full price and skip the chapter question entirely, since it doesn't apply to them. Students, if the association offers a separate rate, get their own tier with proof-of-status questions the other two groups never see. All three groups can register through the same event page — the group assignment on their contact record is what actually differentiates their experience.

A company running an internal conference alongside external customers. Employees might register for free or at a steep internal discount, while customers or partners pay the standard rate. Employees might also need to answer internal-only questions — department, cost center, manager approval — that would be nonsensical to show an external customer. Group Assignment means you can invite both audiences into the same event without building two separate registration flows or manually filtering who gets charged.

A nonprofit gala with donor-tier pricing. Board members might attend free as a matter of course. Major donors might get a reduced or comped rate as a thank-you for their giving level. General public attendees pay full price. Each of these groups might also need different questions — a board member might be asked about a speaking role, a major donor might be asked about a dedication or seating preference, and a general attendee might just need standard registration details. Assigning donor tier as a group means the right price and the right questions show up automatically for each attendee, without your team manually sorting the guest list by hand before the event.

The One-Time Setup Cost That Pays Off Every Event After

It's worth being direct about the tradeoff here: Group Assignment only works as well as the contact data behind it. The automation happens because each contact is already correctly tagged with their group before they're invited into an event — Sunfish isn't guessing who's a member and who isn't, it's reading a label you set.

That means there's real setup work the first time you do this: going through your contact list and assigning the correct group to each person, based on your actual membership, employment, or donor records. If your organization already tracks this information somewhere — a membership database, an HR system, a CRM — that work is mostly a matter of importing and mapping it correctly rather than starting from scratch.

The payoff is that this setup cost is paid once at the org level, not once per event. After your contacts are tagged, every event you run afterward inherits the correct groups automatically. You're not rebuilding the member/non-member/staff logic from a blank spreadsheet each time you launch a new event — you're reusing data you already set up correctly.

Where This Fits With Your Invite Lists

Group Assignment isn't a standalone setting — it lives on the same reusable invite lists you build once at the org level and reuse across every event you run. That's part of why the setup cost pays off repeatedly: the list and the group tags on it persist beyond any single event.

It also shows up in a related workflow: when someone requests access to a request-access, invite-only event, approving that request means picking which invite list — and which group — they belong to. So the same mechanism that handles a clean, pre-built invite list also handles the messier case of someone showing up unannounced and asking to be let in.

If you're earlier in the buying process and want the broader case for why associations specifically should care about member vs. non-member pricing as a category, the broader buyer's guide covers that ground. This post is meant as the mechanical follow-up — what actually happens once you decide that's a feature you need.

Key takeaways and next step

Manually tracking member, non-member, and staff status in a spreadsheet, then applying it by hand through promo codes or overrides, is a system that degrades as your list grows. Group Assignment fixes both halves of that problem — price and questions — by attaching a group label directly to each contact, so the correct experience shows up automatically the moment they're invited into an event. The only real cost is a one-time pass at tagging your contact list correctly, which then pays off on every event you run afterward.

If you're setting up an event with mixed pricing tiers — member and non-member, internal and external, or donor-tiered — take a look at how your invite list is tagged before you launch registration. Getting the groups right once at the list level is what makes everything downstream automatic.