Overview
Allow clients to reserve multiple spots in a single group meeting booking transaction. This feature enables one email/client to book multiple spots without creating separate booking records.
Approach: Single Booking with Multiple Spots
Current implementation - One email books multiple spots in a single transaction.
How it Works
Client selects number of spots (1-N, where N = spots remaining) in one booking form
System generates automatic question: "How many spots would you like to book?"
Single payment transaction for all spots
One booking record with spot quantity field
One confirmation email mentioning multiple spots
Feature Settings
Enabling the Feature
Location: Meeting settings page
UI Component: Checkbox with description
Checkbox Label: "Allow one client to book multiple spots in the same meeting"
Helper Text: "When enabled, a new question will be added to your booking form where clients can select the number of spots to book. [View help article to learn more]"
Behavior:
When checked → Automatically adds "How many spots would you like to book?" question to the Questions tab as the first question
When unchecked → Removes the question from booking form
Questions Tab Changes
Auto-Generated Question
Question Text: "How many spots would you like to book?"
Position: First question (above Name and Email fields)
Type: Dropdown
Default value: 1
Question Properties
Editable:
Question text can be edited
Non-Editable/Hidden:
Clone option: Removed (not available)
Delete option: Available but shows tooltip
Required setting: Always required (like Name/Email fields)
Hide option: Not available
Advanced properties: Kept for consistency
Delete Tooltip: "You have enabled the feature to reserve multiple spots in one booking. To remove this question, disable the setting."
Edit Modal Behavior
When editing this question:
Question text is editable
Options section header is kept (for consistency with form nano)
Info banner text: "The dropdown choices will automatically update based on the number of spots remaining"
Advanced properties section: Displayed but with limited options
Settings like "Required", "Hide" are removed (behaves like Name/Email fields)
Client Booking Page Experience
Question Display
Location: Above Name and Email fields
UI Components:
Question: "How many spots would you like to book?"
Dropdown: Default value = 1
Info banner: Displays "X spots remaining" (dynamically loaded when page loads)
Dropdown Behavior
Lists numbers from 1 to (spots remaining)
Updates dynamically based on real-time availability
Client selects desired number of spots
UI Design Decision
Component choice: Dropdown (vs text field or number picker)
Engineering simplicity
Design team recommendation
Action item: Praveen to share final thoughts on dropdown vs number picker component and width constraints
Booking Details Display
Bookings Table View
Changes:
Add tag next to client name/email showing number of spots booked
Example: "John Doe (3 spots)" or badge showing "3 spots"
Purpose: Host can see at a glance how many people to expect (e.g., 2 clients but 4 total spots = 4 attendees)
Individual Booking Detail Page
Client Section Changes:
Show "X spots" tag next to client information
Display in responses section as well
Example:
If 3 spots booked: Show "3 spots" prominently
If 1 spot booked: Show "1 spot" or no tag (TBD)
Multiple clients example: Client A (3 spots), Client B (1 spot)
Responses Section:
Include the "How many spots would you like to book?" question
Display the answer (e.g., "3")
Email Notifications
Template Approach
Keep existing "Meeting scheduled" template (same as current group booking)
No change to email header
Customers haven't reported issues with current approach
Host Email Changes
Subject: Meeting scheduled - [Meeting Type] for [Date/Time]
Body Changes:
Under "Responses" section: Include "How many spots would you like to book?" with answer
Next to client name: Add tag showing number of spots booked
Example:
Client: John Doe (3 spots)
Email: [email protected]
Responses:
- How many spots would you like to book? 3
- [Other custom questions and answers]Client Email Changes
Subject: Meeting scheduled - [Meeting Type] for [Date/Time]
Body Changes:
Same as host email
Show number of spots booked next to their information
Include response to spots question
Payment Handling
Display Logic
When setting is enabled:
Show "per spot" label next to price
If taxes exist: Show "per spot (+ tax)" in brackets
Example:
Price: ₹120 per spot
Tax: 5% per spotPrice Calculation Display
Simple Case (No discounts/taxes)
When spots = 1:
Amount payable: ₹120
When spots = 3:
Add breakdown section showing: "3 spots × ₹120"
Amount payable: ₹360
With Taxes/Discounts (Table view)
Format:
Item Price
Yoga Class 5 spots (5 × $120.00) ₹600
Tax (5%) ₹30
─────────────────────────────────────────────
Total Amount Payable ₹630Implementation Note:
Show "X spots × ₹Y" with reduced text size
Maintain consistency with recurring meeting display format
Payment Method
UPI Case (no table displayed):
Show price breakdown: "3 spots × ₹120 = ₹360"
Display final amount payable
Package Integration
Duration Calculation
Formula: Meeting duration × Number of spots = Package duration consumed
Example:
Meeting duration: 30 minutes
Spots booked: 3
Package duration consumed: 90 minutes
Validation
Scenario: Package has insufficient duration remaining
Error Message:
"You have exceeded the duration remaining in your package.
Please remove additional spots to continue."Note: Same logic as recurring meetings, but "slots" changed to "spots"
Recurring Meetings with Packages
Formula: Meeting duration × Number of spots × Number of sessions
Example:
Meeting duration: 30 minutes
Spots per session: 3
Number of sessions: 4
Total package duration consumed: 30 × 3 × 4 = 360 minutes
Data Export (Google Sheets/CSV)
Current Behavior
Each client gets one row in export
Shows client name, email, meeting details, etc.
New Behavior
Add new column: "Number of spots booked"
Example:
Name Email Meeting Date Spots Booked
John Doe [email protected] Jan 15, 2025 3
Jane Smith [email protected] Jan 15, 2025 1Technical Implementation
Settings Dependencies
Accept Payment Online
Payment amount = Base price × Spots selected
Display: "₹X per spot"
Split Payment
Split calculation across total amount (price × spots)
Each payee pays proportional amount of total
Taxes
Applied to total amount: (Base price × Spots) + Tax
Display: "per spot (+ tax %)"
Tip
Applied to total amount after spots calculation
Discount Codes
Same behavior as recurring bookings
Applied per spot (similar to per slot logic)
Validation considers total after spot multiplication
Cancellation & Rescheduling
Cancellation Rules
Full cancellation only - All spots must be cancelled together
No partial cancellation - Cannot cancel individual spots
Client cancels → All spots freed up
Host cancels → All reserved spots restored to availability
Rescheduling Rules
All spots rescheduled together
Cannot reschedule partial spots
Same number of spots must be available in new time slot
No-Show Handling
No partial no-shows
Mark entire booking (all spots) as no-show
Cannot mark individual spots as no-show
Edge Cases & Validations
Spot Availability Validation
Scenario: Number of spots selected > Number of spots remaining
Prevention:
Primary: Dropdown limits selections to available spots
Validation: Backend check before confirming booking
Error Message (if race condition occurs):
"Number of spots selected exceeds the spots remaining.
Reload this page for latest availability."Host Reduces Group Capacity
Scenario: Host changes max capacity from 10 to 5, but 9 spots already booked
Behavior:
Existing bookings (9 spots) remain valid
No new bookings allowed until spots < 5
System respects existing commitments
Pre-filled Links
Field Code: Add support for pre-filling number of spots
Validation:
If pre-filled value > spots remaining → Default to 1
If pre-filled value ≤ spots remaining → Use pre-filled value
Example: ?spots=3
Package Expiry
Expiry determined by actual booking time, not meeting date
No change from current behavior
Not a real edge case
Reports & Analytics
Bookings by Client
Each spot counts as one booking by client
Total bookings = Sum of all spots across all bookings
Example: 2 bookings (3 spots + 2 spots) = 5 total bookings by client
UI Changes Summary
Settings Page
✅ Checkbox to enable/disable feature
✅ Helper text with link to help article
Questions Tab
✅ Auto-generated "How many spots" question (first position)
✅ Remove clone option
✅ Delete tooltip explaining how to remove
✅ Info banner in edit modal about auto-updating dropdown
✅ Keep "Options/Choices" header for consistency
✅ Remove "Required" and "Hide" settings (behaves like Name/Email)
Client Booking Page
✅ Dropdown with default value = 1
✅ Info banner showing "X spots remaining"
✅ Positioned above Name and Email fields
Booking Details Page
✅ Tag showing number of spots in bookings table
✅ Tag showing number of spots next to client name
✅ Display question/answer in responses section
✅ Total number of clients will be = total number of spots.
Payment Page
✅ "per spot" label next to price
✅ Breakdown showing "X spots × ₹Y"
✅ Table view for complex cases with taxes/discounts
Email Templates
✅ Keep "Meeting scheduled" header
✅ Add spots count next to client name
✅ Include question/answer in responses section
Proposed changes by Kirti.
Kept "Options" header for the sake of consistency. In our form nano for dropdowns the heading is already there. And could eliminate potential questions of "Where is the options". Suggested text is better I have updated it. "Choices" is better than "Options" imo.
100% agree, let's keep advanced properties.
Same as 2.
Yes, this will be the expected behaviour. Will mention in final video.
Agreed, will mention in video. Also we can add tag in the table.
We can go as per decision from engineering team.
Edge cases.
I remember discussing this in PL call, and the decision was to do full cancellation. No support for partial cancellation. Because we can always add that in the future. Reason was -> We don't know how many people will use this, let's take it up on a request basis. No other notable competitor has this feature, hence the demand is uncertain. Let's keep it simple.
Too much complexity for now, we can decide to take up in phase two. Implementation has already been scoped.
Yes, this is the expected behaviour of existing group bookings.
Similar to point 1, decision to not support partial no show. Can take up as per request.
Yes, the same validation we have for package limit reached will be applicable. But currently we are do not have any error message shown. If remaining minutes < duration of meeting, we just show that the client has to pay, no error message.
Here as well we do not support partial package. For example if 15 minutes remain, and meeting is 30 minutes, client still has to pay full price. Similarly if n x meeting duration > remaining in package, client can pay full. Consistent with existing logic, and we can take this up in phase 2 on requests.
Yes, expected behaviour. Will mention in video.
I don't think we should not reduce, if some slots are overbooked after the change, we can just show that there are no slots remaining. This is a customer decision, no need to block it if no harm imo. If overbooked after the change the host can reschedule. That's how group booking was designed.
If number of spots pre-filled > remaining sports, and it is above it will default to 1. Will mention in video.
Expected behaviour.
As mentioned, if packages covers, booking is free, if not booking is fully paid. Just like existing logic for any other meeting type.
Expected behaviour.
Expected behaviour.
NOTED IMPROVEMENT: Only for recurring cases if package limit is exceeded do we show the error, in normal cases it shows the payment.
Recurring meeting edge cases.
Expected behaviour. Will mention in video.
We don't have such expiry. Expiry is based on usage date, not meeting date.
Expected behaviour.
Host is blocked from changing time if package is involved or bookings exist in group meeting. Edge case already handled.
Expected behaviour.
Not clear, no dependency on reserving spots feature.
No dependency on this feature.
Will not support in phase 1. Will have to cancel and rebook. Can include in phase 2. Will be complicate since we don't support editing the fields in the form when rescheduling. Will be dependent on that.
No dependency.
No dependency.
No dependency.
No dependency.
Will be expected behaviour.
Not an edge case because recurring meeting will be mapped to single client.
Not an edge case.
Discount code.
As discussed in PL call, same can be applied here. Discount code only applicable for 1st meeting, or 1 spot. For simplicity. Can take up based on request.
Future enhancements.
Option to just collect the emails for notification purposes.
Allow host to limit number of spots per person.
Feature Limitations (Phase 1)
Not Supported
-
Individual attendee details per spot
Cannot capture separate names/emails for each spot
Only booking client's information collected
May be added in future if explicitly requested
-
Partial cancellation/rescheduling
Must cancel/reschedule all spots together
Too complex for initial release
-
Partial no-shows
All-or-nothing no-show marking
Cannot mark subset of spots as no-show
-
Different spots for recurring sessions
Same number of spots booked for all recurring sessions
Example: Book 3 spots → All sessions have 3 spots
Cannot vary spots per session
-
Package partial coverage
Not handling cases where package only partially covers booking
Same limitation as current system