Setting Up Tour Packages

Deploy to Salesforce

Guided wizard • ~2-4 hours

Overview

The Gold Config is a set of pre-configured sample packages that demonstrate best-practice implementation patterns for tour products. Think of it as your reference implementation—when you’re wondering “how should I configure a multi-destination tour?” or “how do I handle flight pricing?”—the Gold Config shows exactly how it’s done.

What You’ll Learn

Topic	Description
Package Types	All 6 types and when to use each
Component Structure	How to build tour segments
Flight Placeholders	Air+Land pricing without inventory
Payment Schedules	Deposit and balance timing
Inventory Contracts	Making dates bookable
Multi-Destination	Combo and Linked patterns

Use the Gold Config as your template. Copy its patterns, adapt its structures, and customize for your specific tour products.

Understanding Package Types

Kaptio supports multiple package types to model your tour products. The key distinctions are:

How tours combine
Whether tours can sell independently
Whether flights are included

The Core Definitions

Type	Definition	Example
Principle Package	Standalone tour (single or multi-destination) that can be sold independently	Japan Discovery, South American Discovery
Combo Package	Two or more Principle Tours combined into one product	South Korea + Japan
Linked Package	One Principle Tour + one Sub Tour (both in same package)	Egypt (Principle) + Jordan (Sub)

Package Type Decision Matrix

Question	Land-Only	Air+Land	Combo	Linked
Can sell independently?	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Includes flights?	❌ No	✅ Yes	Either	Either
Combines multiple tours?	❌ No	❌ No	✅ Yes	✅ Yes
Tours share inventory?	N/A	N/A	❌ No	✅ Yes
Best for	Single destination	Package holidays	Multi-country	Extensions

How Package Type is Determined

Package behavior is controlled by three fields working together:

┌─────────────────────────────────────────────────────────────────┐
│  Package Type         IsCombo__c   IsLinked__c   HasFlights__c │
│  ───────────────────────────────────────────────────────────── │
│  Classic Land-Only      FALSE        FALSE         FALSE       │
│  Classic Air+Land       FALSE        FALSE         TRUE        │
│  Combo Land-Only        TRUE         FALSE         FALSE       │
│  Combo Air+Land         TRUE         FALSE         TRUE        │
│  Linked Parent          FALSE        TRUE          Either      │
│  Linked Combined        FALSE        TRUE          Either      │
└─────────────────────────────────────────────────────────────────┘

Classic Land-Only Package

This is your foundation product. Master this configuration before adding complexity with flights, combos, or linked tours.

When to Use

Single-destination tours without flights
Ground-only packages where guests arrange own air
Foundation for understanding all other types

Package Structure

A Classic Land-Only package consists of:

📦 Package (Principle)
├── 🏨 Main Tour Component (Required)
│   ├── Room Option: Twin/Double
│   ├── Room Option: Single
│   └── Room Option: Triple
├── 🏨 Pre-Tour Hotel (Optional)
│   └── Room Options...
├── 🏨 Post-Tour Hotel (Optional)
│   └── Room Options...
└── 🎫 Optional Activities
    └── Activity Options...

Key Configuration Fields

Field	Value	Purpose
`IsCombo__c`	FALSE	Not a combo package
`IsLinked__c`	FALSE	Not a linked package
`HasFlights__c`	FALSE	No flight components
`ServiceLevelMode__c`	Standard	Bed type cascades to all components
`MinPax__c`	2	Minimum guests per departure
`MaxPax__c`	16	Maximum guests per departure

Component Configuration

The Main Tour component is always required and marked as:

IsMandatory__c = TRUE
IsPrimary__c = TRUE

Pre/Post hotels and activities are optional:

IsMandatory__c = FALSE
IsPrimary__c = FALSE

Teaching Point: Service Level Mode

When ServiceLevelMode__c = “Standard”:

Guest selects bed type on Main Tour component
Selection cascades to all other components
Ensures consistent room configuration throughout trip
No auto-fallback if selected type unavailable

Classic Air+Land Package

The Customer Request: “Can you include flights?”

Air+Land packages add flight pricing to your land-only tours without managing actual flight inventory.

How It Works

Kaptio uses flight placeholders—components that represent flight pricing without actual inventory. This enables:

Package pricing that includes air
Separate commission structures for air vs land
Flexibility for guests to upgrade or decline flights

The Two-Component Flight Model

📦 Package (Air+Land)
├── ✈️ Return Flight (Subsidized) - NotMandatoryHidden
│   └── Economy class included in package price
├── ✈️ Flight Upgrade (Optional) - NotMandatoryHidden  
│   ├── Premium Economy (+$500)
│   └── Business Class (+$1,500)
├── 🏨 Main Tour Component (Required)
│   └── Room Options...
└── 🏨 Pre/Post Hotels (Optional)

Why Two Flight Components?

Component	Purpose	Visibility
Return Flight	Base air included in package price	Hidden (auto-selected)
Flight Upgrade	Optional upgrades for additional cost	Shown to guest

This model enables:

Clean pricing: Package price includes economy air
Upsell opportunity: Guests can upgrade class
Commission separation: Air earns different commission than land

Key Configuration Differences

Field	Land-Only	Air+Land
`HasFlights__c`	FALSE	TRUE
Flight Component `IsMandatory__c`	N/A	FALSE
Flight Component `MandatoryMode__c`	N/A	NotMandatoryHidden

Teaching Point: NotMandatoryHidden

Flight components use MandatoryMode__c = “NotMandatoryHidden” because:

They don’t require inventory checking
They’re auto-included in package price
Guests don’t need to “select” the base flight

Combo Packages: Multi-Destination Tours

The Business Decision: Sell multiple destinations as one product.

When to Use Combo

Multi-country itineraries (Japan + South Korea)
Regional combinations (Peru + Bolivia)
Themed collections (Grand Tour of Europe)

How Combo Works

A Combo package references multiple Principle packages:

📦 Combo Package: "Japan & Korea Discovery"
├── 📦 Japan Discovery (Principle Package)
│   ├── 🏨 Tokyo Hotels
│   ├── 🏨 Kyoto Hotels
│   └── 🎫 Japan Activities
└── 📦 South Korea Explorer (Principle Package)
    ├── 🏨 Seoul Hotels
    ├── 🏨 Busan Hotels
    └── 🎫 Korea Activities

Key Characteristics

Aspect	Combo Behavior
Inventory	Each Principle has separate inventory
Pricing	Combined from both Principles
Departures	Must align across both tours
Booking	Single booking, multiple tour segments

Configuration Fields

Field	Value	Purpose
`IsCombo__c`	TRUE	Marks as combo package
`IsLinked__c`	FALSE	Not using linked model
`ComboPackages__c`	[Package IDs]	References to Principle packages

Combo vs Selling Separately

Scenario	Use Combo	Sell Separately
Always sold together	✅
Shared departure dates	✅
Single booking experience	✅
Can book just one		✅
Different departure dates		✅
Separate payment schedules		✅

Linked Packages: Principle + Sub Tour

The Linked Package Model: Pair a main tour with optional extensions.

When to Use Linked

Pre/post tour extensions (Egypt + Jordan extension)
Optional add-on tours
Modular tour building

How Linked Works

📦 Linked Package: "Egypt with Jordan Extension"
├── 📦 Egypt Discovery (Principle)
│   ├── 🏨 Cairo Hotels
│   ├── 🏨 Luxor Hotels
│   └── 🎫 Egypt Activities
└── 📦 Jordan Extension (Sub Tour)
    ├── 🏨 Petra Hotels
    ├── 🏨 Amman Hotels
    └── 🎫 Jordan Activities

Key Differences from Combo

Aspect	Combo	Linked
Relationship	Equal partners	Parent + Child
Inventory	Separate	Can share
Sub tour alone	N/A	Cannot sell alone
Pricing	Combined	Principle + Extension

Configuration Fields

Field	Value	Purpose
`IsCombo__c`	FALSE	Not a combo
`IsLinked__c`	TRUE	Using linked model
`LinkedParentPackage__c`	[Package ID]	Reference to Principle
`IsSubTour__c`	TRUE (on sub)	Marks as extension

Revenue Management with Extensions

Extensions enable:

Incremental revenue from add-on sales
Inventory optimization across related tours
Flexible packaging for different guest preferences

Payment Schedules: When Do Customers Pay?

Most tour operators don’t require full payment at booking. You want deposits to secure bookings, then collect balance closer to departure.

How Payment Schedules Work

Payment schedules are template-based:

Configuration contains rules (deposit %, days before departure)
Assignment links configuration to packages/channels
Booking generates actual payment schedule from rules

Typical Structure

┌─────────────────────────────────────────────────────────────────┐
│  Payment Schedule: "Standard Tour Deposit"                      │
│  ───────────────────────────────────────────────────────────── │
│  At Booking:        25% deposit                                 │
│  90 days before:    50% (total 75%)                            │
│  30 days before:    25% (total 100%)                           │
└─────────────────────────────────────────────────────────────────┘

Assignment Hierarchy

Payment schedules are assigned with priority:

Package + Channel (most specific)
Package only
Channel only
Default (least specific)

Configuration Objects

Object	Purpose
`PaymentScheduleConfiguration__c`	The schedule template
`PaymentScheduleRule__c`	Individual payment rules
`PaymentScheduleAssignment__c`	Links to packages/channels

Inventory Contracts: Making Dates Bookable

Departures aren’t created manually—they’re generated from inventory contracts.

How It Works

┌─────────────────────────────────────────────────────────────────┐
│  Inventory Contract: "Tokyo Hotels Q1 2026"                     │
│  ───────────────────────────────────────────────────────────── │
│  Supplier: Tokyo Hotel Group                                    │
│  Period: Jan 1 - Mar 31, 2026                                  │
│  Rooms: 20 per night                                           │
│  ───────────────────────────────────────────────────────────── │
│  → Generates departures for each valid start date              │
│  → Tracks available capacity in real-time                      │
└─────────────────────────────────────────────────────────────────┘

Key Concepts

Concept	Description
Allotment	Contracted inventory from supplier
Release Tier	When unsold inventory returns to supplier
Departure	Bookable date generated from allotment
Capacity	Real-time tracking of available spots

Release Tiers: Minimize Risk

Release tiers automatically return unsold inventory:

┌─────────────────────────────────────────────────────────────────┐
│  Release Tier 1: 90 days before → Release 50% unsold           │
│  Release Tier 2: 60 days before → Release 25% unsold           │
│  Release Tier 3: 30 days before → Release remaining            │
└─────────────────────────────────────────────────────────────────┘

This protects you from holding inventory you can’t sell while maintaining availability for bookings.

Cancellation Policies

Cancellation policies define what happens when guests cancel their booking.

Structure

Like payment schedules, cancellation policies are template-based:

Object	Purpose
`CancellationPolicy__c`	Policy definition
`CancellationRule__c`	Fee rules by timeframe
`CancellationAssignment__c`	Links to packages/channels

Typical Policy

┌─────────────────────────────────────────────────────────────────┐
│  Cancellation Policy: "Standard Tour Policy"                    │
│  ───────────────────────────────────────────────────────────── │
│  90+ days before:   Full refund (minus admin fee)              │
│  60-89 days:        25% cancellation fee                       │
│  30-59 days:        50% cancellation fee                       │
│  0-29 days:         100% cancellation fee (no refund)          │
└─────────────────────────────────────────────────────────────────┘

Channel-Specific Policies

Different channels may have different policies:

Direct: Standard policy
Travel Agent: May have more flexible terms
Group Charter: Custom negotiated terms

Common Questions

Should I create separate packages for Land-Only and Air+Land?

Yes. While you could use a single package with optional flights, separate packages provide:

Cleaner pricing display
Simpler inventory management
Easier reporting by product type

Can I change minimum capacity after departures exist?

Yes, but carefully. Existing departures keep their original capacity. New departures use the updated minimum. Consider the impact on already-booked departures.

How do I handle single supplements?

Single supplements are configured at the Component Option level:

Create a “Single Room” option
Set the supplement price
System calculates automatically when guest selects single

What if inventory is less than my maximum capacity?

The system uses the lower of:

Package maximum capacity
Available inventory from contracts

If you have 16-pax max but only 10 rooms contracted, departures show 10 available.

Can I offer the same tour style in different regions?

Yes. Create separate packages for each region:

Japan Discovery (Asia)
Italy Discovery (Europe)
Peru Discovery (South America)

Each has its own inventory, pricing, and departures while sharing the “Discovery” brand concept.

Key Takeaways

1. Package Type = Your Product Strategy

The three classification fields (IsCombo__c, IsLinked__c, HasFlights__c) determine how your product behaves. Choose based on your business model, not technical convenience.

2. Flight Placeholders Solve Real Problems

The two-component flight model (subsidized + upgrade) enables air+land pricing without inventory complexity. It’s pricing, not operations.

3. Departures Are Generated, Not Manual

Inventory contracts drive departure availability. Focus on contracting the right allotments—departures follow automatically.

4. Payment & Cancellation Are Template-Based

Create configurations once, assign to many packages. The system generates actual schedules at booking time.

5. Start Simple, Add Complexity as Needed

Master Classic Land-Only first. Add flights when needed. Use Combo/Linked only when your product truly requires it.

Next Steps

Review Gold Config packages in your sandbox
Copy a Land-Only package as your template
Customize for your first tour product
Test the booking flow end-to-end
Add complexity (flights, combos) only when needed

🚢 Foundation: Cruise Operator Foundation - Channels, brands, commission groups
🧭 Packages: Expedition Cruise Collection - Sample cruise packages
🤝 B2B: B2B Trade Partner Setup - Agency and commission configuration

Setting Up Tour Packages

Deploy to Salesforce

Overview

What You’ll Learn

Understanding Package Types

The Core Definitions

Package Type Decision Matrix

How Package Type is Determined

Classic Land-Only Package

When to Use

Package Structure

Key Configuration Fields

Component Configuration

Teaching Point: Service Level Mode

Classic Air+Land Package

How It Works

The Two-Component Flight Model

Why Two Flight Components?

Key Configuration Differences

Teaching Point: NotMandatoryHidden

Combo Packages: Multi-Destination Tours

When to Use Combo

How Combo Works

Key Characteristics

Configuration Fields

Combo vs Selling Separately

Linked Packages: Principle + Sub Tour

When to Use Linked

How Linked Works

Key Differences from Combo

Configuration Fields

Revenue Management with Extensions

Payment Schedules: When Do Customers Pay?

How Payment Schedules Work

Typical Structure

Assignment Hierarchy

Configuration Objects

Inventory Contracts: Making Dates Bookable

How It Works

Key Concepts

Release Tiers: Minimize Risk

Cancellation Policies

Structure

Typical Policy

Channel-Specific Policies

Common Questions

Should I create separate packages for Land-Only and Air+Land?

Can I change minimum capacity after departures exist?

How do I handle single supplements?

What if inventory is less than my maximum capacity?

Can I offer the same tour style in different regions?

Key Takeaways

1. Package Type = Your Product Strategy

2. Flight Placeholders Solve Real Problems

3. Departures Are Generated, Not Manual

4. Payment & Cancellation Are Template-Based

5. Start Simple, Add Complexity as Needed

Next Steps

Related Resources