π Prerequisites
Features
What you get with this outcome
Every Departure, Under Control
Transform departure management from spreadsheet chaos into a real-time command center. From Bunnik's 80+ tour itineraries with combo departures to DuVine's flexible cycling tours with guide assignments, Kaptio's departure management gives you visibility across your entire calendar. Create departure series with templates, track bookings against capacity in real-time, manage yield thresholds for cancellation decisions, and clone entire seasons with a click. When a departure sells outβor needs to be cancelledβeveryone knows instantly.
Visual coming soon
departure-scheduling-diagram
Departure Scheduling & Templates
Create departure dates individually or in bulk using recurring patterns. Use departure templates to standardize setup across toursβensuring consistent capacity rules, pricing assignments, and operational defaults. Templates eliminate repetitive configuration and reduce human error.
- βBulk departure creation with date patterns
- βTemplates for consistent capacity and pricing setup
- βAuto-naming conventions (Tour Name + Date)
- βCopy departures across seasons with date shifting
Visual coming soon
capacity-tracking-diagram
Capacity & Inventory Tracking
Set maximum passenger limits per departure and track real-time availability as bookings come in. Configure singles limits, overbooking rules, and fallback statuses for sold-out scenarios. Link service-level inventory (rooms, cabins, seats) to departure capacity for coordinated availability control.
- βMax/min passenger limits per departure
- βSingles capacity with fallback rules
- βReal-time confirmed guest counts
- βService inventory linked to departure capacity
Visual coming soon
departure-status-diagram
Departure Status Lifecycle
Control departure visibility and bookability through status transitions. From 'Inactive β Hold Date' for new departures to 'Active' for sellable tours to 'Cancelled' when yield thresholds aren't met. Status changes trigger downstream actions: channel visibility, booking blocks, and operational workflows.
- βStatus workflow: Hold β Active β Confirmed β Closed
- βAutomatic visibility control by status
- βCancellation status with downstream handling
- βDays-prior-to-departure countdown tracking
Visual coming soon
yield-management-diagram
Yield Management & Monitoring
Track booking pace against viability thresholds. Bunnik uses minimum passenger counts to decide whether to confirm or cancel departures. DuVine monitors 'Total Confirmed Guests' updated daily. Build dashboards that surface at-risk departures before decisions become emergencies.
- βViability thresholds (min pax to confirm)
- βBooking pace dashboards and alerts
- βDays-prior countdown with decision triggers
- βAt-risk departure identification
Visual coming soon
Waitlist Management
Waitlist Management
When departures sell out, capture demand through waitlists. Guests waitlist at category level (e.g., cabin type) with priority sequencing. Automatic notification when space becomes available through cancellations. Optional auto-upgrade capability moves waitlisted guests to available higher categories.
- βCategory-level waitlist capture
- βPriority sequencing and management
- βAutomatic release notifications
- βOptional auto-upgrade on availability
User Journey
Step-by-step flow from start to finish
πΊοΈUser Journey Flow
Follow the steps from start to finish
Implementation Plan
How to implement this outcome
π Project Overview
Template Design
Week 1- β’ Define departure template standards
- β’ Configure capacity and singles rules
- β’ Set up status workflow and visibility rules
- β’ Create naming conventions
Departure Creation
Week 2-3- β’ Create departure series for initial season
- β’ Link service inventory to departures
- β’ Configure fallback statuses
- β’ Validate search availability
Monitoring & Yield
Week 4- β’ Build yield monitoring dashboards
- β’ Configure threshold alerts
- β’ Set up finalization workflows
- β’ Train revenue/ops teams
Resources
Configs, tools, and documentation to help you
βοΈ Golden Configs
Departure Series Configuration
Template for creating a seasonal departure series: date pattern, capacity defaults, pricing assignment, and status workflow rules
Yield Threshold Rules
Configuration for minimum passenger thresholds, decision timelines (e.g., 60/30/14 days prior), and cancellation handling
Annual Departure Cloning
Process for cloning departures from one season to the next with date shifting, pricing updates, and inventory refresh
Departure Management Concepts
Understanding how departures work in Kaptio is essential for effective tour operations.
Departure vs. Service Inventory
A common source of confusion: Package Departures and Service Inventory are separate but must be aligned.
| Concept | What It Controls | Example |
|---|---|---|
| Package Departure | When the tour runs and passenger capacity | βJapan Discovery - Mar 15, 2025β with 20 max pax |
| Service Inventory | When specific services are available | Hotel rooms available Mar 15-22 with 10 room allotment |
Critical: The service inventory dates must cover the package departure dates. If a hotel has no inventory for March 18, bookings for the March 15 departure will fail when that day is processed.
Departure Status Workflow
Departures follow a standard lifecycle:
Inactive β Hold Date β Active β Confirmed β Finalized β Closed
β
Cancelled
| Status | Bookable? | Visible in Search? | Use Case |
|---|---|---|---|
| Inactive β Hold Date | No | No | New departures awaiting review |
| Active | Yes | Yes | Open for booking |
| Confirmed | Yes | Yes | Minimum threshold met, tour will run |
| Finalized | No | No | Locked for operations |
| Cancelled | No | No | Below threshold or operational issue |
Capacity Types
Kaptio supports multiple capacity configurations:
- Package-Level Max Pax: Overall departure limit (e.g., 20 guests max)
- Min Pax Override: Departure-specific minimum (overrides package default)
- Singles Limit: Maximum single-occupancy passengers
- Service-Level Inventory: Room/cabin-specific capacity
Fallback Behavior: When capacity is reached, configure what happens:
- Block the package from search entirely
- Show as βWaitlistβ or βOn Requestβ
- Allow overbooking with warning
Departure Templates
Templates standardize departure setup across your tour catalog.
What Templates Control
| Setting | Description |
|---|---|
| Capacity Defaults | Max pax, singles limit, min pax |
| Pricing Assignment | Which rate plan applies |
| Status Rules | Initial status, auto-transition rules |
| Visibility | Channel access and search filters |
| Operational Defaults | Guide assignments, VOX requirements |
Template Best Practices
- One template per tour type: Classic Tours, In-Style Tours, Extensions
- Seasonal variants: Peak season vs. shoulder season templates
- Market-specific: If North America and Europe have different capacity rules
Yield Management
Proactive departure management requires monitoring booking pace against viability thresholds.
Key Metrics to Track
| Metric | Formula | Decision Trigger |
|---|---|---|
| Confirmed Guests | Live count of booked passengers | Compare to min pax threshold |
| Fill Rate | Confirmed / Max Pax Γ 100 | Target >75% for profitability |
| Days Prior | Tour Start Date - Today | Decision points at 60/30/14 days |
| Booking Pace | Bookings per week trend | Accelerating vs. decelerating |
Bunnikβs Yield Decision Points
From Bunnikβs Operations CSD:
- 60 days prior: First viability assessment
- 30 days prior: Final confirmation decision
- 14 days prior: Last-minute rescue campaigns
Cancellation Handling
When a departure must be cancelled:
- Update status to βCancelledβ
- Notify all booked passengers
- Offer alternatives (different departure, different tour)
- Process refunds or credits
- Update supplier bookings
Seasonal Cloning
Cloning departures for the next season is a major efficiency gain.
Cloning Process
- Select source season (e.g., 2025)
- Define target dates (shift by 52 weeks or specific dates)
- Choose what to copy:
- Departure dates (shifted)
- Capacity settings
- Pricing (with optional percentage adjustment)
- Status (reset to Hold for review)
- Review and activate
What Requires Manual Update
After cloning, these typically need attention:
- Pricing adjustments for inflation/market changes
- Supplier contract dates (verify inventory alignment)
- Special departure notes (festivals, seasonal events)
- Guide/hotel assignments
Integration with Operations
Departures bridge product management and operations.
Handoff to Operations
When a departure reaches βFinalizedβ status:
- Manifests can be generated
- Supplier confirmations are triggered
- Rooming lists are available
- Operational itineraries are locked
DuVine Example: Departure Service Assignments
From DuVineβs CSD, departures automatically create:
- 3 guide assignment records (status: Unassigned)
- Hotel assignment records per night
- Bike allocation records
This automation ensures operations has placeholder records to manage even before assignments are made.
Reporting & Dashboards
Essential views for departure management:
Product Manager Dashboard
- Departures by status (Active, Hold, Cancelled)
- Upcoming departures needing attention
- Capacity utilization by tour
Revenue Manager Dashboard
- Booking pace by departure
- At-risk departures (below min pax, approaching deadline)
- Fill rate trends
Operations Dashboard
- Finalized departures awaiting confirmation
- Supplier response status by departure
- Passenger data completeness
Common Pitfalls
Avoid these implementation mistakes
Don't publish departures until supplier contracts are confirmedβcancelling after bookings exist requires complex refund handling
Avoid misaligned inventory datesβservice inventory must exactly match departure dates or availability breaks
Don't skip departure templatesβmanually configuring each departure leads to inconsistency and errors
Missing fallback status configurationβif not set, sold-out inventory blocks the entire package from search
Forgetting to update Total Confirmed Guestsβif automated jobs fail, yield decisions are based on stale data
Not using days-prior thresholdsβwithout decision triggers, yielding becomes reactive instead of proactive