Fixed Departure Management

Overview

Fixed departures are the most structured departure model in Kaptio. Each departure is a named record tied to a specific date, with its own capacity, status, and booking eligibility. Operators create individual departure records — “Spring Expedition - Mar 15, 2027” or “Signature Voyage - Jun 8, 2027” — and manage each one through a defined lifecycle from unopened to open, on hold, or cancelled.

This model is purpose-built for premium, date-specific products: guided group tours, expedition cruises, signature voyages, and any product where travellers choose from a curated set of departure dates rather than picking any date on the calendar. Capacity is tracked at the departure level (total spaces minus booked), and operators can override individual components for a specific departure without affecting the base package.

When allotments have been set up for a package, departure dates can be auto-created from the allotment dates, and availability is controlled via the allotment table rather than a manual capacity number on the departure record.

Where Anyday packages offer maximum flexibility and Seasonal packages add time-window controls, Fixed departures give operators the tightest control. Every departure is a distinct entity with its own state, its own capacity, and optionally its own component configuration.

Prerequisites

Before creating a fixed departure package, ensure the following are in place:

Supplier services have been created for all services the package will include (accommodation, activities, transfers). See the Anyday Package Setup Guide for component fundamentals.
Supplier contracts are in place for the relevant travel dates and capacities.
Familiarity with Kaptio package concepts — if this is your first package, work through the Anyday Package Setup Guide first; it covers shared fundamentals in more detail.

Part 1: Understanding the Fixed Departure Model

The Departure Lifecycle

Every fixed departure moves through a defined set of statuses. These statuses control whether the departure appears in search results and whether it can accept bookings.

The four departure statuses are:

Status	Search Visibility	Booking Behavior
Unopened	Hidden from search results	Does not accept bookings
Open	Visible in search results	Accepts bookings (subject to eligibility)
On Hold	Visible in search results	Does not accept new bookings
Cancelled	Hidden from search results	Does not accept bookings

Transitions between statuses:

Unopened → Open: The departure is released for sale — it becomes visible in Package Search and bookable.
Open → On Hold: Triggered when capacity is exhausted or when the operator wants to temporarily pause bookings. The departure remains visible in search but cannot be booked.
Open → Cancelled: The departure is withdrawn before selling out.
On Hold → Open: The operator releases the hold (e.g., a cancellation frees spaces) and the departure accepts bookings again.
On Hold → Cancelled: A held departure is subsequently cancelled (rare; requires rebooking or refunding existing passengers).
Cancelled → Open: A previously cancelled departure is reinstated (e.g., demand materializes, supplier confirms availability).

Custom Departure Status values are supported. Operators can add values beyond the four defaults (e.g., “Call to Sell”) and replace the out-of-the-box flow with a custom one to map those values to the appropriate Booking Eligibility.

Status is distinct from booking eligibility, but the two are linked by a flow. When a user sets the Departure Status, an out-of-the-box flow automatically sets the Booking Eligibility field based on the status value. The default mapping is shown in the table below. This flow can be deactivated and replaced with a custom flow if needed.

Booking Eligibility States

Booking eligibility controls how customers interact with a departure that is visible in search. It is a separate dimension from status.

Eligibility	Behavior
Bookable	Customers can book directly. Standard flow.
Visible Only	The departure appears in search results but cannot be booked. Customers can see it but cannot add it to an itinerary. Used when the operator wants to advertise a departure without accepting bookings.
Inactive	The departure is hidden from search entirely, regardless of status. Used during setup or when temporarily pulling a departure from sale.

The out-of-the-box flow maps Departure Status to Booking Eligibility as follows:

Departure Status	Booking Eligibility (set by flow)
Unopened	Inactive
Open	Bookable
On Hold	Visible Only
Cancelled	Inactive

When to Use Fixed Departures

Choose the fixed departure model when:

The product has specific, named departure dates (not a range)
Capacity is managed at the departure level (30 seats, 12 cabins, etc.)
Each departure may need unique component configuration (different hotel for one date)
The product is premium, group-based, or expedition-style
Operators need per-departure yield management (adjusting status as seats fill)
Pricing may vary per departure (peak dates vs shoulder dates)

For a side-by-side comparison of all three departure types, see Three Ways to Sell Dates.

Part 2: Creating the Package

Step 1: Create the Package Record

Navigate to Packages in the Kaptio app and click New.

Set the following fields:

Field	Value	Notes
Record Type	Package	A Package that can contain multiple components including Bundles and Live components
Name	Descriptive package name	e.g., “Signature Voyage Collection”
Departure Type	Fixed	This cannot be changed after creation
Duration	Total trip duration in nights	e.g., 10
Categories	Package type category	e.g., “Expedition”, “Group Tour”

Screenshot of the New Package form with Departure Type set to Fixed, showing the required fields filled in

Important: The Departure Type field is locked after the package is saved. Double-check that “Fixed” is selected before saving.

After saving the package record, configure these additional settings:

Field	Description	Recommendation
Active	Makes the package available for search and booking	Leave unchecked until departures are configured
Visibility Setting	Controls which channels can see the package	Set per business requirements

Step 2: Build Components

Components in a fixed departure package work the same way as in any Kaptio package. Add the accommodation, activities, transfers, and other services that make up the product.

For detailed instructions on creating components, assigning services, and setting up component structure, see the Anyday Package Setup Guide.

Fixed Departure doesn’t necessarily mean fixed price. The Pricing Behaviour should be set according to the prices you want to set:

Standard — both cost and selling price from the associated supplier service will be used
Free Component — there is no cost or sell price to be added to the Itinerary (even if the supplier service has a valid cost or sell price for the booking date)
No Cost Rate — the cost rate from the supplier service will not be added to the Itinerary (but the sales rate will be)
No Sales Rate — the sell rate from the supplier service will not be added to the Itinerary (but the cost rate will be)

Fixed Departure Component Fields

When building components for a fixed departure package, there are three additional fields that control how components relate to departures:

Field	API Name	Behavior
Departure Mode	`DepartureMode__c`	Whether the component applies to all departures or only selected ones — see Step 6 for details
Primary Component	`PrimaryComponent__c`	Marks this as a primary component for departure variation highlighting
Is Controlling Departure Dates	`IsControllingDepartureDates__c`	This component is the source for creating and validating departure dates and allotment days

Build and validate the base component structure before creating departures. Departures inherit the package’s components, so getting the base right first avoids rework.

Part 3: Creating Named Departures

Step 3: Create a Departure Record

Departures can be created in two ways: manually without an allotment assigned, or by auto-creating departures from an allotment.

To manually create departures, from the package record, navigate to the Departures related list and click New.

Each departure record represents a single, bookable departure date:

Field	Description	Example
Name	Descriptive departure name	”Spring Expedition - Mar 15, 2027”
Departure Date	The travel start date	2027-03-15
Status	Current departure status	Open
Booking Eligibility	How customers can interact	Bookable

Enter a descriptive Name following your naming convention.
Set the Departure Date.
Save the record.

To auto-create departures using an allotment, select the component that has the Inventory Controlled Service using the field for Controlling Component — this should be your Package Item. Click the Autocreate from allotment button — this will remove any previously created departure dates and replace them with dates based on the allotment assigned to the component service.

Tip: “Autocreate from allotment” button not active? Make sure the field Allocation Type on the controlling Service is set to Booking. If you don’t see Allocation Type on the Detail tab of the Service, go to the Price Manager tab > Price Settings button. Change the value of the field called Duration to Booking. It’s the same field, just labelled differently on that screen.

Tip: To display actual available spaces in Package Search, check the Show Inventory box on the controlling component. Without this, search results will show the departure but won’t reflect real-time inventory availability.

Screenshot of the new departure form showing name, departure date, status, and booking eligibility fields.

Step 4: Set Initial Status and Eligibility

For a new departure, the recommended initial configuration depends on your workflow:

Workflow	Initial Status	Initial Eligibility	Rationale
Ready to sell immediately	Open	Bookable (set by flow)	Departure appears in search and accepts bookings
Soft launch, visible but not bookable	Open	Visible Only (manually overridden)	Departure is visible in search but customers cannot book
Placeholder for future planning	Unopened	Inactive (set by flow)	Record exists for planning; not yet customer-facing

Start with Unopened status if you are still configuring components or pricing. Change to Open only when the departure is fully validated — the flow will set eligibility to Bookable automatically.

Step 5: Configure Capacity

Total capacity defines the maximum number of passengers or spaces for the departure. As bookings are made, the system tracks:

Metric	Description
Total Capacity	The maximum set on the departure record
Booked	Number of confirmed passengers
Remaining	Total Capacity minus Booked

Capacity is set on the departure record using inventory setup. The capacity for each date updated automatically as bookings are confirmed or cancelled. Operators can also manually adjust capacity (e.g., if additional spaces become available through a supplier agreement) by adjusting the inventory table. Use this guide to understand how to set up and view capacity using inventory: Inventory Operations Guide.

Capacity is a departure-level concept, not a component-level concept. Unlike Anyday packages where availability is checked per service, fixed departures track capacity as a single number on the departure record.

Naming Conventions

Consistent naming makes departure management significantly easier at scale. Recommended patterns:

Pattern	Example	When to Use
`{Product} - {Month} {Day}, {Year}`	”Desert Explorer - Apr 12, 2027”	Standard, most common
`{Product} - {Season} {Year}`	”Signature Voyage - Spring 2027”	When exact day is secondary
`{Product} - {Code}`	”Arctic Expedition - AE-2027-03”	High-volume operators with internal codes

Avoid generic names like “Departure 1” or “March Trip.” The name should identify the departure at a glance in lists, reports, and customer-facing documents.

Part 4: Managing the Departure Lifecycle

Status Transitions

Operators manage departure status manually based on business conditions. To change status, open the departure record, update the Status field to the new value, and save.

Transition	When to Use	What Happens Automatically	Extra Steps
Unopened → Open	Departure is ready for sale	Booking Eligibility set to Bookable	—
Open → On Hold	Capacity exhausted or operator wants to pause bookings	Booking Eligibility set to Visible Only; departure stays visible in search but cannot be booked	—
On Hold → Open	Hold released — e.g., a cancellation freed spaces	Booking Eligibility set to Bookable	—
Open → Cancelled	Departure withdrawn — insufficient demand, supplier issue, or strategic decision	Booking Eligibility set to Inactive; departure hidden from search	If bookings exist, follow the rebooking or refund process
On Hold → Cancelled	Held departure subsequently cancelled (rare — e.g., force majeure)	Booking Eligibility set to Inactive; departure hidden from search	All existing bookings require resolution (rebooking or refund)
Cancelled → Open	Previously cancelled departure reinstated — e.g., demand materializes, supplier confirms availability	Booking Eligibility set to Bookable	Verify components and pricing are still valid for the departure date

Managing Visible Only Departures

Visible Only eligibility exists because operators need a bridge between “this departure exists” and “this departure is ready to book.” Two common reasons drive this:

Operational efficiency: Teams want to create and plan departures in the system without immediately putting them on sale. Visible Only lets the departure appear in search — so agents and customers know it’s coming — while the operator finishes configuration, pricing, or supplier confirmations behind the scenes.
Sell before everything is ready: Some operators want departures visible and even sellable before pricing is fully configured, because they have repeat guests who want to book far in advance. Historically, missing pricing caused errors that blocked this workflow. Visible Only provides a safe intermediate state: the departure is marketed and discoverable, but booking is held back until pricing is in place.

In short, Visible Only is the status that enables “market it / show it / let agents see it” without allowing booking until the departure is truly ready.

Typical Visible Only workflow:

Operator creates the departure record and sets status to Open with eligibility manually overridden to Visible Only.
The departure appears in search results — agents and customers can see it — but booking is not permitted.
The operator completes pricing, inventory, and component configuration.
When the departure is ready for sale, the operator sets eligibility to Bookable (or resets status so the flow sets it automatically).

Cancelling a Departure

When a departure is cancelled:

It is removed from search results.
Existing bookings are not automatically cancelled — operators must handle each booking individually.
The departure record remains in the system for audit and reporting purposes.

Before cancelling, check:

How many confirmed bookings exist on this departure?
Have affected customers been notified?
Are rebooking options available (alternative departure dates)?
Have refund or credit processes been initiated?

Reopening a Departure

A cancelled departure can be reopened by changing the status back to Open. This is appropriate when:

The reason for cancellation has been resolved (e.g., supplier reconfirmed)
Demand has materialized for a previously unviable date
A scheduling conflict was cleared

After reopening, verify that all components and pricing are still valid for the departure date.

Part 5: Component Overrides

When to Use Overrides

Component overrides allow operators to swap a component for a specific departure without changing the base package configuration. This is useful when:

A hotel is unavailable for one departure date and a substitute is needed
A special activity is added for a particular departure (e.g., a festival-timed event)
A supplier change affects only certain dates
A premium upgrade is offered for a single departure

The base package retains its standard component set. The override applies only to the targeted departure.

Step 6: Set the Departure Mode on the Component

Before creating overrides or assigning departures to a component, you must set the Departure Mode field on the component record. This field determines whether the component applies to every departure on the package or only to selected departures.

Open the component record within the package (e.g., “Boutique Hotel”).
Locate the Departure Mode field on the component detail page.
Set the value:

Departure Mode	Behavior
All (default)	The component is included in every departure on the package. No per-departure assignment is needed.
Selective	The component is only included in departures you explicitly assign. Use this when a component applies to some departures but not others.

Save the component record.

Set Departure Mode before creating departures or component overrides. If the mode is left as All, the component will automatically apply to every departure. Switch to Selective when you need per-departure control over which components are included.

Step 7: Create a Component Override

Navigate to the component record you want to override (e.g., “Boutique Hotel” within the package).
Open the Component Overrides related list on the component.
Click New.
Select the departure this override applies to (e.g., “Spring Expedition - Mar 15, 2027”).
Assign the replacement service (e.g., a different hotel’s supplier service).
Configure pricing for the replacement if it differs from the base.
Save.

Screenshot of the component record’s Component Overrides related list, showing the departure selection, replacement item assignment, and override pricing fields.

An override is created on the component and scoped to a specific departure. Other departures on the same package continue to use the base component’s default service. To change the component for all departures, edit the base package instead.

Override Pricing Impact

When a component is overridden, the pricing for that departure changes:

Scenario	Pricing Behavior
Override with same-price service	No change to departure total
Override with higher-price service	Departure total increases by the difference
Override with lower-price service	Departure total decreases by the difference
Override with explicit price set	The override price replaces the base component price entirely

If the override service has its own pricing configured, that pricing is used. If no pricing is set on the override, the system falls back to the base component price.

Always verify the departure total after applying an override. Price changes from overrides are not flagged automatically — operators must confirm the impact.

Part 6: Capacity Operations

Monitoring Capacity

For fixed departures, capacity tracking is straightforward:

Departure	Total	Booked	Remaining	Fill Rate
Spring Expedition - Mar 15	24	18	6	75%
Signature Voyage - Apr 22	16	16	0	100%
Desert Explorer - May 10	30	8	22	27%

Monitor capacity through:

Departure record: Shows booked count and remaining spaces.
Package-level reports: Aggregate view across all departures for a package.
Dashboard views: Custom list views filtered by status and fill rate.

Yield Management

Operators can adjust departure settings based on fill rate to maximize revenue and manage demand:

Fill Rate	Recommended Action
0–30%	Keep Bookable. Consider promotional pricing or marketing push.
30–70%	Standard operation. Monitor booking pace.
70–90%	Consider switching to Visible Only eligibility to manage final spaces carefully.
90–99%	Switch to Visible Only. Manually manage remaining spaces and re-enable Bookable as needed.
100%	Change status to On Hold.

Yield management for fixed departures is a manual process. Operators review fill rates and adjust status and eligibility based on business judgment.

Batch Departure Creation

When launching a new season, operators often need to create multiple departures at once (e.g., 12 monthly departures for a year-round product). While Kaptio does not have a built-in batch creation tool, common approaches include:

Data Loader: Use Salesforce Data Loader to insert multiple departure records from a CSV file.
Manual creation: Create each departure individually (suitable for products with fewer than 10 departures per season).
Flow or automation: Build a Salesforce Flow that generates departure records based on a date range and frequency.

For batch creation via Data Loader, prepare a CSV with columns:

Name, KaptioTravel__Package__c, KaptioTravel__DepartureDate__c, KaptioTravel__TotalCapacity__c, KaptioTravel__Status__c
"Spring Expedition - Mar 15, 2027", a0XXXXXXXXXXXXXX, 2027-03-15, 24, Open
"Spring Expedition - Apr 12, 2027", a0XXXXXXXXXXXXXX, 2027-04-12, 24, Open

When batch-creating departures, set eligibility to Inactive initially. Validate each departure before switching to Bookable.

Validation Checklist

Before activating a fixed departure package and its departures, verify each item:

Common Issues and Solutions

Issue	Likely Cause	Solution
Departure not appearing in search	Status is Cancelled, or eligibility is Inactive, or the package is not Active/Searchable	Check departure status, eligibility, and package-level Active and Searchable flags
Capacity shows incorrect remaining count	Bookings were cancelled but capacity was not recalculated	Verify booking records; recalculate if needed
Component override not applying	Override is linked to the wrong departure or the wrong base component	Open the override record and verify the departure lookup and base component lookup are correct
Wrong price on a departure with overrides	Override item has no pricing, so the system falls back to base pricing	Set explicit pricing on the override record
Customer can still book an On Hold departure	Status was not updated, or a race condition during booking	Verify the departure status field; consider using Visible Only eligibility as a buffer before On Hold
Departure appears but shows no price	Base component pricing is missing, or currency mismatch	Check component pricing and ensure the departure’s currency matches the package default
Batch-created departures all show Inactive	Batch creation used Inactive as the default (recommended)	Review and switch each departure to Bookable once validated

Object	API Name	Purpose
Package	`KaptioTravel__Package__c`	Parent record; holds departure type, settings
Departure	`KaptioTravel__Departure__c`	Named departure with date, capacity, status, eligibility
Component	`KaptioTravel__PackageComponent__c`	Bookable unit within the package
Service	`KaptioTravel__Item__c`	Supplier service assigned to a component
Component Override	`KaptioTravel__ComponentOverride__c`	Per-departure component replacement
Service Level	`KaptioTravel__ServiceLevel__c`	Quality tier (Standard, Premium, Luxury)