Event Chamber Booking Links
This process explains how to set up event booking links when multiple chambers are involved. It outlines when to use round-robin scheduling versus dedicated booking links, how to minimize the number of links attendees see, and how to ensure capacity, pricing, and VIP control are handled correctly without creating unnecessary inboxes or complexity.
Table of Contents
Current Situation
How booking works today
- Each chamber requires its own meeting link
- Each meeting link is tied to a separate calendar
- To support multiple calendars, the team has created multiple shared inboxes:
- events@immortal
- hello@immortal
- marketing@immortal
- (and others as needed)
- These inboxes exist primarily to host calendars, not because they represent real teams
What happens operationally
- Event staff:
- Log into HubSpot
- Switch owners/calendars
- Manually select the “right” link for each chamber
- Attendees:
- See multiple booking links
- Often don’t understand the difference between chambers
- For large events:
- More chambers = more links = more inboxes
Where it breaks down
- Scaling problem
- Upcoming events (e.g., Biohacking) require 6 chambers
- Current model implies 6 links + potentially 2 new inboxes
- UX friction
- “Chamber 1 vs Chamber 2” means nothing to attendees
- Operational risk
- High cognitive load onsite
- Easy to send the wrong link
- System debt
- Inbox sprawl
- No standard rules for when a new link or inbox is needed
- Hidden inefficiency
- Calendars are doing capacity work
- Inboxes are being misused as a workaround
Events Booking & Chamber Scheduling SOP
Purpose
This SOP defines how Immortal plans, builds, and manages event booking links when multiple chambers are involved. It ensures:
- A clean attendee experience
- Scalable operations for large events
- Minimal inbox and link sprawl
- Consistent reporting and automation
This SOP applies to all events using HubSpot meeting links, including paid, free, VIP, and multi‑chamber events.
Core Principle
Solve capacity with calendars and logic not inboxes.
Inbox creation is a last resort. Calendars define capacity. Booking strategy defines scale.
Step 1: Classify the Event
Before opening HubSpot, answer the following:
- Total number of chambers?
- Are any chambers interchangeable?
- Are any chambers VIP‑controlled?
- Are sessions paid, free, or mixed?
- Do chambers have different hours?
If these answers are unclear, stop and clarify. HubSpot configuration comes after this step.
Step 2: Choose the Correct Booking Strategy
Option A: Round‑Robin Booking Link
Use when:
- Chambers have identical pricing
- Chambers have the same availability
- No manual/VIP control is required
- Chambers are operationally interchangeable
Result:
- One public booking link
- Multiple calendars behind the scenes
- HubSpot auto‑assigns capacity
Do NOT use if:
- Any chamber needs manual blocking
- Pricing differs
- Hours differ materially
Option B: Dedicated Chamber Booking Link
Use when:
- Chamber has unique hours
- VIP holds are required
- Slots are unblocked manually onsite
- Chamber is physically separate or staffed differently
Result:
- One link per chamber
- Maximum control
- No automated balancing
Option C: Separate Links for Paid vs Free
Use when:
- Pricing differs
- Confirmation emails differ
- Reporting must clearly separate revenue vs non‑revenue
Result:
- At least two links (Paid / Free)
- Each may still use round‑robin internally
Option D: Hybrid Model (Default for Large Events)
Use when:
- 4+ chambers
- Mixed pricing
- Mixed schedules
- VIP presence
Typical structure:
- Standard paid chambers → 1 round‑robin link
- VIP chambers → 1 link per chamber
- Free chambers → 1 free link
Step 3: Calendar Rules (Non‑Negotiable)
- One calendar = one physical chamber
- Calendars reflect real availability only
- VIP calendars default to blocked if needed
- Calendars are reused before creating new inboxes
- Inbox creation requires justification
Step 4: Meeting Link Build Standards
Naming Convention
Format:
Event Name | Location | Chamber Type | Paid/Free | Time Zone
Example:
Biohacking | Miami | VIP Chamber | Paid | PT
Required Settings
- Owner set to shared inbox (not a person)
- Correct time zone selected
- Clear description for attendee context
- Product attached if paid
Round‑Robin Specific
- Rotation created intentionally
- Only eligible calendars selected
- Test multiple bookings to confirm distribution
Step 5: Attendee Experience Rules
- Attendees never choose between "Chamber 1 / Chamber 2"
- Choices are based on experience, not logistics
Approved labels:
- Book a Standard Session
- Book a VIP Session
- Book a Free Session
- No more than 3 booking options visible at once
Step 6: Automation & Lists
For every booking link:
- Trigger workflow on meeting submission
- Add contact to:
- Event Attendee list
- Event‑specific list
- Apply marketing subscription only if consented
- Respect suppression lists
Step 7: Testing Checklist
Before launch:
- Book the same time slot repeatedly
- Test first and last available slots
- Test paid and free paths
- Confirm blocked calendars prevent booking
- Confirm confirmation + reminder emails
No event goes live untested.
Step 8: Documentation & Handoff
- Event links logged in central tracker
- Deviations documented
- SOP updated if pattern changes
- Events team trained on decision logic, not just clicks
Golden Rules
- If humans need flexibility → isolate the link
- If the system can handle it → round‑robin it
- Never scale inboxes to solve capacity
- Consistency beats cleverness
Ownership
- SOP Owner: Events Operations
- Review cadence: Quarterly or after flagship events
Summary
This SOP ensures Immortal can scale events from 1 chamber to 6+ chambers without increasing chaos, while protecting attendee experience, reporting integrity, and onsite flexibility.
Quick Decision Tree
- Are these chambers interchangeable?
- Yes → Round-robin
- No → Dedicated link
- Is pricing different?
- Yes → Separate links
- No → Continue
- Does it require VIP or onsite control?
- Yes → Dedicated link
- No → Round-robin
- Is this a large / flagship event?
- Yes → Hybrid model
- No → Simplest valid option