Service Level Configuration

Overview

Service Levels allow a single package to offer multiple pricing tiers — Standard Class, First Class, Premium Class, and so on — each with its own component-level pricing. When a guest books, they choose a tier and the system adjusts every component price accordingly.

This mechanism is foundational for operators who sell the same itinerary at different quality levels. Rather than duplicating packages for each tier, you create one package, assign service levels to it, and set per-tier prices on each component. The result is a single searchable product that fans out into multiple price points at booking time.

Service levels also have a critical integration point with the Search API. Packages that have service level assignments will only appear in search results when the service_level_ids parameter is included in the request. This is the single most common reason a package “disappears” from search after service levels are added.

Prerequisites

Before configuring service levels, ensure the following are in place:

Package created — the base package exists with at least one itinerary and component structure.
Components built — all components (accommodation, transport, activities, etc.) are created and linked to the package.
Pricing strategy defined — you know how many tiers you need and how pricing differs between them.
Search integration access — you can modify the front-end or API configuration that sends search requests.

Part 1: Understanding Service Levels

When to Use Service Levels

Use service levels when:

The same itinerary is sold at multiple quality tiers (e.g., Standard and Premium accommodation).
You want to enable upsell flows where guests can upgrade during booking.
Different component suppliers or room categories map to different price points.
Your front-end or booking engine supports tier selection.

Use standard pricing when:

There is only one quality level for the package.
The product is simple and upsell is not required.
You want to minimize configuration effort.

Common Service Level Patterns

Pattern	Example Tiers	What Changes Between Tiers
Accommodation quality	Standard Room, Superior Room, Suite	Hotel category or room type
Transport class	Economy, Business, First Class	Seat class on trains or flights
Experience level	Essential, Comfort, Luxury	Combination of accommodation, meals, and activities
Inclusion scope	Base, Plus, All-Inclusive	Which optional components are included

How Service Levels Affect Search

How service levels interact with search depends on whether you’re using Kaptio’s built-in Package Search or calling the API directly.

Searching Inside Kaptio (Package Search)

For users searching within Kaptio’s Package Search feature, service levels are handled automatically. When service levels exist in the org, a Service Levels filter appears on the search screen. All tiers are included by default, so packages with service levels show up in results straight away. Users can toggle individual tiers on or off to narrow results — no additional configuration is needed.

Searching via the API (e.g. Your Website)

If you’re calling the Search API directly — for example, from an ecommerce website — you must explicitly include the service_level_ids parameter in the request. Without it, packages that have service level assignments will not appear in results at all. This applies regardless of departure type — Anyday, Seasonal, or Fixed.

Critical: This is the single most common reason a package “disappears” from search after service levels are added. If a package was previously appearing and stops showing up, check that service_level_ids is included in every search request from your integration.

The API uses this parameter to determine which tier’s pricing to return. Without it, the API has no way to resolve which price to show, so it excludes the package entirely.

Part 2: Creating Service Level Records

Step 1: Create Service Level Records

Navigate to Kaptio Settings > SERVICE & PACKAGE > Service Levels.
Click New Service Level.
Enter the Name — this is the display name guests will see (e.g., “First Class”).
Enter the API Name — the internal identifier used in API calls and configuration.
Set the Order (sort position) — this integer controls the display sequence wherever tiers appear, including search results, the booking upsell flow, and list views. Lower numbers appear first. The tier with the lowest Order value is treated as the primary tier — it is shown first when a guest views the package and used for initial price display. For example, set your base tier to 1, the mid-range to 2, and premium to 3.
Save the record.
Repeat for each tier you need.

Field	Purpose	Example
`Name`	Display name shown to guests	”Standard Class”
`API_Name__c`	Internal identifier for API calls	”standard_class”
`Order__c`	Sort position (ascending)	1, 2, 3

Screenshot of a list view showing three service level records ordered by the Order field.

Part 3: Assigning Service Levels to Packages

Step 2: Set Service Level Mode and Select Service Levels on the Package

Once service level records exist, assign them directly on the Package record:

Open the Package record.
Set the Service Level Mode field — this tells Package Search how to behave for this package (e.g., whether to show tier selection, how to display pricing).
In the Service Levels field on the Package, select the relevant service levels (e.g., “Standard Class”, “First Class”).
Save the Package.

Screenshot of the Package record showing the Service Level Mode field and the Service Levels selection field with two tiers selected.

Assignment Rules

A package can have 2 to 5 service levels selected.
Every selected tier must have pricing configured on the Service Price Category. A Price Category without pricing will cause errors at booking time.
Removing a service level from the Package removes it from search results for that tier.
If you remove all service levels, the package reverts to standard pricing behavior and will appear in search without service_level_ids.

Part 4: Configuring Tier-Specific Pricing

Step 3: Assign Service Levels and Set Prices via Service Price Categories

The service level is assigned on the Component Option, but per-tier pricing is set on the Service Price Category, not the Component Option itself:

Open a Component Option within the package.
Assign the relevant Service Level to the Component Option.
Set the cost and sell price for that tier on the Service Price Category associated with the Component Option.
Repeat for each service level, creating a Component Option per tier where pricing differs.
Repeat for every component in the package.

Component Option	Standard Class	First Class	Premium Class
Accommodation – Night 1	$150 (Standard Room)	$250 (Deluxe Room)	$400 (Prestige Room)
Accommodation – Night 2	$150 (Standard Room)	$250 (Deluxe Room)	$400 (Prestige Room)
Transport – Day 1	$80	$80	$80
Activity – City Tour	$45	$45	$45
Package Total	$425	$625	$925

Screenshot of a Component Option showing the assigned service level and per-tier sell price.

Step 4: Verify Price Differences

After setting tier-specific pricing, verify that the total package price differs meaningfully between tiers:

Create a test itinerary using Costings / Builder and add the relevant Service Price Categories for each Service Level to compare tier totals.
Confirm that the price delta between tiers aligns with your pricing strategy.

Warning: If two tiers show the same total price, guests have no incentive to choose one over the other. Review your component pricing to ensure each tier has a clear value proposition.

Part 5: Search API Integration

How Search Finds Service Level Packages

The Search API uses the service_level_ids parameter to:

Filter — only return packages that have at least one of the specified service levels assigned.
Price — return the price for the specified service level tier.

Without this parameter, packages with service level assignments are excluded from results.

GET /api/v1/search/packages
  ?departure_date=2026-06-15
  &channel_id=abc123
  &service_level_ids=sl_standard,sl_first_class

The parameter accepts one or more service level IDs, comma-separated. The API returns results for each matching tier.

Step 5: Configure Search Parameters

Ensure that every search request from your front-end or integration includes service_level_ids:

Identify where search requests are constructed in your front-end or middleware.
Add the service_level_ids parameter with the appropriate tier IDs.
If you want to show all tiers, include all service level IDs.
If you want to default to one tier and let guests upgrade later, include only the default tier ID.

Scenario	Parameter Value	Result
Show all tiers	`service_level_ids=sl_standard,sl_first,sl_premium`	Returns package with pricing for each tier
Show default only	`service_level_ids=sl_standard`	Returns package with standard pricing only
No parameter	(omitted)	Package not returned

Testing Search Results

After configuring the parameter:

Execute a search request with service_level_ids included.
Verify the package appears in results.
Check that the returned price matches the tier’s expected total.
Remove service_level_ids and confirm the package no longer appears.
Test with each individual tier ID to verify per-tier pricing.

Screenshot of a search API response showing a package with service level pricing for two tiers.

Part 6: Upsell Flows

How Upsell Works at Booking Time

The upsell experience differs depending on the channel:

For agents using Package Search

Each service level appears as its own line in the search results. Agents compare the full prices side by side and advise guests on the available tier options.

For guests on a website or booking portal

The first tier (by sort order) is shown with its total price.
The guest sees the available tiers with price differences displayed (e.g., ”+$240 for First Class”).
The guest selects their preferred tier.
All component prices adjust to the selected tier.
The booking is created with the chosen service level recorded.

This flow enables natural upselling — guests see the upgrade options and their cost before committing.

Configuring Upsell Display

The upsell presentation depends on your front-end implementation, but the data contract from the API includes:

Field	Description
`service_level_id`	The tier’s unique identifier
`service_level_name`	Display name (e.g., “Premium Class”)
`total_price`	Package total for this tier
`price_delta`	Difference from the base tier’s price (lowest sort order)

Tip: Display tiers in ascending price order with the first tier (by sort order) pre-selected. Show the price delta rather than the absolute price for upgrade tiers — ”+$240” is more persuasive than showing the full price again.

Screenshot or wireframe showing a tier selection UI with three tiers, price deltas, and a selected default.

Validation Checklist

Before going live with service levels on a package, verify each item:

Common Issues and Solutions

Issue	Likely Cause	Solution
Package not appearing in search	`service_level_ids` parameter missing from search request	Add the parameter with the correct service level IDs
Package appears but with wrong price	Search request includes wrong service level ID	Verify the IDs match the assigned service levels
Tier shows $0 price delta	Component pricing is identical across tiers	Review and update component prices for each tier
”No pricing found” error at booking	A Service Price Category is missing pricing for the selected tier	Create pricing on the Service Price Category for the missing tier
Only one tier showing in upsell	Front-end only passing one `service_level_id`	Update front-end to pass all assigned tier IDs
Tier order is wrong	Order field values are incorrect or duplicated	Update the Order field on each Service Level record
Package disappeared after adding service levels	Service levels assigned but `service_level_ids` not added to search	Update all search integration points to include the parameter

Object	Purpose	Key Fields
`ServiceLevel__c`	Defines a pricing tier	`Name`, `API_Name__c`, `Order__c`
`Package__c`	The bookable product; Service Level Mode and selected Service Levels are set directly here	`Name`, `Status__c`, `DepartureType__c`, `ServiceLevelMode__c`, `ServiceLevels__c`
`ComponentOption__c`	Stores the service level assignment; per-tier pricing is set on the associated Service Price Category	`Component__c`, `ServiceLevel__c`