Events and Tickets

This guide covers attendee and organiser workflows, with emphasis on event-day reliability.

Event Lifecycle (Organiser)

1. Draft

Create event with name, date/time, location, and visibility.
Configure ticket types and capacity.
Attach required forms and publish versions.
Assign event staff roles and permissions.

2. Publish

Publish only when event details and policy are final.
Once sales begin, date/time edits should be deliberate and minimal.
Visibility and access settings control discoverability and checkout behaviour.

3. Operate

Use event admin tabs for Event Day, Scan, Chat, tickets, staff, and updates.
Event Day is the main live roster workspace during an active event and relabels to Attendance records after the event.
Scan only appears when the event attendance registration allows QR validation.
When scanning is enabled, treat Scanner as the main door tool and Event Day as the broader oversight and records workspace.
If attendance registration is off, Event Day stays available as a read-only roster and Scan is hidden.
Scanner and readiness checks are canonical and enforce required-form completion.
Use overrides only when policy and permissions allow.

Event Staff Setup

Start with reusable staff roles for stable bundles like Door Team, Incidents, or Stage.
If one person needs an exception for one event, use Customise access on that staff assignment instead of creating another role.
Sensitive permissions such as Verify Members and Override Consent can only be granted by owners/admins.
If you later remove the exception, reset the assignment back to Role defaults.

4. Close

Post final updates where needed.
Review attendance and incident outcomes.
Resolve refund/void actions deliberately.
Archive operationally complete events.

Post-Event Reports

Use Event -> Admin -> Reports after the event ends.

Operational Debrief is the organiser closeout view for attendance, arrival timing, staff turnout, incidents, and follow-up items.
Finance Report is the settlement view for gross sales, refunds, disputes, Hubbaly fee, Stripe processing, organiser net, and reconciliation anomalies.
Use the drilldown links instead of exporting people-level attendance data from this workspace. Event Day, Staff, and Incidents stay the canonical detail pages.
Export finance CSV stays finance-only and summary-led. It does not include the attendance roster or per-person check-in times.
Download PDF opens a combined print-friendly pack with executive summary, operational debrief, finance summary, and action items.
The post-event email is a shorter combined summary. Use it as the inbox handoff, then open the reports workspace for full detail.
If the event had paid orders and payments are ready, the finance report can hand you into Stripe with Manage in Stripe. If setup still needs work, the finance report will point you to the right hub payments action instead.

Sales Workspace

Use Hub Admin -> Sales for cross-event commercial operations.

Sales is the hub-level view for orders, refunds, payout history, and open dispute tracking across events.
The summary highlights gross, fees, net settlement, net-after-adjustments, live Stripe balances, and paid-out totals when Connect is configured.
The payouts section links back to Stripe for full payout detail and still shows recorded payout history if the live Stripe read is temporarily unavailable.
Open disputes are called out separately with amount, reason, evidence deadline, and event context where Hubbaly can map the dispute back to an event.
Each event card exposes gross, platform fee, net settlement, refunds, net-after-adjustments, and ticket-type revenue rows.
Use the export controls for date-scoped finance CSVs, and use each event row for attendee export without exposing attendee email addresses.
Use Finance Digest Emails on the sales page to choose Off, Daily, Weekdays only, or Weekly (Monday at the chosen local time), set the local send time/timezone, and add finance recipients beyond the owner.
Scheduled digests are suppressed automatically when the reporting window has no meaningful finance activity, so Hubbaly does not send zero-activity summary email.
Critical finance alerts stay immediate for payout failures, Stripe capability issues, disputes, and reconciliation problems even if scheduled digests are off.
Event admin Tickets stays focused on event setup and live operations.
Event ticket pages now show recent orders and recent sold tickets only, with drill-down pages for full browsing/search.

Paid Ticket Readiness

Check Hub -> Admin -> Settings -> Payments before publishing or changing live paid tickets.

Fully ready means the hub can take payments and the platform checkout path is active for that hub.
Connected, rollout not active means the hub has a connected account, but this hub can still use legacy paid checkout until Connect rollout is active for it.
Platform setup incomplete or Needs review means do not treat paid-ticket setup as healthy yet. The hub may be connected, but the platform checkout path or recent sale evidence does not match the expected Connect route.
This is not determined by old event versus new event alone. Hub rollout policy and the checkout path used at sale time matter more.
If a newly sold paid ticket later shows 0 Hubbaly fee / 0 Stripe fee in Event Admin refunds, pause and review payments setup before more sales. That usually indicates legacy routing or incomplete platform paid-ticket readiness rather than a harmless display mismatch.
Draft events can still keep paid ticket types saved while setup is incomplete, but publishing or changing live paid tickets is blocked until the required readiness checks pass.

Event Admin Settings

Use Event -> Admin -> Settings to control the event rules before people arrive.

Event Admin Settings Basic Info

Set the event name, description, and date/time carefully.

Keep major date/time changes deliberate once tickets are live.
Add enough description for attendees and staff to understand the event quickly.
Treat this as the source of truth for what the event is and when it happens.

Event Admin Settings Location

Use this to set the venue name and address the team should rely on.

Make sure the location is accurate before publishing.
Keep it consistent with any email or update copy you send later.

Event Admin Settings Images

Use event images for the event page, admin context, and outbound communications.

Upload clear artwork that still makes sense on mobile.
Replace test artwork before the event is public.

Event Admin Settings Visibility

This decides whether the event is hub-only or public.

Hub Only keeps discovery and checkout inside the hub.
Public allows direct-link viewing and public ticket access where policy allows.
Public events with active tickets cannot be switched back to Hub Only until active ticket count returns to zero.
Review this alongside ticket eligibility so the public/private behaviour stays consistent.
Public event pages can show hub context, but they only link back to the hub overview when the hub itself is public.
Public event pages can reuse the hub banner only when the hub is public. Private hub banners are not reused on public event surfaces.

Treat public event visibility and public ticket access as related but separate decisions.

Only Public events get a real public event page that you can share outside the hub.
Hub Only events do not have a public event page, so they are not intended for normal public discovery or search results.
An event can still have a public event page even if tickets are members-only. That page can explain the event publicly while keeping buying restricted to eligible members.
Appearing in search results is not immediate or guaranteed. The main requirement on your side is that the event actually has a public event page and clear public-facing details.
Use a stable event slug, a clear event title, and a short description that explains what the event is and why someone should care before they click through.

When someone shares a public event link, the preview usually comes from the event’s public metadata.

The social sharing card typically uses the event title, description, and a main image.
If an event flyer is available, that is usually the strongest image for the social sharing card. If not, Hubbaly can fall back to other event artwork.
Choose artwork that still reads well in a wide preview crop and does not rely on tiny edge text.
Review public event details before sharing widely, because the card preview often becomes the first impression people see in messages and social feeds.

Event Admin Settings Tickets and Access

Use this section to decide whether tickets are required and who can get them.

Turn ticketing on only when the event really needs controlled entry or registration.
Set capacity deliberately.
Choose whether tickets are member-only, member-plus-guest, or public.
Members only: only hub members can buy, ticket 1 stays with the buyer, and every extra ticket must be assigned to an active hub member during checkout.
Members + guests: only hub members can start checkout, but extra tickets do not all need a designated member up front. Assign existing members during checkout if you already know them; any extra tickets you leave unassigned stay on the buyer account for now so you can reserve places for guests without naming them first.
Public: anyone can buy when the event is public-listed. This is the only mode that enables the separate guest-checkout flow for signed-out buyers.
Paid ticket types can stay saved while the event is still in draft, but once the event is live Hubbaly requires both hub payment capability and platform paid-ticket readiness before paid sales continue.

Event Admin Settings Attendance Registration

This controls how Hubbaly registers attendance for the event.

Use QR scanning when entry validation matters.
Use manual-only when you want Event Day to be the check-in tool.
Keep the attendee list visible only if that suits the event privacy posture.
Ticket QR visibility is platform-managed. Hubbaly shows attendee QR codes 24 hours before the event starts, and there is no per-event timing setting in v1.

Event Admin Settings Chat

This section is informational only. Event chat is channel-first now.

Use Event -> Admin -> Chat to manage the actual event channels: create channels, rename them, disable them, and restore them later if needed.
/chat can also create an event channel now. Start from the main chat page, choose Event channel, then pick the event you manage.
If an event has no active event channels, the event page simply does not show event chat until an organiser creates the first one.
Ticket holders gives access to anyone with an active ticket for the event, including people using the same Hubbaly account to hold a ticket without being hub members.
Ticket holders who are members is useful when the event is public but the chat should stay inside the hub membership boundary.
Staff is for event staff coordination.
Verified attendees (after check-in) is a later/additional channel option for post-attendance discussion. It only becomes relevant after attendance has been confirmed by scanning a ticket or marking someone attended manually.
Name the channel for the job people will recognise, then let the audience preset control who can get in.
Use event updates for organiser announcements. Event chat no longer includes a separate event announcements channel.
Use Event -> Admin -> Documents to manage required forms.

Event Admin Actions and Danger Zone

These are operator-only actions with wider impact.

Duplicating is useful for recurring formats.
Delete/archive actions should only be used when you are sure the event should no longer exist in its current state.
Pause before any destructive change once staff, tickets, or attendees exist.

Ticket Lifecycle (Attendee)

Discover an event.
Select ticket type and quantity.
Complete checkout (or free/comp flow).
Open ticket in My Tickets or from the secure hosted ticket link sent by email.
Complete required forms before arrival.
Present QR at check-in.

Additional ticket access notes:

Signed-in ticket holders use My Tickets and the ticket detail page as the main source of truth, including the ticket links sent in purchase confirmations and reminder emails.
Placeholder or email-only ticket holders can use the secure hosted ticket link sent in purchase confirmations and reminder emails.
The scannable QR appears 24 hours before the event starts. Before that, ticket surfaces show the readiness state/countdown instead of the QR itself.
If required forms are still incomplete, the ticket surface sends the holder into the guest-consent flow and then returns them to the ticket afterward.
If you lose a guest/email ticket message, use Find my ticket. Recovery emails send signed-in holders back to My Tickets and send email-only holders fresh hosted ticket links for upcoming active events.
If a hosted ticket link has expired or no longer works, use Find my ticket to request a fresh access email.
Hosted guest-ticket surfaces also offer Email me a sign-in link as the primary account-claim path, with Create password instead as the secondary option.

Guest Checkout

Use guest checkout when a public event allows account-free purchase.

Guest checkout only appears on published public-listed events with Public ticket access. Members only ticket types still require a signed-in eligible member.
The guest form is email-first. Buyers enter an email address and can optionally add a name before selecting quantities.
If that email already belongs to a real Hubbaly account, guest checkout is blocked on purpose. Sign in with that email instead so the tickets attach to the existing account.
If you already have or want a Hubbaly account, use the Log in or Create account links on the guest-checkout page before paying. Hubbaly keeps your email and selected ticket quantities when it hands you into auth.
Free guest checkout confirms immediately on the page and by email.
Paid guest checkout goes through Stripe, then returns to a guest-friendly processing screen that verifies the payment and hands off to ticket access without assuming you are signed in.
If you close or cancel out of Stripe before paying, Hubbaly returns you to guest checkout with your current guest details and ticket selections preserved.
Guest purchasers are sent a secure hosted ticket link in purchase confirmations and reminder emails. Hubbaly does not send the raw scannable QR directly in the email body.
The hosted ticket page is read-only. It shows ticket details, readiness state, required-form status, and then the QR itself once the 24-hour activation window opens.
If required forms are still outstanding, the hosted ticket page sends the holder into the guest-consent flow and then safely returns them to the same ticket page afterward.
Find my ticket appears only on guest-relevant surfaces: auth pages, guest success / hosted ticket flows, and public event pages where guest checkout is actually available.
Recovery is email-only and privacy-preserving. Hubbaly always shows the same success state, then emails either My Tickets or secure hosted ticket links for upcoming active events tied to that email.
Guest holders can claim tickets into a full account from the hosted ticket page or guest-completion flows. Email me a sign-in link is the fastest path; Create password instead stays available if you want a normal password login immediately.
About 24 hours before the event, guest/email-only holders get one state-aware reminder email: either the QR is ready, or required forms still need to be completed before the QR becomes available.
Creating an account later with the same email upgrades the placeholder guest account and keeps those tickets/purchases attached to the new real account automatically.

Public Event Albums

Public event pages can show event-linked public albums.
Album cards open the specific album directly.
The broader View all public albums handoff is only shown when the hub itself is public.

Ticket Types

Ticket types let you shape how people book:

Create different offers such as General Admission, VIP, free entry, guest list, or staff tickets.
Choose the price, how many are available, whether they count toward event capacity, and who can buy them.
Ticket prices can be free, or at least £1.00 for paid entry.
Use Members Only when a ticket should only be available to hub members.
Use a sales window if you want sales to start later or stop before the event begins.
Turn a ticket type off by making it inactive instead of deleting it when you want to pause sales.

Ticket Price Phases

Use ticket price phases when one ticket type should get more expensive over time without cloning separate ticket tiers.

When phases are enabled, Phase 1 is the first live price for that ticket type.
There is no separate base price running before Phase 1.
If Phase 1 starts in the future, that ticket type shows as coming soon instead of selling at a fallback price.
Each phase can be free, or at least £1.00.
Each later phase must start after the previous one.
Later phases can keep the same price or increase it, but they cannot go down.
If you also use a delayed sales start, Phase 1 cannot begin before that sales window opens.
Use clear phase names such as Early Bird, Standard, or Final Release so buyers understand what changes next.

Ticket Notes

Use Event -> Admin -> Tickets when buyers need more context than the generic checkout policy card.

Event Ticket Notes are the default notes for the whole event.
Use event notes for shared guidance such as arrival details, dress code, ID checks, accessibility info, or house rules that apply across ticket types.
Each ticket type then chooses one behaviour:
- Use event notes: show only the event-wide note.
- Add ticket note: show the event-wide note first, then extra ticket-specific notes.
- Override event notes: hide the event-wide note and show only the ticket-specific note.
Ticket notes support markdown paragraphs and bullet lists.
Buyers only see these notes after they choose a quantity for that ticket type on a ticket-selection surface.
The Reuse from this hub picker copies a previously used note into the current editor as a starting point. It does not stay linked to the original.

Buyer Limits

Use buyer limits when you want to stop one account from buying too many tickets.

Set an event-wide buyer cap if you want one buyer to have a total ceiling across the whole event.
Set a ticket-type buyer cap if only one ticket type needs a stricter limit, such as VIP or early access.
These limits apply to normal self-serve checkout only.
Complimentary tickets and staff-issued tickets are not blocked by buyer limits.
Buyer caps work across all orders, not just one checkout basket.
Buyer caps follow the original purchaser account, even if tickets are later transferred.

Transfers

Before event start and when policy allows:

Owner initiates transfer.
Recipient accepts.
Ownership updates and transfer history is retained.
Member-only policy can block transfer if recipient already has an active ticket.

Transfer targeting rules:

Public ticket-access events can be transferred either to an existing eligible account or directly to an email address.
Email-targeted recipients get a secure review link by email, can accept without joining the hub first, and can claim a full account afterward.
Holding a transferred public-event ticket does not automatically make the recipient a hub member or unlock hub-only features.
Members only ticket-access events still require transfer to an eligible existing account through the in-app recipient search.

Refund policy note:

Refunds always go back to the original purchaser.
A ticket designated to someone else at checkout can still be refunded from the original purchase when it has not been later transferred.
Once a ticket is transferred after checkout, it must be transferred back to the original purchaser before a self-serve refund can be requested.
If the original purchaser already has another active members-only ticket for that event, Hubbaly can show Transfer back blocked because the transfer would be rejected under the same holder-uniqueness rules that govern transfer acceptance.
Transfer-back can be blocked by those holder-uniqueness rules, so some cases need organiser/support handling instead.
Event Admin standard refunds retain the Hubbaly fee and Stripe processing shown in the refund breakdown.
Event Admin can also choose a full-refund override when the organiser should absorb those retained fees instead.

Sold-out Waitlist

Use the waitlist when tickets are full and you want to keep a clear order for who gets the next chance.

People join the waitlist from the event page after tickets sell out.
Event waitlists are tied to Hubbaly accounts.
On public event pages, signed-in viewers can join directly and logged-out viewers go through an account handoff before the entry is created.
Each requested ticket creates its own queue slot. Joining for 2 adds 2 slots, and adding 1 later appends one more slot to the back of the line.
Buyers can see their queue position when they join and again on the waitlist management page.
Buyers can remove individual waitlist slots or remove several at once instead of clearing the whole waitlist every time.
Waitlist joins still respect event-wide and ticket-type buyer caps.
When a place opens again, Hubbaly automatically offers it to the next people waiting.
Release notifications tell the buyer they are next in line, include the exact Purchase by deadline, and the waitlist management page shows that same deadline while a slot is released.
The release email and waitlist management page also let the buyer use Pass to next person if they no longer want those tickets.
If the buyer passes or misses the deadline, that slot moves to the next person in line automatically and the earlier buyer gets a closure message with a rejoin link.
Places can reopen because stock is added, a checkout hold expires, or a ticket is cancelled/refunded back into normal inventory.
If an organiser increases ticket capacity after sellout, Hubbaly automatically offers the newly opened seats to the front of the relevant waitlist instead of leaving those buyers stuck waiting.
The platform only sends new offers for seats that are actually free at that moment. Live checkout reservations still count as held inventory, so a large capacity increase does not over-invite beyond real availability.
If one ticket type is sold out while another is still on sale, the sold-out ticket type can show its own waitlist entry point without blocking the other ticket type from being purchased.
The batch size controls how many people get a chance at the same time when places reopen automatically, but a post-sellout capacity increase can promote a larger number when that many newly opened seats are genuinely available.
You can remove entries if someone no longer wants a place.

Status guide:

Waiting: the person is still in line.
Invited: they were offered a place.
Joined: they completed checkout after being invited.
Removed: they were removed or left the list.

Complimentary Tickets

Use complimentary tickets when you want to issue a free place without sending someone through normal checkout.

Good for staff, VIP guests, media, partners, or promo attendees.
Search for an existing member or type an email address.
The ticket uses the rules of the ticket type you choose, including whether it counts toward capacity.
The attendee receives a normal ticket after it is issued.

Resell

If enabled for the event, this flow replaces ad-hoc peer-to-peer resale for eligible paid attendee tickets.

Ticket holder queues the ticket to resell.
Original ticket is locked from transfer/check-in.
Replacement inventory is released immediately.
Matching runs with waitlist-first timed offers.
If a buyer passes or the timed hold expires, Hubbaly offers that slot to the next eligible waitlist buyer before falling back to public checkout.
Seller payout is triggered only after replacement sale succeeds (Hubbaly fee and Stripe processing retained under the standard policy).

Important policy notes:

Refund payout is not guaranteed until replacement sale completes.
Unresolved requests expire at event start.
Waitlist-first refund offers use the same automatic You're next in line, Purchase by, and Pass to next person flow as the standard sold-out waitlist.
If a timed offer expires, or the current buyer passes, that buyer gets a closure/rejoin message and the slot continues through the next waitlist-or-public fallback step.
REFUND_PENDING can persist temporarily when Stripe/Connect settlement requires retry/reconciliation.
Ticket holders usually start this from Account → Purchases, and each live ticket page now includes a shortcut back to the matching purchase row.
Organisers turn this on per ticket type in Event Admin → Tickets.

Designated Tickets at Checkout

One payer can assign tickets to other members at checkout:

Payer remains financial source-of-truth,
Ticket holder and payer can differ,
Refunds return to original payer,
Ledger keeps ownership and refund states explicit.

How that changes by ticket-access mode:

Members only: after the buyer’s own ticket, every extra ticket must be assigned to an active hub member before checkout can continue.
Members + guests: assigning existing members is optional. Use it when you already know which member should hold a ticket. Any extra tickets you leave unassigned stay on the buyer account for now, which lets a member reserve places for guests on private events without naming them first.
Public: people can usually buy directly for themselves instead of relying on member assignment, and signed-out guest checkout is available only when the event is also public-listed.

Critical Event Updates

Time-change alerts should only be sent for actual time changes.
Time text should be human-readable.
Non-time edits should not be labeled as time changes.

Identity verification for events

Identity verification is an advanced capability for selected communities. Use it only when a community sometimes confirms identity in person and needs a reusable trusted state for later events, without storing sensitive ID documents online.

Common organiser use cases:

Name or ID-style checks at entry,
Private or trust-sensitive community events,
Marking someone as known or identified in person so later events can rely on that community-level trusted state.

How it works:

Hubbaly enables it for a specific community.
After that, the hub then chooses whether to turn identity verification on.
Hub -> Admin -> Settings then chooses whether to turn identity verification on for that hub.
Once the hub enables it, specific events choose whether to use it.
Members see calmer Door-check details wording on member-facing surfaces instead of the system label.
Members can save their legal name and, if useful, an optional private photo from Hub -> Verification.
Owners/admins, or event staff with VERIFY_MEMBERS, can review those details or mark someone verified in person.
That verified state belongs to the hub, so future events can reuse it without asking the person to upload sensitive documents.

What is stored:

Legal name,
Optional private photo,
Trusted/reviewed state,
Review history for who confirmed or revoked it,
No sensitive ID documents stored online.

Event setting options:

Off: do not use identity verification for this event beyond normal ticket validation.
On demand: staff can open identity details after a successful online scan when they need an extra check.
Used at door: identity verification is part of the normal door workflow for this event after ticket validation.

Important limits:

Ticket validation still stays the main event-day step.
Scanner review only appears after a successful online validation.
Offline scanning can continue, but identity verification review does not.
Hub admins can also review or revoke someone’s trusted state from Hub -> Admin -> Verification.
Communities that have not been enabled by Hubbaly do not see this workflow in normal hub or event admin settings.

Event Day Scanning

Use Event -> Admin -> Scan for live check-in.

If the event attendance registration is Manual only or Off, the Scan tab is hidden from navigation.
Owners/admins can still open the disabled scan page from a direct link to confirm why it is unavailable and jump back to settings.
Managers and staff are redirected to the next visible admin workspace instead of staying on a disabled scanner route.
Scanner opens in manual mode first so desk teams can search immediately and deliberately switch into camera use when they need it.
Use Camera is the primary scanner action when live scanning is enabled.
Camera mode is best for phone-based QR scanning.
Manual input/search is useful for desk workflows and hardware scanners.
For very large events, scanner manual mode becomes search-first instead of showing a passive browse list.
Offline pack download is only available in the native shell. The standard web app scanner still needs a live connection when the page reloads.
Offline scanning should be prepared before losing connectivity, not after.
Review Recent Scans if someone disputes whether they were checked in.
If the event uses private door-check details, the panel appears only after a successful online validation and only when an operator intentionally reveals it.
Staff need the separate VERIFY_MEMBERS permission to use that panel unless they are already a hub OWNER or ADMIN.
Offline scanning can continue, but private door-check review does not.
Scanner review is one option, not the only one: hub admins can also review members from Hub -> Admin -> Verification.

Event Day and Attendance Records

Use Event -> Admin -> Event Day for the live roster during the event. After the event, the same workspace relabels to Attendance records for later review.

If attendance registration is Off, Event Day stays visible for organisers and other roster-capable roles, but it becomes read-only and Scan stays hidden.
Event Day is the place to review checked-in tickets, who is not in yet, blocked arrivals, staff-on-site status, and recent arrivals from one canonical roster.
The main summary answers the door question first: how many tickets are in and how many are still to come.
On larger events, Event Day opens search-first with summary, filters, and a small recent-arrivals feed instead of a long passive roster.
Review the policy banner first so operators know what counts as confirmed.
Use manual confirmation only when it matches the event policy.
Keep notes short and factual if you manually confirm someone.

Incident Logging and Follow-up

Use Event -> Admin -> Incidents to capture operational problems with an audit trail.

Report incidents when something operational or safety-relevant happens.
Apply outcomes only after the facts are clear enough to explain the decision later.
Use this for durable records, not casual back-and-forth discussion.

Post-Event Reports and Reconciliation

Use Event -> Admin -> Reports after the event to review what happened.

Ticket Summary shows sales and check-in outcomes.
Required Forms Mismatch highlights readiness/compliance gaps.
Payment Reconciliation helps operators spot ledger or Stripe coverage issues.
Incidents & Notes gives a quick operational summary for follow-up and handoff.

Event-Day Quick Checklist

Scanner operators are assigned and tested.
Required forms readiness is monitored.
Staff escalation owner is known.
Critical update path is ready.
Incident logging path is verified.

Where to Go Next

Forms and signer rules: Required Forms and Waivers
Refund rules and outcomes: Purchases and Refunds
Event admin governance flow: Community Admin
Ops templates and handoff packs: Support Playbooks