> For the complete documentation index, see [llms.txt](https://help.peoplevine.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.peoplevine.com/products/control-panel-overview/events-engine-overview.md). # Events & Bookings The Events module is how Peoplevine clubs publish gatherings, sell tickets, manage RSVPs, and check attendees in. Every event — from a free social to a ticketed gala — is a record in [**SELL > Manage Events**](https://control.peoplevine.com/events) that controls capacity, pricing, audience access, payment, communications, and check-in. > **Note (Pro Dash):** Events live under **SELL > EVENTS > Manage Events**. This article is the conceptual overview. For step-by-step setup, see the linked how-tos at the bottom. ### The four registration types Choose one when you create the event. Once an event exists, **you cannot change its registration type** — copy or recreate the event if you need a different model. | Type | Use For | Capacity Control | Payment | | ------------------------ | --------------------------------------------------------------- | -------------------------------------------------------- | -------- | | **Add to calendar** | Reminders only — no RSVP | None | None | | **Require Registration** | Free RSVP, member registers themselves only | Yes (via **Total People** field on the event setup page) | None | | **Digital tickets** | Full ticketing — capacity, pricing tiers, audience restrictions | Yes | Yes | | **External event** | RSVP via a third-party platform (you provide the URL) | External | External | > **Note**: When you allow a member to register more than themselves on an RSVP event, the event behaves like a ticketed event under the hood. If you need multi-person registration, choose **Digital tickets** so capacity and pricing work as expected. ### Privacy vs. permissions Two settings work together to control who sees the event and who can register: | Setting | Controls | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | **Visibility (Privacy)** | Whether the event appears on the public calendar, only on the member calendar, or only via a direct link. | | **Permissions** | Who can actually register — Anyone, Active Members Only (with selectable membership programs), or Staff Only (testing). | To run an event open to both members and the public, set **Visibility = Public** and create two ticket types — one restricted to membership programs (member rate) and one open to anyone (non-member rate). ### Tickets and inventory Ticket types live under the event. Each ticket has a title, price, capacity, sale window (start/stop selling dates), per-order min/max, and an optional visibility restriction by membership program. * **Linked inventory** allows multiple ticket types to draw from a single shared capacity pool. Always link non-primary tickets back to the main ticket so a single sold-out point applies to everyone. * **Capacity changes after sales have begun ADD to the pool, not replace.** If you start with 20, sell 10, and set capacity back to 20, you end up with **30** total (10 sold + 20 new available). Calculate carefully. ### Member Portal event display | Feature | What members see | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Join Waitlist button on sold-out events** | When the event is at capacity *and* a waitlist is enabled, the card shows **Join Waitlist** instead of **Sold Out**. Without a configured waitlist, the card still says Sold Out. | | **Tickets-on-sale-date message** | If the on-sale date is in the future, the event card shows *Tickets go on sale \[date]*. | | **Low ticket count indicator** | Once availability drops to **9 or fewer remaining**, the count is shown. Can be turned off platform-wide via the *Show Remaining Ticket Quantity* setting (managed by Peoplevine) so the card always reads *Tickets Available* until sold out. | | **External events display** | External events with no tickets do not show ticket-related copy. | ### The event lifecycle (admin perspective) ```mermaid stateDiagram-v2 state "Registration Open" as Open state "Sold Out" as SoldOut state "Waitlist Active" as Waitlist state "Event Day" as EventDay state "Check-In" as CheckIn [*] --> Draft : Staff creates event Draft --> Draft : Edit details Draft --> Approved : Publish (Status → Approved) Approved --> Open Open --> SoldOut : Capacity reached SoldOut --> Open : Cancellation or capacity increase SoldOut --> Waitlist : Waitlist configured Waitlist --> Open : Manual promote Open --> EventDay : Event start date SoldOut --> EventDay : Event start date EventDay --> CheckIn : Doors open CheckIn --> Completed : Event ends Completed --> [*] : Export guest list, post-event campaigns note right of Approved Direct Link visibility hides the event from the calendar (share URL only) — same lifecycle. Registration type is locked after the event is created. end note classDef setup fill:#4A90E2,stroke:#2E5C8A,stroke-width:2px,color:#fff classDef live fill:#2ECC71,stroke:#1A9C54,stroke-width:2px,color:#fff classDef constrained fill:#F5A623,stroke:#B37518,stroke-width:2px,color:#fff classDef terminal fill:#95A5A6,stroke:#7F8C8D,stroke-width:2px,color:#fff class Draft,Approved setup class Open,EventDay,CheckIn live class SoldOut,Waitlist constrained class Completed terminal ``` ### Check-in Front-of-house staff scan the digital QR code on a member's phone. The first scan checks the attendee in (*Valid ticket*); a second scan records a second timestamp (exported as `scan_out` — guests aren't typically scanned out); a third or later scan returns *Already redeemed*. Staff can also export a guest list from the event detail page to track attendance manually. For step-by-step check-in, see [How to Check In Event Attendees](/products/control-panel-overview/events-engine-overview/check-in-attendees.md). ### Sharing tickets * **Sharing tickets is ON by default.** The only configuration is whether to **disable** it. * The **Require Guest Email** and **Require Guest Mobile Number** settings (managed by Peoplevine) control what details a member must enter about the recipient — either or both. See: [Admin Settings Managed by Peoplevine](/products/portal-overview/portal-admin-settings.md). * Recipients receive their share via email or SMS and can present the ticket at the door like any other. ### Communications Three event-related communication points are normally configured: 1. **Event confirmation** — not sent by default. Requires a triggered response newsletter set to an event trigger (e.g., "Event registration confirmed"). See: [How to Set Up Event Emails](/products/control-panel-overview/events-engine-overview/setup-event-emails.md). 2. **Event reminder** — typically 24-48 hours before the event. Configured as a Pre-Arrival campaign. 3. **Post-event follow-up** — configured as a When It's Over campaign for feedback or upcoming-event promotion. All three are configured under **CONNECT**. ### Where revenue and stats appear | Surface | What you see | | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | **Event detail page** | Total Revenue, Awaiting (not yet checked in), Checked-In counts, Awaiting refund | | [**SELL > View Transactions**](https://control.peoplevine.com/transactions) | Each ticket purchase as a transaction with ticket type, member, amount | | **Guest list export** | Export a guest list (green button, top center of event detail page) or a face sheet PDF | ### Best Practice * **Create events in Draft first**, then move to Approved when you've checked the dates, ticket types, communications, and waitlist setup. Mistakes on a live event are visible to members immediately. * **Decide upfront on registration type**, because you cannot change it after creation. If you later need capacity control, you have to recreate the event with **Digital Tickets**. * **Always link inventory** for ticket tiers so you have one true sold-out point, not several silos. * **Enable the waitlist** on any event you expect to sell out so the *Join Waitlist* button replaces *Sold Out* on MP3.0. * **Watch the capacity-add behaviour** when adjusting tickets after sales have begun. If you mean *make the new total 30*, you only need to add **10** (not enter 30) when 20 already exist. ### What Happens Next * **On the member side**: An Approved event with public/permitted access appears on the events page. The member browses, registers or buys, receives the QR code by email, and presents it on event day. * **Next step**: [How to Set Up an Event](/products/control-panel-overview/events-engine-overview/create-event.md) · [How to Set Up a Member-Only Event](/products/control-panel-overview/events-engine-overview/setup-member-only-event.md) · [How to Manage Event Registrations](/products/control-panel-overview/events-engine-overview/manage-registrations.md) · [How to Set Up and Manage a Waitlist](/products/control-panel-overview/events-engine-overview/manage-waitlist.md) · [How to Check In Event Attendees](/products/control-panel-overview/events-engine-overview/check-in-attendees.md) · [How to Manage Event Registrations](/products/control-panel-overview/events-engine-overview/manage-registrations.md). *Last updated: 2026-06-12* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.peoplevine.com/products/control-panel-overview/events-engine-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.