> ## Documentation Index > Fetch the complete documentation index at: https://docs.orriven.com/llms.txt > Use this file to discover all available pages before exploring further. # Perks > Define a benefit once — a breakfast voucher, lounge access — then grant it from tickets, codes and add-ons, and require it at sessions and venues. A perk is a benefit that exists **once** for the whole event — "Breakfast voucher", "VIP lounge access", "Workshop seat" — and is then *bound* to the things that grant it or require it. The **Perks** page in the event navigation is where perks are created and where you get the overview; the bindings themselves are made elsewhere. ## Granting and honouring Perk bindings come in two directions: **Granting — who receives the perk:** * A **ticket type** — every holder of that ticket gets its perks. * A **redemption code** — its perks stack *on top of* the ticket's own; see [Offers & redemptions](/en/ticketing/offers). * An **add-on** — its perks are what the add-on delivers; see [Add-ons](/en/ticketing/addons). * A single **attendee** — a one-off grant, edited on that attendee's detail page. **Honouring — where the perk is required:** * An **agenda session** — bind perks to it and only holders of one of them may attend; see [Agenda](/en/program/agenda). * A **venue** — bind perks to it and only holders may enter; sessions held there inherit the gate; see [Venues](/en/program/venues). The chain is always *ticket → perk → session*: a gated session never names ticket types directly, it names the perks — and any ticket, code or add-on granting one of those perks opens the door. On the honouring side, **any binding restricts**. A session or venue with no perk bindings is open to everyone; the moment one perk is bound, entry is holders-only. ## Create a perk and bind it On the Perks page, click **Create perk** and name it (e.g. "Breakfast voucher"). That's the whole definition — a perk has no configuration of its own. Open a ticket type, add-on, redemption code or attendee page and select the perk there — under "Perks this type includes", "Perks this add-on grants", and so on. Open an agenda session or a venue and select the perk as its entry requirement. ## The Perks page is the map, not the editor Each perk's detail page lists **every binding** — the ticket types, codes, add-ons and attendees that grant or hold it — with a link to each. But the list is **read-only**: bindings are always edited on the bound thing's own page. This keeps each page the single place its configuration lives. ## Rules to know * **Define once, bind many.** Don't create "VIP breakfast" and "Speaker breakfast" if they're the same voucher — one perk, several granting bindings. * **Code perks stack.** An attendee entering with a code holds the ticket's perks *plus* the code's. * **Direct grants are per-attendee** and managed on the attendee's page — useful for one-off exceptions without minting a ticket type. * **Assigning a speaker to a gated session grants them its required perks** automatically (and removing the assignment does not take them back) — see [Speakers](/en/program/speakers). * **Venues add their gate on top.** A session in a perk-gated venue requires the venue's perks in addition to its own. * **Perks archive, never delete.** Bindings and history survive; an archived perk stops appearing in pickers. Restore it to use it again. * Each perk's log records changes to the perk and every binding change that includes it. ## Related The most common granting side. Sessions gated by required perks. Rooms whose perks are their entry gate. Codes whose perks stack on the ticket's.