Seasonal Package Setup Guide

Start with Package Configuration — If you haven’t already set up your Package and configured its core settings, complete the Package Configuration Guide first. It covers creating Packages, assigning services, setting up price categories, and other fundamentals you’ll need before configuring seasonal rules. Come back to this guide once that’s done.

Overview

Seasonal packages are the middle-flexibility departure model in Kaptio. They sit between Anyday packages (any date, no restrictions) and Fixed departures (specific locked-in dates). With seasonal packages, availability is governed by date ranges and day-of-week rules.

This model is ideal for products that run within defined windows but don’t have single fixed departure dates. A coastal walking tour that operates every Monday and Thursday from April through October, with peak pricing in July and August, is a textbook seasonal package. The structure gives operators control over when bookings can land while still offering travellers flexibility within those windows.

The PackageSchedule object sits at the heart of the seasonal model — it controls when a departure can be booked and which days of the week are valid. Getting the schedule configuration right is the key to a well-configured seasonal package.

Prerequisites

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

Supplier services have been created for all services you plan to include (accommodation, activities, transfers). See the Supplier & Service Setup guide.
An understanding of the product’s seasonal calendar — which date ranges are valid for travel, which days of the week departures run, and how pricing varies across the year.
Familiarity with Kaptio package concepts — if this is your first package, work through the Package Configuration Guide first; it covers shared fundamentals in more detail.

Part 1: Understanding the Seasonal Model

How Seasonal Availability Works

Seasonal availability is defined through package seasons (the PackageSchedule object). Each package season specifies a start date, an end date, and a set of day-of-week rules. Together, these answer the question: On which dates can a traveller depart?

For example, a package season might say: “From 1 April 2026 to 31 October 2026, departures are available on Mondays, Wednesdays, and Fridays.” Any date that falls within that range and lands on one of those days is a valid departure date. Dates outside the range, or on other days of the week, will not appear in search results.

A single package can have multiple package seasons. A summer season might run April–October with three departure days per week, while a winter season runs November–March with only one departure day per week. Each package season is independent and can have its own day-of-week configuration.

How Seasonal Pricing Works

Pricing is defined through price seasons (the PriceSeason object). Each price season covers a date range and carries a label — typically High, Shoulder, or Low — that determines which rate tier applies when a traveller books a departure within that window.

Price seasons do not control availability. They only control cost. A departure on 15 July might be available (because a package season covers that date and it falls on a valid day), and it might be priced at the High season rate (because a price season tagged “High” covers July). The two systems work in parallel.

Component-level pricing is then configured per price season. A hotel room might cost $250/night in High season, $180/night in Shoulder, and $120/night in Low. When a booking falls on a departure date, Kaptio resolves the applicable price season and pulls the matching rate for each component.

When to Use Seasonal

Choose the seasonal departure type when:

The product runs within defined date windows (not year-round, or not every day)
Departures are restricted to specific days of the week
Pricing varies by time of year and you need structured season-based rates
You want more control than Anyday but don’t need the rigidity of Fixed departures
The product has a repeating annual pattern that can be expressed as package seasons

Seasonal vs Other Departure Types

Aspect	Anyday	Seasonal	Fixed
Availability	Any date	Date ranges + day-of-week rules	Specific locked dates
Pricing	Single rate or manual overrides	Season-based rate tiers	Per-departure pricing
Flexibility	Maximum	Medium	Minimum
Setup effort	Low	Medium	Higher (per departure)
Best for	Year-round, any-day products	Products with seasonal patterns	Group tours, set itineraries
Key objects	Package only	PackageSchedule + PriceSeason	Departure records
Inventory	Optional	Seasonal allotments	Per-departure allotments

Part 2: Creating the Package Record

Step 1: Create the Package

Navigate to the Packages tab in Kaptio and create a new package record.

Set Departure Type to Seasonal.
Enter the package name, description, and duration (number of nights).
Save the record.

Screenshot of the new package form with Departure Type set to Seasonal, showing the name and duration fields.

Setting the departure type to Seasonal unlocks the Package Seasons and Price Seasons related lists on the package record. These will not appear for Anyday or Fixed packages.

Step 2: Configure Package Settings

With the package record created, configure the core settings:

Field	Purpose	Recommended Value
Active	Controls whether the package appears in search	Leave unchecked until setup is complete
Visibility	Who can see the package	Set per business requirements
Searchable	Whether the package is indexed for search	Enable after validation
Min Pax / Max Pax	Passenger range	Set based on product constraints
Default Currency	Base pricing currency	Match your rate card currency

Save the record before proceeding to package seasons.

Part 3: Configuring Package Seasons

Understanding PackageSchedule

The PackageSchedule (KaptioTravel__PackageSchedule__c) object defines a booking window for a seasonal package. Each record represents one package season with:

Field	API Name	Description
Name	`Name`	Descriptive label (e.g., “Summer 2026”)
Package	`KaptioTravel__Package__c`	Lookup to the parent package
Start Date	`KaptioTravel__StartDate__c`	First valid departure date
End Date	`KaptioTravel__EndDate__c`	Last valid departure date
Monday	`KaptioTravel__Monday__c`	Checkbox — departures allowed on Mondays
Tuesday	`KaptioTravel__Tuesday__c`	Checkbox — departures allowed on Tuesdays
Wednesday	`KaptioTravel__Wednesday__c`	Checkbox — departures allowed on Wednesdays
Thursday	`KaptioTravel__Thursday__c`	Checkbox — departures allowed on Thursdays
Friday	`KaptioTravel__Friday__c`	Checkbox — departures allowed on Fridays
Saturday	`KaptioTravel__Saturday__c`	Checkbox — departures allowed on Saturdays
Sunday	`KaptioTravel__Sunday__c`	Checkbox — departures allowed on Sundays

A departure date is valid only if it falls within the start–end range and falls on a checked day of the week.

Step 3: Create time periods and day-of-week rules

From the package record, navigate to the Package Seasons (PackageSchedules) related list and click New.

Enter a descriptive Name — use a consistent naming convention like {Package} – {Season} {Year} (e.g., “Coastal Explorer – Summer 2026”).
Set the Start Date to the first valid departure date for this window.
Set the End Date to the last valid departure date.
Before you save, check the day-of-week boxes for each valid departure day (Monday through Sunday). For example, a tour that departs every Monday and Thursday would have only Monday and Thursday checked. A daily-departure product would have all seven days checked.
Save the Package Season record.

IMPORTANT

Add the day-of-week rules before you click Save. A Package Season saved with dates only (no days checked) has no valid departure dates.

Scenario	Days Checked
Weekly departures (Mon only)	Monday
Twice weekly	Monday, Thursday
Weekdays only	Monday–Friday
Daily	All seven days
Weekends only	Saturday, Sunday

Screenshot of the PackageSchedule creation form showing name, start date, end date, and day-of-week checkboxes populated for a summer season.

If no days are checked, the package season will produce zero valid departure dates. Always verify at least one day is selected.

Managing Multiple Package Seasons

A single seasonal package can have multiple package seasons. Common patterns include:

Consecutive seasons with different day-of-week rules:

Summer 2026 (Apr 1 – Sep 30): Monday, Wednesday, Friday
Winter 2026 (Oct 1 – Mar 31): Saturday only

Year-over-year periods:

2026 Season (Apr 1 – Oct 31, 2026)
2027 Season (Apr 1 – Oct 31, 2027)

Avoiding gaps: Ensure there are no unintended date gaps between consecutive package seasons. If Summer ends on 30 September and Winter starts on 1 October, there is no gap. If Summer ends on 30 September and Winter starts on 15 October, departures from 1–14 October will not be available.

Step 5: How price is calculated

For new implementations, use Dynamic selling price setup only. Fixed Selling Price is a legacy pattern and is not recommended — sell price should be derived from costs and markup or margin rules, not set as a fixed package sell rate.

With Dynamic setup, the package sell price is calculated from its components, not entered as a single package-level sell amount. Price seasons are date-range labels on the package: they tell the pricing engine which tier of per-component rates applies for the traveller’s departure date.

The calculation flow is:

The traveller selects a departure date.
Kaptio resolves which price season covers that date (for example High, Shoulder, or Low).
For each component, the engine resolves cost (and any intermediate pricing inputs) for that price season from the service and package configuration.
Sell amounts are derived from those values using your markup or margin rules; the package price is the roll-up of the component sell amounts.

You still create price season records and enter per-component rates for each season — but those rates feed the dynamic engine; they do not replace it. For a full field-by-field explanation of Dynamic cost and sell setup (and related behaviour), see Pricing Setup Fields.

Continuing Setup: Components, Pricing & More

With your package record and package seasons configured, the remaining setup steps — adding Components and Component Options, creating price seasons, and configuring per-component seasonal pricing — follow the same process used for all package types. See the Package Configuration Guide for complete instructions on these steps.

Validation Checklist

Before activating a seasonal package, verify each item:

Package record exists with departure type set to Seasonal
At least one package season (PackageSchedule) is created with valid start and end dates
Day-of-week rules are configured on every package season (at least one day checked)
No unintended gaps between consecutive package seasons
Components are added and assigned to the package (see Package Configuration Guide)
Activate the package and run a test search for a date within each package season — verify correct pricing
Search for a date outside all package seasons and verify it returns no results
Verify day-of-week filtering by searching for a valid date on a non-departure day

Common Issues and Solutions

Issue	Likely Cause	Solution
Departure dates not appearing in search	Package season does not cover the date, or no day-of-week rule is checked for that day	Verify the date falls within a PackageSchedule start–end range and the corresponding day checkbox is enabled

Object	API Name	Purpose
Package	`KaptioTravel__Package__c`	Parent record; holds departure type, settings
PackageSchedule	`KaptioTravel__PackageSchedule__c`	Package season with date range and day-of-week rules
PriceSeason	`KaptioTravel__PriceSeason__c`	Pricing tier with date range and season classification
Component	`KaptioTravel__PackageComponent__c`	Bookable unit within the package
Service	`KaptioTravel__Item__c`	Supplier service assigned to a component
InventorySeason	`KaptioTravel__InventorySeason__c`	Seasonal allotment configuration for inventory
AllotmentDay	`KaptioTravel__AllotmentDay__c`	Daily availability count for an inventory season
ServiceLevel	`KaptioTravel__ServiceLevel__c`	Quality tier (Standard, Premium, Luxury)