EP-009: Channel Manager & Distribution
| Field | Value |
|---|---|
| Epic ID | EP-009 |
| Epic Name | Channel Manager & Distribution |
| Owner | Distribution Module Lead |
| Created | 2026-03-05 |
| Last Updated | 2026-03-05 |
| Status | In Progress |
| Priority | P1 - High |
1. Business Objective
Automate OTA (Online Travel Agency) distribution to maximize occupancy while maintaining rate parity across all channels. Indian hotels currently spend 2-3 hours daily manually updating rates and availability across 5-10 OTA platforms (MakeMyTrip, Goibibo, Booking.com, Agoda, Expedia, etc.). Manual updates lead to rate parity violations (resulting in OTA penalties), overselling (leading to costly relocations), and missed revenue from stale inventory. A connected channel manager enables real-time two-way sync: pushing availability and rates to OTAs and pulling bookings back into the PMS automatically. For a 100-room hotel, this can increase occupancy by 8-15% and reduce distribution costs by eliminating manual effort.
2. Audience
| Role | Interaction |
|---|---|
| Revenue Manager | Rate strategy, channel performance analysis, rate parity monitoring |
| Reservations Manager | Booking management, OTA booking reconciliation, allocation management |
3. Scope
3.1 In Scope
- Support for 10 OTA channels: MakeMyTrip, Goibibo, Booking.com, Agoda, Expedia, OYO, Yatra, Cleartrip, TripAdvisor, Google Hotel Ads
- Room type and rate plan mapping (PMS room types to OTA room types)
- Two-way sync:
- Availability push (inventory updates to all connected channels)
- Rate push (rate updates with date-range and occupancy-based pricing)
- Booking pull (new reservations from OTAs into PMS)
- Sync monitoring dashboard (last sync time, success/failure, error logs)
- Rate parity alerts (detect and flag rate mismatches across channels)
- Booking source analytics (revenue by channel, commission tracking, ADR by source)
- GDS (Global Distribution System) connectivity (Amadeus, Sabre, Travelport)
- Stop-sell / close-out controls per channel
- Minimum stay and CTA/CTD (Close to Arrival / Close to Departure) restrictions
- Overbooking buffer configuration per channel
3.2 Out of Scope
- Direct booking engine (covered in EP-011)
- Revenue management / dynamic pricing strategy (covered in EP-007)
- Guest CRM / loyalty program (covered in EP-010)
- Payment gateway integration for OTA virtual cards (covered in EP-015)
4. Current Implementation Status
4.1 Backend (01-hmp-backend - Channel Service)
| Component | Status | Notes |
|---|---|---|
| Channel Connections | Built | CRUD for OTA connections with credentials storage |
| Room/Rate Mapping | Built | Map PMS room types and rate plans to OTA equivalents |
| Availability Push | Partial | Logic built, OTA API calls are mock/simulated |
| Rate Push | Partial | Logic built, OTA API calls are mock/simulated |
| Booking Pull | Partial | Logic built, returns simulated bookings |
| Sync Logging | Built | Detailed logs with timestamp, status, error message |
| Rate Parity Detection | Partial | UI comparison built, automated scraping not implemented |
| Booking Source Analytics | Partial | Basic aggregation, commission tracking not automated |
| GDS Connectivity | Not Started | Requires certified middleware (e.g., SiteMinder, RateGain) |
| Booking Modifications | Not Started | OTA modification/cancellation callbacks not handled |
| Stop-Sell Controls | Built | Per-channel, per-room-type close-out |
4.2 Dashboard (02-hmp-web-dashboard)
| Component | Status | Notes |
|---|---|---|
| Channel Status Grid | Built | All channels with connection status, last sync time |
| Sync Log Viewer | Built | Filterable by channel, date, status |
| Booking List by Channel | Built | OTA bookings with source attribution |
| Rate Push Interface | Built | Date-range rate updates with channel selection |
| Inventory Grid | Built | Availability by room type, date, channel |
| GDS Status Page | Built | Connection status (placeholder data) |
| Rate Parity Dashboard | Partial | Shows configured rates, no live OTA rate comparison |
| Commission Reports | Not Started | Revenue by channel without commission calculation |
5. Gap Analysis
| # | Gap | Impact | Effort | Priority |
|---|---|---|---|---|
| 1 | OTA API integrations are mock/simulated | Critical - core feature non-functional for production | XL | P0 |
| 2 | Rate parity is UI-only, no live comparison | High - cannot detect actual parity violations | L | P1 |
| 3 | Booking modifications from OTA not handled | High - cancellations/changes not reflected in PMS | M | P1 |
| 4 | GDS needs certified middleware | Medium - corporate/travel agent bookings missed | XL | P2 |
| 5 | Commission tracking not automated | Medium - manual P&L per channel | M | P2 |
| 6 | No retry/failover for failed syncs | High - stale rates on OTAs cause revenue loss | M | P1 |
| 7 | Overbooking buffer not configurable | Low - can be managed manually | S | P3 |
6. User Stories Summary
| Story ID | Title | Priority | Points | Sprint | Status |
|---|---|---|---|---|---|
| US-009-01 | Channel Connection Setup | P0 | 5 | 1 | Built |
| US-009-02 | Room Type & Rate Plan Mapping | P0 | 8 | 1 | Built |
| US-009-03 | Availability Push to OTAs | P0 | 13 | 2 | Partial |
| US-009-04 | Rate Push to OTAs | P0 | 13 | 2 | Partial |
| US-009-05 | Booking Pull from OTAs | P0 | 13 | 3 | Partial |
| US-009-06 | Sync Monitoring & Error Handling | P1 | 8 | 3 | Built |
| US-009-07 | Rate Parity Monitoring | P1 | 8 | 4 | Partial |
| US-009-08 | Booking Modification Handling | P1 | 8 | 4 | Not Started |
| US-009-09 | Stop-Sell & Restriction Controls | P1 | 5 | 3 | Built |
| US-009-10 | Booking Source Analytics | P2 | 5 | 5 | Partial |
| US-009-11 | Commission Tracking & Reports | P2 | 8 | 5 | Not Started |
| US-009-12 | GDS Connectivity | P2 | 13 | 6 | Not Started |
| US-009-13 | Overbooking Buffer Config | P3 | 3 | 6 | Not Started |
7. Dependencies
| Dependency | Type | Epic/Service | Status |
|---|---|---|---|
| Property service (room types) | Upstream | EP-002 / property | Available |
| Reservation service (booking creation) | Downstream | EP-003 / reservation | Available |
| Rate management (rate plans) | Upstream | EP-007 / revenue | Available |
| Auth service (RBAC roles) | Upstream | EP-001 / auth | Available |
| Notification service (sync alerts) | Downstream | EP-014 / notification | Partial |
| Kafka event bus | Infra | Docker / Kafka | Available |
| Redis (rate cache, sync locks) | Infra | Docker / Redis | Available |
| OTA API credentials (per property) | External | Hotel operations | Not Ready |
| GDS middleware (SiteMinder/RateGain) | External | Third-party | Not Ready |
8. Epic-Level Acceptance Criteria
- AC-EP-009-01: Availability updates are pushed to all connected OTA channels within 30 seconds of a PMS inventory change (check-in, check-out, new booking, cancellation).
- AC-EP-009-02: Rate updates are pushed to all mapped channels within 60 seconds of a rate change in the PMS.
- AC-EP-009-03: OTA bookings are automatically pulled and created as reservations in the PMS with correct room type, rate, guest details, and source attribution.
- AC-EP-009-04: Rate parity violations across channels are detected and alerted within 4 hours of occurrence.
- AC-EP-009-05: The sync monitoring dashboard shows real-time status of all channel connections with error details for failed syncs.
- AC-EP-009-06: Stop-sell controls take effect on OTA platforms within 60 seconds of activation.
9. KPIs
| KPI | Target | Measurement Method |
|---|---|---|
| Sync success rate | > 99.5% | Successful syncs / total syncs |
| Availability update latency | < 30 seconds | PMS change to OTA update time |
| Rate parity compliance | > 98% | Parity checks passed / total |
| OTA booking auto-creation rate | 100% | Auto-created / total OTA bookings |
| Channel revenue distribution | Balanced per strategy | Revenue by channel pie chart |
| Manual intervention rate | < 2% | Manual fixes / total sync events |
| Overbooking incidents | 0 | Overbooking relocations / month |
10. Detailed User Stories
US-009-01: Channel Connection Setup
As a Revenue Manager, I want to configure OTA channel connections with API credentials and enable/disable channels, So that the hotel's inventory is distributed to selected OTA platforms.
Priority: P0 | Points: 5 | Sprint: 1 | Status: Built
Implementation Status
Channel connection CRUD fully built. Stores API key, secret, hotel ID per OTA. Supports enable/disable toggle. Connection health check endpoint pings the OTA API (mock) and reports status. Dashboard UI shows all channels with connection status indicators.
Acceptance Criteria
Scenario: Connect to MakeMyTrip channel
Given the hotel has a MakeMyTrip extranet account
When the revenue manager adds a new channel connection:
| Field | Value |
| Channel | MakeMyTrip |
| Hotel ID | MMT-HTL-98765 |
| API Key | mmt_api_key_xxxxx |
| API Secret | mmt_secret_xxxxx |
And clicks "Test Connection"
Then the system validates the credentials against the MakeMyTrip API
And displays "Connection Successful" with the hotel name returned by MakeMyTrip
And the channel status changes to "CONNECTED"
Scenario: Disable channel temporarily
Given the Booking.com channel is connected and actively syncing
When the revenue manager disables the Booking.com channel
Then sync operations (availability push, rate push, booking pull) are paused
And the channel status changes to "DISABLED"
And existing bookings from Booking.com remain unaffected in the PMS
And the channel can be re-enabled without reconfiguring credentials
US-009-02: Room Type & Rate Plan Mapping
As a Revenue Manager, I want to map PMS room types and rate plans to their OTA equivalents, So that rates and availability are pushed to the correct OTA room/rate combinations.
Priority: P0 | Points: 8 | Sprint: 1 | Status: Built
Implementation Status
Mapping interface allows linking each PMS room type (e.g., "Deluxe King") to OTA-specific room type IDs. Rate plans (e.g., "Best Available Rate", "Breakfast Included") mapped to OTA rate plan codes. Supports one-to-many mapping (one PMS room type to multiple OTA room types across channels).
Acceptance Criteria
Scenario: Map room types to MakeMyTrip
Given the hotel has 4 PMS room types: Standard, Deluxe, Suite, Presidential
And MakeMyTrip has room type IDs: MMT-STD-01, MMT-DLX-01, MMT-STE-01, MMT-PRE-01
When the revenue manager maps each PMS room type to its MakeMyTrip equivalent
Then the mapping is saved and validated
And availability pushes for "Deluxe" in PMS will update "MMT-DLX-01" on MakeMyTrip
And the mapping is displayed in a grid: PMS Room Type | MMT Room Type | Status
Scenario: Map rate plans across channels
Given rate plan "EP" (European Plan - Room Only) exists in PMS at INR 5,000/night
When the revenue manager maps it to:
| Channel | OTA Rate Plan ID |
| MakeMyTrip | MMT-RP-EP-001 |
| Booking.com | BDC-RP-12345 |
| Expedia | EXP-RP-67890 |
Then rate pushes for "EP" will update all three OTA rate plans simultaneously
And the mapping grid shows all channels with their mapped rate plan IDs
US-009-03: Availability Push to OTAs
As a Revenue Manager, I want to have real-time availability updates pushed to all connected OTA channels whenever PMS inventory changes, So that OTAs always show accurate room availability and overbooking is prevented.
Priority: P0 | Points: 13 | Sprint: 2 | Status: Partial
Implementation Status
Availability push logic listens for Kafka events (reservation.created, reservation.cancelled, guest.checked_in, guest.checked_out) and recalculates available inventory per room type per date. The push to OTA APIs is currently mock/simulated. Needs real OTA API integration. Retry mechanism for failed pushes not implemented.
Acceptance Criteria
Scenario: Auto-push availability after new booking
Given the hotel has 10 "Deluxe King" rooms and 8 are sold for 2026-03-15
And all connected OTA channels show availability = 2
When a new booking for 1 "Deluxe King" is created for 2026-03-15
Then available inventory drops to 1
And an availability update of "1 room" is pushed to all channels within 30 seconds
And the sync log records each channel push with status (success/failure)
And the inventory grid in the dashboard updates to show 1 available
Scenario: Push availability after cancellation
Given 0 "Standard" rooms are available for 2026-03-20 (sold out)
And all channels show "Sold Out" for Standard rooms on that date
When a guest cancels their Standard room reservation for 2026-03-20
Then available inventory increases to 1
And an availability update of "1 room" is pushed to all channels
And previously closed channels for this room type reopen for sale
Scenario: Retry failed availability push
Given an availability update to Booking.com fails due to API timeout
When the retry mechanism activates
Then the push is retried up to 3 times with exponential backoff (5s, 15s, 45s)
And if all retries fail, the sync log records the failure with error details
And an alert is sent to the revenue manager via dashboard notification
And the system continues attempting in the next sync cycle
US-009-04: Rate Push to OTAs
As a Revenue Manager, I want to push rate updates to all connected OTA channels for specific date ranges and room types, So that pricing is consistent across all distribution channels.
Priority: P0 | Points: 13 | Sprint: 2 | Status: Partial
Implementation Status
Rate push interface allows selecting date range, room types, rate plans, and channels. Rate calculation includes base rate, applicable taxes, and any promotions. Push to OTA APIs is mock/simulated. Bulk rate update for 30/60/90-day windows supported.
Acceptance Criteria
Scenario: Push rate update for festive season
Given the revenue manager sets Diwali rates for October 15-25, 2026:
| Room Type | Rate Plan | Rate (INR) |
| Deluxe King | EP | 8,500 |
| Deluxe King | CP | 10,000 |
| Suite | EP | 15,000 |
| Suite | CP | 17,500 |
When the rates are pushed to all connected channels
Then each channel receives the rate update for the 11-day period
And rates are inclusive of taxes as per each OTA's requirement
And the sync log confirms successful push to each channel
And the rate parity dashboard shows consistent rates across all OTAs
Scenario: Push different rates per channel (BAR waiver)
Given the revenue manager wants to offer an exclusive 5% discount on MakeMyTrip
When the rate push is configured with:
| Channel | Deluxe EP Rate (INR) |
| MakeMyTrip | 4,750 (5% off) |
| Booking.com | 5,000 |
| Expedia | 5,000 |
Then each channel receives its specific rate
And the rate parity dashboard flags MakeMyTrip as having a different rate
And the revenue manager acknowledges the intentional parity exception
US-009-05: Booking Pull from OTAs
As a Reservations Manager, I want to have bookings from OTA channels automatically pulled into the PMS as reservations, So that all bookings are centralized regardless of source.
Priority: P0 | Points: 13 | Sprint: 3 | Status: Partial
Implementation Status
Booking pull logic polls OTA APIs (mock) at configurable intervals (default: every 5 minutes). Pulled bookings are validated against room type mappings and created as reservations with source attribution. Guest profile auto-created if not existing. OTA confirmation number stored for reference. Booking modification and cancellation callbacks not yet handled.
Acceptance Criteria
Scenario: Auto-pull new booking from Booking.com
Given a guest books a "Deluxe King" room via Booking.com for March 15-18, 2026
And the OTA booking ID is "BDC-RES-20260315-001"
When the booking pull runs
Then a new reservation is created in the PMS with:
| Field | Value |
| Source | BOOKING_COM |
| OTA Reference | BDC-RES-20260315-001 |
| Room Type | Deluxe King (mapped) |
| Check-in | 2026-03-15 |
| Check-out | 2026-03-18 |
| Guest Name | (from OTA booking data) |
| Rate | INR 5,000/night |
And the guest profile is created or matched to existing profile
And available inventory is decremented and pushed to all other channels
And a Kafka event "reservation.created" is published
Scenario: Handle duplicate booking detection
Given OTA booking "BDC-RES-20260315-001" has already been pulled into the PMS
When the next booking pull cycle runs and encounters the same booking
Then the system detects the duplicate by OTA reference number
And skips the booking without creating a duplicate reservation
And the sync log records "Booking already exists - skipped"
Scenario: Pull booking with unmapped room type
Given an OTA sends a booking for room type "MMT-PREM-01" which is not mapped
When the booking pull encounters the unmapped room type
Then the booking is flagged as "MAPPING_REQUIRED" in the sync log
And the reservations manager receives an alert to resolve the mapping
And the booking is held in a pending queue until mapping is configured
US-009-06: Sync Monitoring & Error Handling
As a Revenue Manager, I want to monitor the status of all channel sync operations in real-time, So that I can identify and resolve sync failures before they impact availability or rates on OTAs.
Priority: P1 | Points: 8 | Sprint: 3 | Status: Built
Implementation Status
Sync log captures every push/pull operation with timestamp, channel, operation type, status (SUCCESS/FAILED/PARTIAL), error message, and retry count. Dashboard sync monitoring page shows real-time status with filtering and search. Alert thresholds configurable (e.g., alert if sync fails 3+ times consecutively).
Acceptance Criteria
Scenario: View sync status dashboard
Given 10 channels are connected and syncing
When the revenue manager opens the sync monitoring dashboard
Then each channel shows:
| Column | Example Value |
| Channel Name | MakeMyTrip |
| Connection Status| CONNECTED |
| Last Avail Push | 2 min ago - SUCCESS |
| Last Rate Push | 15 min ago - SUCCESS |
| Last Booking Pull| 3 min ago - SUCCESS |
| Errors (24h) | 0 |
And channels with errors in the last 24 hours are highlighted in amber/red
And clicking a channel shows detailed sync history
Scenario: Alert on consecutive sync failures
Given Agoda availability push has failed 3 consecutive times
When the failure threshold (3) is reached
Then a critical alert is displayed on the dashboard
And the revenue manager is notified via push notification
And the sync log shows all 3 failures with error details (e.g., "API rate limit exceeded")
And a suggested action is shown ("Wait 15 minutes and retry, or check API credentials")
US-009-07: Rate Parity Monitoring
As a Revenue Manager, I want to monitor rate parity across all OTA channels and receive alerts when rates differ, So that I can maintain parity compliance and avoid OTA penalties.
Priority: P1 | Points: 8 | Sprint: 4 | Status: Partial
Implementation Status
Dashboard shows rates configured in PMS per channel side-by-side for comparison. Live OTA rate scraping/comparison is not implemented (would require web scraping or OTA reporting APIs). Currently, parity is assessed based on what was pushed vs what was configured -- not what is actually live on the OTA website.
Acceptance Criteria
Scenario: Detect rate parity violation
Given the PMS rate for "Deluxe King EP" on March 15 is INR 5,000
And rates were pushed to all channels at INR 5,000
When the rate parity check runs (comparing pushed rates across channels)
Then all channels show INR 5,000 - "In Parity"
And the parity status is green across the board
Scenario: Flag intentional rate difference
Given MakeMyTrip has a promotional rate of INR 4,500 (10% less than BAR)
When the rate parity check detects the difference
Then MakeMyTrip is flagged with "Rate Difference: -INR 500 (-10%)"
And the revenue manager can mark it as "Approved Exception" with reason
And the exception is excluded from parity violation counts
And the parity report shows the exception with approval details
Scenario: Rate parity report for management
Given the revenue manager generates a weekly parity report
Then the report shows:
| Metric | Value |
| Total parity checks | 1,400 |
| In-parity | 1,370 |
| Violations | 20 |
| Approved exceptions | 10 |
| Compliance rate | 98.6% |
And violations are listed by channel, room type, and date
US-009-08: Booking Modification Handling
As a Reservations Manager, I want to receive and process booking modifications and cancellations from OTAs automatically, So that the PMS stays in sync with OTA booking changes without manual intervention.
Priority: P1 | Points: 8 | Sprint: 4 | Status: Not Started
Implementation Status
Not started. Currently, if a guest modifies or cancels a booking on an OTA, the change must be manually updated in the PMS. Requires implementing OTA webhook/callback handlers for modification and cancellation notifications.
Acceptance Criteria
Scenario: Process OTA booking cancellation
Given reservation "RES-2026-0150" was created from Booking.com booking "BDC-RES-20260315-001"
When the guest cancels the booking on Booking.com
And the cancellation callback is received by the channel service
Then reservation "RES-2026-0150" is automatically cancelled in the PMS
And the cancellation policy is applied (per Booking.com policy, not hotel policy)
And available inventory is incremented and pushed to all channels
And the reservations manager is notified of the OTA cancellation
And a Kafka event "reservation.cancelled" is published with source "OTA_CANCELLATION"
Scenario: Process OTA date modification
Given a guest changes their Expedia booking from March 15-18 to March 20-23
When the modification callback is received
Then the PMS reservation dates are updated to March 20-23
And availability is adjusted for both the old and new date ranges
And rate differences (if any) are recalculated based on the new dates
And the modification is logged with old and new details
Scenario: Handle conflicting modification
Given an OTA modification changes room type to "Suite" but no suites are available
When the modification callback is received
Then the modification is flagged as "CONFLICT" in the sync log
And the reservations manager receives an urgent alert
And the OTA is not confirmed until the conflict is manually resolved
US-009-09: Stop-Sell & Restriction Controls
As a Revenue Manager, I want to close out room types on specific channels for specific dates and set booking restrictions (minimum stay, CTA/CTD), So that I can control distribution strategy and protect high-demand periods.
Priority: P1 | Points: 5 | Sprint: 3 | Status: Built
Implementation Status
Stop-sell (close-out) controls per channel, per room type, per date range. Restrictions include: minimum length of stay (MinLOS), maximum length of stay (MaxLOS), close to arrival (CTA), and close to departure (CTD). All pushed to OTA channels via the rate/availability push mechanism.
Acceptance Criteria
Scenario: Close-out Standard rooms on MakeMyTrip for Diwali
Given the revenue manager wants to sell only premium rooms during Diwali (Oct 15-25)
When they set a stop-sell on "Standard" room type for MakeMyTrip for Oct 15-25
Then MakeMyTrip receives a close-out update for Standard rooms on those dates
And Standard rooms remain available on other channels (Booking.com, Expedia)
And the inventory grid shows MakeMyTrip as "Closed" for Standard on those dates
Scenario: Set minimum stay restriction
Given New Year's Eve (December 31, 2026) is a high-demand date
When the revenue manager sets a MinLOS of 2 nights for all channels for Dec 31
Then OTAs only allow bookings that include Dec 31 if the stay is 2+ nights
And single-night bookings for Dec 31 are blocked on all channels
And the restriction is displayed in the inventory grid with a "Min 2N" indicator
US-009-10: Booking Source Analytics
As a Revenue Manager, I want to analyze booking performance by channel (revenue, ADR, bookings count, cancellation rate), So that I can optimize channel mix and distribution strategy.
Priority: P2 | Points: 5 | Sprint: 5 | Status: Partial
Implementation Status
Basic aggregation of bookings by source (channel) with count and revenue. ADR calculation per channel implemented. Cancellation rate per channel not tracked. Commission data not connected. Dashboard shows channel contribution pie chart and booking trend line.
Acceptance Criteria
Scenario: View channel performance dashboard
Given the revenue manager wants to analyze March 2026 channel performance
When they open the booking source analytics report
Then the report shows:
| Channel | Bookings | Revenue (INR) | ADR (INR) | Cancel Rate | Share |
| Direct | 120 | 18,00,000 | 5,000 | 5% | 30% |
| MakeMyTrip | 80 | 10,40,000 | 4,333 | 12% | 17% |
| Booking.com | 95 | 14,25,000 | 5,000 | 8% | 24% |
| Expedia | 45 | 5,85,000 | 4,333 | 15% | 10% |
| Others | 60 | 11,50,000 | 6,389 | 10% | 19% |
And a pie chart shows revenue distribution by channel
And a trend line shows bookings per channel over the last 12 months
Scenario: Compare channel cost-effectiveness
Given commission rates are configured per channel
When the revenue manager views the cost analysis
Then net revenue per channel (after commission) is displayed
And channels are ranked by net ADR (highest to lowest)
And recommendations are shown (e.g., "Increase allocation to Direct - highest net ADR")
US-009-11: Commission Tracking & Reports
As a Revenue Manager, I want to track commission paid to each OTA channel automatically, So that I can calculate true net revenue per channel and optimize distribution costs.
Priority: P2 | Points: 8 | Sprint: 5 | Status: Not Started
Implementation Status
Not started. Commission rates vary by channel (typically 15-25% for Indian OTAs, 15-18% for international OTAs). Currently, commission is calculated manually by the finance team. Needs: configurable commission rates per channel per room type, automated calculation against OTA bookings, monthly reconciliation report.
Acceptance Criteria
Scenario: Configure commission rates
Given the revenue manager sets up commission rates:
| Channel | Commission Rate |
| MakeMyTrip | 20% |
| Booking.com | 15% |
| Expedia | 18% |
| Goibibo | 22% |
When an OTA booking of INR 5,000/night (3 nights) comes from Booking.com
Then the commission is calculated as INR 15,000 x 15% = INR 2,250
And the net revenue is INR 12,750
And the commission is recorded against the reservation for reconciliation
Scenario: Generate monthly commission report
Given March 2026 has 320 OTA bookings across all channels
When the monthly commission report is generated
Then the report shows:
| Channel | Gross Revenue (INR) | Commission (INR) | Net Revenue (INR) |
| MakeMyTrip | 10,40,000 | 2,08,000 | 8,32,000 |
| Booking.com | 14,25,000 | 2,13,750 | 12,11,250 |
| Expedia | 5,85,000 | 1,05,300 | 4,79,700 |
And total commission payable is calculated with GST (18% on commission)
And the report is exportable to Excel for finance team reconciliation
US-009-12: GDS Connectivity
As a Revenue Manager, I want to connect the hotel to Global Distribution Systems (Amadeus, Sabre, Travelport), So that corporate travel agents and international travel management companies can book the hotel.
Priority: P2 | Points: 13 | Sprint: 6 | Status: Not Started
Implementation Status
Not started. GDS connectivity requires certified middleware (e.g., SiteMinder, RateGain, or direct certification with GDS providers). Dashboard has a placeholder GDS status page. Implementation requires: GDS property setup, room/rate mapping to GDS codes, availability/rate distribution, booking retrieval, and corporate rate (negotiated rate) support.
Acceptance Criteria
Scenario: Connect hotel to Amadeus GDS
Given the hotel has obtained an Amadeus property code (e.g., BOMDLX)
And a GDS middleware provider (SiteMinder) is configured
When the revenue manager activates GDS connectivity
Then hotel availability and rates are distributed to Amadeus
And travel agents worldwide can search and book the hotel via Amadeus terminals
And GDS bookings flow into the PMS as reservations with source "GDS_AMADEUS"
Scenario: Support corporate negotiated rates via GDS
Given "Infosys Corporate" has a negotiated rate of INR 4,000/night for Deluxe rooms
And the rate code "INF-CORP-2026" is set up in the GDS
When an Infosys travel manager books via their corporate travel tool (connected to Amadeus)
Then the booking is created at the negotiated rate of INR 4,000/night
And the reservation shows rate plan "Corporate - Infosys" in the PMS
And the standard rack rate is not exposed for this corporate booking
US-009-13: Overbooking Buffer Config
As a Revenue Manager, I want to configure an overbooking buffer per room type, So that I can strategically oversell to account for expected cancellations and no-shows while minimizing walk-outs.
Priority: P3 | Points: 3 | Sprint: 6 | Status: Not Started
Implementation Status
Not started. Many Indian hotels intentionally overbook by 5-10% to account for no-shows (which average 5-8% in domestic travel). The feature would allow configuring an overbooking percentage per room type, effectively inflating available inventory pushed to OTAs.
Acceptance Criteria
Scenario: Configure overbooking buffer
Given the hotel has 50 "Deluxe" rooms and historical no-show rate is 8%
When the revenue manager sets an overbooking buffer of 5% for Deluxe rooms
Then available inventory pushed to OTAs is calculated as: physical rooms + 5% buffer
And if 48 rooms are sold, OTAs show 4 available (instead of 2)
And the PMS dashboard clearly indicates "2 physical + 2 overbooked" availability
Scenario: Overbooking alert when buffer exceeded
Given the overbooking buffer is 5% (2 rooms for 50-room type)
When 52 bookings are confirmed (50 physical + 2 overbook)
And a 53rd booking comes in from an OTA
Then the system blocks the booking (buffer exhausted)
And sends a stop-sell to all channels for this room type
And alerts the reservations manager of the overbooking limit reached
Document generated: 2026-03-05 | Epic Owner: Distribution Module Lead | Review Cycle: Bi-weekly