Tenant User Guides

What it’s used for

Choosing the event context for tabs that operate on a specific event (Check-In, Attendees lists, and Reports).

Configure

• • Open Dashboard → Ticketing to reach Ticketing Management.
• • In the header, open the Active Event dropdown and select the event you want to operate on.

Use day-to-day

• • If Operations / Attendees / Analytics show a warning, select an Active Event first.
• • If you were deep-linked with an event in the URL, the app may preselect that event automatically.

Pro tips

• • Sales → Events actions (Preview / Publish / Configure) don’t rely on Active Event — they work per event card.
• • If you’re supporting multiple events, confirm Active Event before processing refunds/transfers/check-ins.

What it’s used for

Your primary control surface for ticketing per event: turn ticketing on/off, configure settings, preview the buyer page, and control public visibility.

Configure

• • Open Ticketing → Sales → Events.
• • Use filters (Current & Future / Past / All) and Ticketing Enabled/Disabled to find the event.
• • If Ticketing is Off, click Enable Ticketing (or click Configure to proceed — configuration can initialize defaults).
• • Click Configure to open the event ticketing configuration page.

Use day-to-day

• • Use Preview to open the buyer-facing event page on the tenant portal.
• • Use Publish / Unpublish to control whether the event appears on the public events page.
• • Use Disable to remove ticketing config (existing tickets/orders may still exist depending on backend rules).

Pro tips

• • Treat Publish/Unpublish as a buyer-visibility control — always preview after changing it.
• • If publishing paid tickets is blocked, your tenant may need payments onboarding (e.g., Stripe Connect) before publishing.

What it’s used for

Defining what buyers can purchase and when, including ticket tiers, pricing, inventory, and core constraints.

Configure

• • Open Ticketing → Sales → Events and click Configure on the event card.
• • On the ticketing configuration page, start in Pricing & Revenue to set up tiers/prices/inventory and any revenue settings available for your tenant.
• • If Auto-save is enabled, pause briefly after edits; otherwise click Save.
• • Use Copy Preview Link / Open Preview to confirm what buyers will see.

Use day-to-day

• • Update tiers/pricing in controlled windows and validate buyer visibility via Preview.
• • Coordinate major pricing changes with Comms/RSVP if communications are already scheduled or sent.

Pro tips

• • The configuration page can create defaults if a config doesn’t exist yet — it’s safe to click Configure early in setup.
• • Avoid last-minute pricing/inventory changes without a clear internal note/runbook entry for support alignment.

What it’s used for

Controlling buyer experience and operational rules: verification/security, policies & compliance, capacity/visibility, galleries/images, lineup content, and event/venue details.

Configure

• • Open Ticketing → Sales → Events → Configure for an event.
• • Use the configuration sections (e.g., Verification & Security, Policies & Compliance, Visibility & Capacity).
• • In Verification & Security, decide whether to enable Require Email Verification (this changes when tickets are delivered to buyers after checkout).
• • Update Images/Gallery and Lineup/Performers so the buyer page has complete content.
• • Use Event Metadata and Venue Details to keep the ticketing buyer page consistent with the event listing.

Use day-to-day

• • Re-validate Preview after changing policies/visibility (these impact checkout eligibility and who can see the event).
• • If Require Email Verification is ON, buyers will receive a verification email after purchase and must confirm their email before tickets are sent.
• • If Require Email Verification is OFF, tickets can be delivered immediately after purchase (no email-confirmation gate).
• • If you plan to use reserved seating, configure Seating before opening sales.

Pro tips

• • Keep “Visibility” aligned with your intended sales channel (public vs private vs members-only).
• • Enable email verification when you want higher confidence that buyer inboxes are reachable before tickets are issued.
• • Image and content changes are “buyer facing” — preview them before publishing.

What it’s used for

Confirming the buyer-facing event page loads and shows the correct tiers, pricing, and availability — and that the event is visible (or hidden) on the public events page as intended.

Configure

• • From Ticketing → Sales → Events, click Preview on the event card.
• • If the event should appear on the public events page, click Publish; if it should be hidden, click Unpublish.

Use day-to-day

• • After any meaningful config change, re-open Preview to confirm tiers and rules updated as expected.
• • Verify sale window behavior (pre-sale vs on-sale vs ended) and inventory/availability messaging.

Pro tips

• • Test in a private/incognito window to avoid admin-session bias.
• • If preview fails, your tenant subdomain may be missing; set it before relying on preview/copy-link flows.

What it’s used for

Resolving edge cases (refund approvals, transfer history, resale issues, comp invites) while keeping sales and entry operations stable.

Configure

• • Select the correct Active Event (header) before working exceptions in Operations/Attendees.

Use day-to-day

• • Operations → Refunds: approve/reject pending refunds and process approved refunds when ready.
• • Attendees → Transfers: review Pending vs History; watch for transfers that require ID rebinding.
• • Attendees → Resale: monitor active listings vs “My Listings”, and review disputes/payout status where shown.
• • Attendees → Comp Invites (admin): create invites by selecting a ticket tier + quantity (optionally set an expiry).
• • Comp Invites → Require email verification: when ON, the recipient must verify via a 6-digit email code before the claim completes (recipient email is required).
• • Comp Invites → Require email verification: when OFF, the invite link is effectively public — anyone with the link can claim tickets instantly (email can be left blank on the invite).
• • After a successful claim, the claimant can access printable tickets from the claim flow, and confirmations/tickets are sent to the email address used during the claim.

Pro tips

• • Clear exception backlog before event day; day-of queues should stay quiet and fast.
• • If an action fails, double-check Active Event and your role scope before retrying.

What it’s used for

Preparing entry operations: pairing scanning devices to the event and creating/scoping scanner operators securely.

Configure

• • Select the Active Event (header).
• • Open Ticketing → Operations → Scanner Setup.
• • Use the pairing QR/URL to pair scanning devices (pairing link uses `/scanner/#/pair?pairing_token=...`).
• • Create scanner operators (optionally email PINs), and set session duration as needed.

Use day-to-day

• • Rotate the pairing token if you suspect the QR/link leaked or after a major staffing change.
• • Enable/disable operators to control who can scan for the event.
• • Use an override PIN only for controlled operational scenarios; clear it when no longer needed.

Pro tips

• • Pair devices before gates open; don’t wait for the first queue spike.
• • Treat operator PINs like credentials — rotate/reset if shared accidentally.

What it’s used for

Running entry operations: scanning QR codes, validating tickets, committing check-ins, and handling spot issues fast.

Configure

• • Confirm Scanner Setup is complete (paired device + active operator) before gates open.

Use day-to-day

• • Use camera scanning or a keyboard wedge scanner, depending on device setup.
• • If connectivity is unreliable, use Offline Mode where supported and sync when back online.
• • Resolve scan failures by validating ticket state (already used/invalid) and operator/event selection.

Pro tips

• • If scan counts don’t change, verify Active Event, operator state, and device pairing first.
• • Keep one “manual entry” operator ready for edge cases (damaged QR, device camera issues).

What it’s used for

Helping support and operations teams find attendees quickly (checked-in vs pending) and export lists for gates/finance/workflows.

Configure

• • Select the Active Event (header).

Use day-to-day

• • Filter attendees (e.g., checked-in/pending) and narrow by ticket type where available.
• • Export CSV for offline reconciliation, incident response, or stakeholder reporting.

Pro tips

• • Export right before doors open if you need a “snapshot” list for offline backup.

What it’s used for

Closing the loop after the event with auditable attendance and sales outcomes (sold vs checked-in vs refunds/adjustments).

Configure

No configuration required.

Use day-to-day

• • Analytics → Reports: review sales/ticket/attendance metrics for the Active Event.
• • Attendees → Purchase History (admin): verify order timelines and investigate anomalies.
• • Cross-check attendee exports against check-in outcomes for any disputes or audits.

Pro tips

• • Reconcile exceptions first; they often explain discrepancies in totals.

What it’s used for

Managing the tenant public events page surface and quickly copying/previewing the buyer-facing events listing for QA and stakeholder review.

Configure

• • Open Ticketing → Configuration.
• • Use Copy Link to copy the tenant public events page URL.
• • Use Preview to open the tenant public events page.
• • Use Customize to open the tenant portal page where branding/layout can be adjusted.

Use day-to-day

• • Use alongside Publish/Unpublish in Sales → Events to validate what the public events page should show.

Pro tips

• • If Copy/Preview fails, your tenant subdomain is likely missing — add it before relying on these controls.

What it’s used for

Monitoring and controlling fraud-related signals and policies for ticketing operations.

Configure

• • Select the Active Event (header).
• • Open Ticketing → Configuration → Fraud Detection.

Use day-to-day

• • Use fraud controls as part of the exception triage process (especially during peak sales windows).

Pro tips

• • Keep fraud policy changes minimal during doors-open unless you have a clear incident.

What it’s used for

Platform admin workflows for discovery/search surfaces; hidden for tenant admins without platform access.

Configure

No configuration required.

Use day-to-day

• • If you do not have platform admin access, this tab won’t be available (or will show “Platform admin access required”).

Pro tips

• • Treat discovery changes as platform-level configuration; validate across tenants/environments where applicable.