How memberships, benefits and categories tie together

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 typed row in that matrix — an allowance ("3 wellness talks a year"), an unlimited pass, a percentage off, a fixed member price, early booking, a physical item, a voucher. It is what a tier actually includes, stored as real data your checkout can act on, not a sentence on a page nobody enforces.
• 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, registers for an event, or reserves an appointment, the platform 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, tour or appointment type, 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.

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, allowance at 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 percent_off at 10%. Its three children 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 their own priority binding, set directly on them. That binding is found at step 2, before the chain ever looks up at Tours — so neither one gets the 10% discount, deliberately: they get early booking access instead.

Same parent category, three different outcomes, because the chain always takes the nearest answer rather than combining every answer it finds.

Set it up for your own club

1. Create your tiers first. Under Offerings, set up the memberships and passes people will actually join — these become the columns of your benefit matrix.
2. Build your benefit catalogue. Under Members → Benefits, add a row for each real thing your tiers include — an allowance, an unlimited pass, a discount, a fixed price, priority booking, a physical item or a voucher. 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 mark it excluded if a tier deliberately doesn't include it. An empty cell means "pays the listed price," which is different from excluded — the public comparison table only shows a true ✗ for a benefit a tier was deliberately denied.
4. Create your categories. Under Events → Categories, build the groupings that match how you actually schedule things. 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 picker on its own edit page. If you already have uncategorised activities, the bulk-categorise queue on the same Categories page lists all of them at once so you aren't doing this one at a time.
7. Check your work. The coverage report on the same page flags two things worth a second look: a category bound to a benefit no tier actually grants, and an activity whose own binding disagrees with what its category would have given it anyway.

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, tour or appointment type, and always wins over whatever its category would have given it. Use it for the genuine exception — the way Community A uses it for Outrides and for Tours' two priority-booking children — 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 bulk-categorise queue and coverage 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.