🎨 Product Experience circle

πŸ“… Departure Command Center

Create departure schedules, manage capacity, track bookings against availability, and control the tour lifecycle from publication to finalization.

πŸ“
6
Steps
✨
5
Features
⏱️
3-4 weeks
Duration

πŸ”— 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

ACTORS:
πŸ“¦
Product Manager
πŸ“Š
Revenue Manager
πŸ‘€
Operations Coordinator
πŸ“‹

Implementation Plan

How to implement this outcome

πŸ“… Project Overview

3-4 weeks medium complexity
1

Template Design

Week 1
  • β€’ Define departure template standards
  • β€’ Configure capacity and singles rules
  • β€’ Set up status workflow and visibility rules
  • β€’ Create naming conventions
2

Departure Creation

Week 2-3
  • β€’ Create departure series for initial season
  • β€’ Link service inventory to departures
  • β€’ Configure fallback statuses
  • β€’ Validate search availability
3

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

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.

ConceptWhat It ControlsExample
Package DepartureWhen the tour runs and passenger capacity”Japan Discovery - Mar 15, 2025” with 20 max pax
Service InventoryWhen specific services are availableHotel 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
StatusBookable?Visible in Search?Use Case
Inactive – Hold DateNoNoNew departures awaiting review
ActiveYesYesOpen for booking
ConfirmedYesYesMinimum threshold met, tour will run
FinalizedNoNoLocked for operations
CancelledNoNoBelow threshold or operational issue

Capacity Types

Kaptio supports multiple capacity configurations:

  1. Package-Level Max Pax: Overall departure limit (e.g., 20 guests max)
  2. Min Pax Override: Departure-specific minimum (overrides package default)
  3. Singles Limit: Maximum single-occupancy passengers
  4. 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

SettingDescription
Capacity DefaultsMax pax, singles limit, min pax
Pricing AssignmentWhich rate plan applies
Status RulesInitial status, auto-transition rules
VisibilityChannel access and search filters
Operational DefaultsGuide assignments, VOX requirements

Template Best Practices

  1. One template per tour type: Classic Tours, In-Style Tours, Extensions
  2. Seasonal variants: Peak season vs. shoulder season templates
  3. 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

MetricFormulaDecision Trigger
Confirmed GuestsLive count of booked passengersCompare to min pax threshold
Fill RateConfirmed / Max Pax Γ— 100Target >75% for profitability
Days PriorTour Start Date - TodayDecision points at 60/30/14 days
Booking PaceBookings per week trendAccelerating 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:

  1. Update status to β€œCancelled”
  2. Notify all booked passengers
  3. Offer alternatives (different departure, different tour)
  4. Process refunds or credits
  5. Update supplier bookings

Seasonal Cloning

Cloning departures for the next season is a major efficiency gain.

Cloning Process

  1. Select source season (e.g., 2025)
  2. Define target dates (shift by 52 weeks or specific dates)
  3. Choose what to copy:
    • Departure dates (shifted)
    • Capacity settings
    • Pricing (with optional percentage adjustment)
    • Status (reset to Hold for review)
  4. 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