← Knowledge base

Community owners · Memberships & plans

How memberships, benefits and categories tie together

How a member's tier decides what they pay for anything they book, and how early they can book it — walked through with Community A's pricing sheet, then set up step by step for your own club.

Every community on JollyBee is built from three connected pieces: the membership somebody joins, the benefits that membership includes, and the categories that let you bind a benefit once instead of repeating it on every class, event, tour and appointment you ever create. This article explains how the three fit together, using Community A — a mountain-bike and trail-running club — as the worked example, then walks through setting it up for your own club.

The three pieces

  • Membership is the tier somebody actually holds — an ongoing plan like Community A's SUMMIT or CLUB, a day pass, or a session pack bought outright. What a member holds decides which column of your benefit matrix applies to them.
  • Benefit is one row in that matrix: a thing your tiers give, such as hikes, coached rides or tours. Each tier's cell on the row says what that tier gets: a number of them ("3 wellness talks a year"), unlimited, a percentage off, a member price, early booking, an included item, a voucher, or nothing. It is stored as real data, not a sentence on a page: bookings and checkout act on the answers they can check, and each benefit is labelled with how far that goes, from Enforced and Partly enforced to Recorded or Shown only.
  • Category is a folder for the things you schedule — Hikes, Skills, Tours. Bind a benefit to the folder once, and every class, event, tour or appointment inside it inherits that benefit automatically. Add a new ride to the Hikes category next month, and it is covered the moment it is created — nothing to configure twice.

How JollyBee decides what a member pays

When a member books a class, an event ticket, an appointment or a tour, JollyBee first works out which benefit it counts as. It asks the same four questions, in order, and stops at the first "yes":

  1. Does this exact activity have its own binding? A benefit set directly on this one class, event or appointment type, or on a tour's event, bypassing categories entirely. Used for the exception, not the rule — Community A binds Outrides this way, since it's priced differently from everything else in its category.
  2. Does its category have a binding? If the activity itself sets nothing, JollyBee checks the category it belongs to.
  3. Does an ancestor category have one? Categories can nest up to four levels deep. If the immediate category is silent too, JollyBee walks up — nearest ancestor first — checking up to three levels further.
  4. Nothing anywhere in the chain. The member pays the listed price. This is deliberate: under-covering shows up as a support ticket you can fix; silently over-covering is money nobody notices leaking until reconciliation.

The nearest binding always wins. A binding set directly on an activity beats one inherited from its category, and a category's own binding beats one it could have inherited from its parent.

The cell for the member's tier on that benefit then decides the rest: what is included, what they pay and whether they can book before everyone else. Early booking counts back from the moment booking opens for everyone: a class's booking window, an appointment's, a ticket's sales start or a tour's Bookings open. A ticket with no sales start, or a tour with no Bookings open, is open to everyone at once, so there is nothing to book early. Early booking counts only while the member's plan is current, a member on more than one tier gets the most days any of them gives, and the member has to be signed in when they book: a booking made through a widget on your own website opens at the normal time.

Community A: the running example

Community A sells two ongoing memberships, SUMMIT and CLUB, plus a handful of session packs bought outright. Its pricing sheet lists what each tier includes across hikes, coached rides, skills sessions and tours — and almost all of it runs through two categories: Skills and Tours.

Hikes: a plain category binding

Hikes is bound once, on the Hikes category, with SUMMIT's cell reading Unlimited. Any SUMMIT member registering for any hike is covered automatically — including hikes added to the calendar after the category was set up, since the binding lives on the category, not on any one ride.

Skills: a grouping category with no benefit of its own

Skills organises three different offerings — a workshop, group sessions and 1-on-1 sessions — but carries no benefit itself; it exists purely to group them. Each child sets its own binding, and they don't have to match:

  • Skills · workshop — its own binding, an Allowance of 1 a year.
  • Skills · 1-on-1 sessions — a different own binding, Percent off at 10%. A SUMMIT member booking a R950 session pays R855.

Tours: where inheritance and override sit side by side

Tours is where the chain's behaviour shows clearest. The category itself carries a Tours benefit, with SUMMIT's cell reading Percent off at 10%. Its three child categories each answer the chain differently:

  • Local tours sets nothing of its own, so it inherits the 10% from Tours — step 3 of the chain.
  • Microadventures and International each carry a benefit of their own, set directly on them, and SUMMIT's cell on each reads Early booking only at 14 days. That binding is found at step 2, before the chain ever looks up at Tours — so neither one gets the 10% discount, deliberately. SUMMIT members book them 14 days before bookings open to everyone else, and pay the listed price.

Same parent category, three different outcomes, because the chain always takes the nearest answer rather than combining every answer it finds. Had Community A wanted SUMMIT to get both on International tours, one cell would do it: Percent off at 10% with Book early set to 14 days, which the comparison table shows as "10% off · book 14 days early".

A tour's category is chosen on the tour itself, not on its event, and so is its Bookings open, the moment everyone else can start booking.

Set it up for your own club

  1. Create your tiers first. Under Operations → Membership & Access Hub → Memberships & access, set up the memberships and passes people will actually join — these become the columns of your benefit matrix.
  2. Build your benefit catalogue. Under Operations → Membership & Access Hub → Benefits, add a row for each real thing your tiers give, and say what kind of thing it is: a session you run, a trip or tour, something in your shop, a perk at a partner and so on. That choice decides which answers the grid offers for it. Name them as your members would recognise them, the way Community A uses "Wellness talks" rather than a generic label — it keeps the grid readable a year from now.
  3. Fill in the grid. For each tier column and each benefit row, set what that tier gets, or choose Not included if a tier deliberately doesn't get it. A cell left on the first choice, "— pays listed price", is different from Not included — the public comparison table only shows a true ✗ for a benefit a tier was deliberately denied. On a benefit members book, an Allowance, Unlimited, Percent off or Member price cell can also carry Book early with a number of days, and Early booking only is the answer for a tier that books early and gets nothing else.
  4. Create your categories. Under Operations → Events & Experiences → Categories, build the groupings that match how you actually schedule things, and choose which kinds of thing each one is for: classes, events, appointment types, tours or any mix. Community A's Skills and Tours are a good model: a handful of top-level folders, nested no more than a level or two beyond that.
  5. Bind a benefit to a category once, instead of to every activity inside it. This is the whole payoff — do it here, and every class, event, tour or appointment type assigned to that category inherits it, including ones you haven't created yet.
  6. Assign your activities to categories. Every class, event, appointment type and tour has a category field on its own form, and a tour's is on the tour, not on its event. The Categories page also lists the classes, events and appointment types that have no category yet, so you can assign several at once instead of one at a time.
  7. Check your work. The report linked from the Categories page lists the categories whose benefit nobody holds yet, what each benefit covers, and every class, event or appointment type that has a benefit of its own as well as a category, saying whether the two differ.

Common questions

What's the difference between a category binding and an own binding?

A category binding covers everything filed under that category, present and future. An own binding is set directly on one specific class, event or appointment type, or on a tour's event, and always wins over whatever its category would have given it. Use it for the genuine exception — the way Community A uses it only for Outrides — not as your everyday setup, or you'll end up repeating the same cell on every activity instead of setting it once.

If I bind a category to a benefit, does everything already inside it update immediately?

Yes. The binding lives on the category, and every activity assigned to it is resolved fresh at checkout — there's nothing to re-save on the activities themselves.

What happens if I don't categorise something?

Nothing breaks. An uncategorised activity resolves through its own binding if it has one, or the member pays the listed price. It's always safe, just easy to lose track of at scale — which is what the Categories page's list of uncategorised activities and its report are for.

Can a category have no benefit at all?

Yes, and it's a normal, useful setup — Community A's Skills category organises three offerings without granting anything itself; each child sets its own benefit. A category is a folder first, an entitlement second.

How deep can categories nest?

Four levels. The platform stops you from nesting a fifth, and the resolution chain only ever walks up three ancestors from wherever an activity sits.

What if two tiers should get different things from the same benefit?

That's what the grid is for — a category binding names one benefit, and the matrix's columns are where each tier's actual entitlement against it differs: SUMMIT might read Unlimited where CLUB reads Allowance at 2 a year, on the very same benefit.