Events and Tickets

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

Event Lifecycle (Organiser)

1. Draft

Create event with the right setup mode, schedule, visibility, ticketing, attendance, chat, and image choices.
Configure ticket types, ticket access, capacity, and buyer limits when the event uses tickets.
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 Required Ticket Docs 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.

Create Event Options

Use Create event when you want to set up a gathering and decide what Hubbaly should do for it from the start. You can keep the first version simple, then finish specialist setup from the event admin pages later.

Core Details

Name is the public event title. Keep it clear enough for members to recognise in tickets, emails, calendars, and event lists.
Starts at and Ends at are required for ticketed and no-ticket events because Hubbaly needs a real time for attendance, reminders, and event-day tools. For Collect interest first, both can stay blank while the date is still being worked out.
Description should explain what the event is, who it is for, and anything people should know before they register or turn up.
Location is optional at creation. Add it when the venue or address is known; collect-interest events can stay location TBC.
Capacity is optional. Use it when there is a real room, staffing, or safety limit.

Event Setup

This is the choice that changes how the rest of the form behaves.

Tickets available now creates a ticketed event. Use it when people should claim or buy a place, receive a ticket, and potentially show a QR code at check-in. This mode requires a start time and an end time before the event can be created.
Collect interest first creates an event page for demand-gathering before the date, venue, or tickets are final. People can register interest, but that does not reserve a place or guarantee tickets. Use this for early announcements, wait-and-see venues, or events where you want to email interested people when tickets go on sale.
Event-specific interest questions appear on the public Register interest form before the person submits. Use them only for one-off answers needed for this event’s interest list. Put reusable details such as full name or phone number in Hub -> Admin -> Advanced features -> Details to collect instead.
No tickets for this event creates an event without ticket claiming or checkout. Use it when people can simply attend, or when organisers only need a page, updates, chat, and manual attendance. QR ticket validation is not available in this mode.

Visibility and Discoverability

Hub only keeps the event inside the hub experience. This is best for private member gatherings or events that should not have a public share page.
Public listed gives the event a public event page and makes it eligible for public sharing and discovery surfaces. Public visibility does not automatically mean anyone can get tickets; ticket access is a separate choice.
Show attendee list on the event page controls whether visitors can see who is attending. Leave it off for more private or sensitive events.

Ticket Access

These choices appear when Tickets available now is selected.

Members only means only hub members can claim tickets. Extra tickets must be assigned to active hub members during checkout, and each member can hold one active ticket for the event.
Members plus guest tickets lets members reserve tickets for guests without naming every person straight away. Use it for private events where members may bring someone with them.
Public lets anyone claim tickets when the event is also Public listed. This is the mode that enables public guest checkout for signed-out buyers.
Buyer cap limits how many tickets one buyer can hold for the event. Leave it blank if there is no per-buyer limit.

Attendance Registration

This decides how Hubbaly should count attendance.

QR scan plus manual check-in is for ticketed events where door validation matters. Staff can scan tickets and still use manual check-in when needed.
Manual check-in only keeps attendance as a staff action in Event Day, without QR scanning.
Check-in optional is for ticketed events where holding a ticket usually counts as attended, but Scanner and Event Day should still be available.
Off means Hubbaly will not register attendance for this event. Use it when attendance records are not needed.

Event Chat and Images

Create initial event channels creates useful event channels at the same time as the event. You can start with ticket-holder and staff channels, choose the membership behavior for each channel, then adjust chat in Event Admin after creation.
Flyer or artwork is optional. Upload a clear square image if you already have one; otherwise you can add or replace event images after the event record exists.

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 & reconciliation is the event-only settlement view for gross sales, refunds, disputes, Hubbaly fee, Stripe processing, original organiser net, final 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 spreadsheet 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 and reconciliation, 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 view can hand you into Stripe with Manage in Stripe. If setup still needs work, the finance view will point you to the right hub payments action instead.

Hub Finance

Use Hub Admin -> Finance for hub-wide money, payouts, refunds, disputes, and reconciliation.

Hub Finance is the hub-level view for orders, refunds, payout history, and open dispute tracking across events.
The summary highlights Gross sales, Final organiser net, Available balance, and Paid out totals; a secondary strip breaks out Platform fee, Card processing, Original organiser net, Refunded, and Open disputes.
Open disputes surface as an alert banner above the hero stats while any remain open, with amount, reason, evidence deadline, and event context where Hubbaly can map the dispute back to an event.
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.
Each event card expands to show Gross, Platform fee, Card processing, Original organiser net, Final organiser net, Refunded, and ticket-type revenue rows.
Use the Export CSV action in the page header for date-scoped finance CSVs, and use each event row for attendee export without exposing attendee email addresses.
Use Finance Digest Emails on the finance 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, reservations, checkout, or QR access.
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.
For members-only ticket types on a public event, Hubbaly shows the ticket publicly as reserved for hub members with sign-in and join guidance, so visitors can see the ticket name and price. Active hub members can still buy it from the normal event page.
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 resources (FAQ, notes, links, files)

Manage event-facing resources in Event Admin -> Documents -> Event resources. This tab covers practical details that do not belong in the main event description.

Good examples:

Arrival time, parking, transit, and meeting-point notes.
Accessibility details and what to bring.
Private joining instructions for ticket holders.
Short FAQs such as “Can I bring a guest?” or “What happens if it rains?”
Downloadable PDFs/images such as floor plans, schedules, and waiver readables.
External links to maps, partner pages, or supporting docs.

Each resource has its own visibility:

Everyone: visible to anyone who can view the event page.
Members & ticket holders: visible to hub members and active ticket holders.
Ticket holders only: visible only to people with an active ticket for this event.

File limits: PDF, JPEG, PNG, WebP, GIF up to 25 MB. Downloads are access-checked: a denied download returns 404 (privacy boundary) instead of revealing that a private file exists.

Attendee documents/waivers and post-event feedback forms continue to live in their own tabs in the same workspace.

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.
Hubbaly also has fixed platform checkout limits: up to 10 of one ticket type and 20 tickets total per checkout. These are not event settings.

Discount Codes

Use Event -> Admin -> Tickets -> Discounts when you want to offer a specific ticket discount without changing the public ticket price.

Discounts belong to one event. Create a shared code when many buyers can use the same code, or a unique batch when each buyer should receive a one-use code.
A discount can be percentage based, a fixed amount off the order, or a fixed amount off each eligible ticket.
Scope a discount to all ticket types or selected ticket types from the discount form. You do not need to edit ticket types just to allow or block a code.
Buyers can use one code per order, and that one code can discount more than one eligible ticket in the order. For example, a staff discount can apply to the staff member and their partner when both tickets are eligible.
Optional start/end dates, total redemption limits, and per-buyer limits control when and how often a code can be used.
Copy link creates an event link with discountCode pre-filled. The buyer still needs to apply the code during checkout so they can see the updated subtotal, discount, and total before paying.
You can pause a discount without affecting tickets already bought. After the first redemption, Hubbaly locks the code value, discount type, and ticket scope so historical refunds and reporting stay stable. You can still rename it, extend the end date, or raise usage limits.
A 100% discount on paid tickets is still recorded as a checkout order, not a complimentary ticket.
Refunds are based on what the buyer actually paid after discount. Refunding an order does not free the code usage back up; the code was used and remains counted.
Review performance from the Tickets discount panel, the Event Admin Sales tab summary, and the finance report/export.

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:

Tickets are dated event access, so buyers should not assume a change-of-mind refund is available.
If an event is cancelled, moved, rescheduled, or materially changed, direct refund handling follows the organiser’s obligations, Hubbaly platform rules, and payment-provider requirements.
Refunds always go back to the original purchaser.
A ticket designated to someone else at checkout can still be requested from the original purchase when it has not been later transferred, but the designated holder must approve before Hubbaly releases the place.
Pending holder approval does not lock that holder’s pass. The holder can approve the return, keep the ticket, or transfer it before any place is released. If they transfer it first, the approval request is cancelled because the requested holder no longer owns the ticket.
Once a ticket is transferred after checkout, it must be transferred back to the original purchaser before a self-serve refund can be requested.
Members plus guests events allow the original purchaser to hold extra guest tickets, so transfer-back should not be blocked just because the purchaser already has one active ticket.
If a strict members-only event does not allow guest tickets and the original purchaser already has another active ticket for that event, Hubbaly can show Transfer back blocked because moving the ticket back would give that purchaser two active tickets in an event that only allows one member-held ticket per person.
Transfer-back can be blocked by strict members-only holder 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.

Ticket Returns and Released Tickets

About Ticket Return requests

If enabled for the event, this optional Hubbaly feature lets eligible paid ticket holders request a conditional return before or after primary availability sells out. It is separate from cancellation or material-change refund rights. The queue protects normal ticket availability, and the replacement buyer receives a newly issued ticket from the organiser only when Hubbaly releases a place.

Original purchaser starts from Account → Purchases.
Purchaser-held tickets queue immediately.
Clean designated-at-checkout tickets ask the current holder to approve before Hubbaly releases the place. The holder receives an in-app notification and email, and the pass remains valid while they decide.
Once a ticket is queued or holder-approved, the original ticket is locked from transfer/check-in.
A released ticket hold can then be offered to the waitlist.
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.
The original purchaser’s refund is triggered only after a replacement purchase succeeds (Hubbaly fee and Stripe processing retained under the standard policy).

Important policy notes:

Refund is not guaranteed until a replacement purchase completes.
Holder approval is not a refund and not a return request. It is only consent from the attendee currently holding a clean designated-at-checkout ticket.
Ticket returns are a Hubbaly product feature, not a legal refund obligation.
Unresolved requests expire at event start.
Waitlist-first released tickets 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.
The readiness area is an attention panel, not a second attendee list. Before the event it highlights preparation gaps, during the event it becomes Needs attention, and after the event it becomes attendance follow-up.
Use the attention panel for counts and the first few people who need action; use the roster, filters, search, and scanner for the full participant list.
People to review is for actionable work: missing required forms, forms that need re-signing, and post-event feedback follow-up. Refunded, transferred, voided, or replaced tickets stay in summary counts for audit context; they are not listed as people to review.
Roster rows show profile display names first, then @username when a display name is blank. Uploaded avatars follow profile-photo visibility rules, including connection-only photos; generated fallback avatars are unique per account.
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