Overview
Pre/post stays — sometimes called extensions — allow guests to add extra nights before or after the main tour. They are a straightforward way to increase booking value while giving travellers flexibility to arrive early or linger after the tour ends.
A PreNight stay is allocated before the tour start date. If the tour begins on 10 March, a 2-night pre-stay occupies 8–9 March. A PostNight stay is allocated after the tour end date. If the tour ends on 20 March, a 2-night post-stay occupies 20–21 March. Both are configured as accommodation components on the package, distinguished by a single field: Allocation Behaviour.
In the booking wizard, pre/post stays appear as optional add-ons. The guest selects how many extra nights they want, sees per-night pricing, and the selected nights are appended to the itinerary. Inventory for extensions can be managed in three ways: drawn from the same allotment pool as the main tour accommodation, allocated from a separate dedicated contract for the extension hotel, or handled on request where the operator checks availability with the supplier before confirming the extension for the guest.
This guide covers how to configure pre/post stay components, set per-night pricing, manage shared inventory, and offer multiple extension options on a single package.
Prerequisites
Before configuring pre/post stays, ensure the following are in place:
- A package with at least one accommodation component already configured. The pre/post stay extends an existing package — it is not a standalone product.
- Supplier services created for the extension accommodation, with active inventory seasons and allotment days covering the pre/post dates. See the Supplier & Service Setup guide.
- Allotment days generated for the extension date range. Pre-stay dates fall before the tour start; post-stay dates fall after the tour end. If allotment days do not cover those dates, the extension will not be bookable.
- Familiarity with the inventory chain (Package → Component → Service → Inventory Season → Allotment Day). See the Inventory Operations Guide for details.
- Programs Manager, Delivery Consultant, or Admin access in Kaptio.
Part 1: Understanding Pre/Post Stay
How Allocation Works
The Allocation Behaviour field on a component controls how dates are calculated relative to the tour. There are three possible values:
| Allocation Behaviour | Date Calculation | Example (Tour: Mar 10–20, 2 Nights) |
|---|---|---|
| Standard (default) | Dates fall within the tour date range | Mar 10–11 (nights 1–2 of the tour) |
| PreNight | Dates are placed before the tour start date, counting backwards | Mar 8–9 (2 nights before Mar 10) |
| PostNight | Dates are placed after the tour end date, counting forwards | Mar 20–21 (2 nights after Mar 20) |
The date arithmetic is automatic. When a guest selects a 2-night pre-stay on a tour departing 10 March, the system allocates 8 March and 9 March without any manual date entry. The number of nights determines how far before (or after) the tour dates the extension reaches.
PreNight dates count backwards from the tour start date. The night immediately before the tour start is the last pre-stay night, not the first. For a 3-night pre-stay on a tour starting 10 March, the occupied dates are 7, 8, and 9 March.
Pre/Post Stay in the Booking Wizard
From the traveller’s perspective, pre/post stays appear during the booking flow as optional selections:
- The guest searches for and selects a package.
- During the booking wizard, an Add Pre-Tour Stay section appears (if a PreNight component exists on the package).
- The guest selects the number of nights — for example, 1, 2, or 3.
- Per-night pricing is displayed for the selected duration.
- An Add Post-Tour Stay section follows the same pattern (if a PostNight component exists).
- Selected extensions are added to the itinerary summary before checkout.
Screenshot of the booking wizard showing the “Add Pre-Tour Stay” section with a dropdown for number of nights (1, 2, 3) and per-night pricing displayed next to each option
The guest is not required to select any extension. Pre/post stays are always optional — the Selection Type on the component must be set to Optional for the extension to appear in the booking wizard. If extra nights are truly mandatory, they belong in the core itinerary as standard accommodation, not as a pre/post stay add-on.
Revenue Impact
Pre/post stays are one of the simplest revenue levers on a package. They require minimal additional configuration — typically one component and one supplier service — yet they add meaningful per-booking revenue.
Consider a 7-night tour priced at $3,500 per person. A 2-night pre-stay at a gateway city hotel at $180/night adds $360 per person. Across 200 annual bookings with a 40% uptake rate, that is $28,800 in incremental revenue from a single optional component.
Extensions also improve the guest experience. Travellers arriving a day early can recover from jet lag, explore the departure city, and start the tour rested. Post-stays give travellers a buffer before flights home. Both reduce the operational risk of missed connections affecting the tour group.
Part 2: Configuring Pre/Post Stay Components
Step 1: Create the Pre/Post Stay Component
If the extension uses the same hotel as the first or last night of the main tour, you may already have a suitable supplier service. If the extension uses a different hotel (e.g., a gateway city hotel that is not part of the core itinerary), create a new service first via the Supplier & Service Setup guide.
From the package record:
- Navigate to the Components related list.
- Click New to create a new component.
- Set the Component Type to the appropriate accommodation type.
- Enter a descriptive name — for example, “Pre-Tour: Gateway Hotel” or “Post-Tour: Departure City Hotel”.
- Set the Allocation Behaviour field to PreNight (for a pre-tour stay) or PostNight (for a post-tour stay). This is the field that distinguishes a pre/post stay from a regular accommodation component.
- Set the Selection Type field to Optional. This is required — it makes the extension appear as a guest-selectable add-on in the Pre Stay or Post Stay tab of the booking wizard.
- Assign supplier services to the component. For each component option:
- Select New Component Option
- Search for and select the Supplier
- Search for and select the Service
- Select the required Price Categories as well as Add-ons and Meal Plans if needed
- If using Service Levels, assign the Price Category to the appropriate level
- Save the record.
Screenshot of the new component form with the name set to “Pre-Tour: Gateway Hotel”, component type set to Accommodation, Allocation Behaviour set to PreNight, and Selection Type set to Optional
Allocation Behaviour controls how dates are calculated relative to the tour:
| If the extension is… | Set Allocation Behaviour to… |
|---|---|
| Before the tour (arrive early) | PreNight |
| After the tour (depart later) | PostNight |
| During the tour (standard night) | Leave as Standard (default) |
If the Allocation Behaviour field is left as Standard, the component’s dates will fall within the tour date range, not before or after it. Double-check this field if your extension dates are appearing on the wrong days.
Selection Type determines how the component behaves in the booking wizard:
| Selection Type Value | Behaviour | Use for Pre/Post Stay? |
|---|---|---|
| Optional | Guest chooses whether to add the extension in the booking wizard | Yes — this is the correct setting |
| Pre-Selected Refundable | Included automatically in the package, guest can remove | No — if nights are included by default, configure them as standard accommodation |
| Pre-Selected Non-Refundable | Included automatically, cannot be removed | No — same as above |
Pre/post stay components must be Optional. A mandatory extension would be included automatically in the package price, which defeats the purpose of offering it as an add-on. If extra nights are truly required, they belong in the core itinerary as standard accommodation.
Step 2: Configure Per-Night Pricing
Pre/post stays are priced per night. Pricing is configured on the Service — the same place all Kaptio pricing is managed — not on the component itself. The component simply links to a supplier service that already has rates set up in the Price Manager. For the full pricing walkthrough, see the Cost & Pricing Architecture guide.
| Configuration | Example Rate | What the Guest Sees |
|---|---|---|
| Per night, double occupancy | $180 | ”2 nights × $180 = $360” |
| Per night, single occupancy | $230 | ”2 nights × $230 = $460” |
| Per night, per person sharing | $95 | ”2 × $95 × 2 nights = $380” |
The booking wizard multiplies the per-night rate by the number of selected nights. No additional formula or markup logic is needed — the rate configured on the service is the nightly charge.
If rates vary by season (e.g., the gateway hotel is more expensive in summer), ensure that per-night rates are entered on the service for every price season. A missing rate for one season will cause pricing failures for departures in that window.
Part 3: Inventory Considerations
Inventory Models for Pre/Post Stays
There are three ways to manage inventory for pre/post stay accommodation. The right choice depends on the operator’s supplier relationships, risk appetite, and how much flexibility guests need.
Option 1: Shared Allotment
The extension draws from the same allotment pool as the main tour accommodation — the same hotel room block serves both core itinerary nights and extension nights. This is the simplest approach and works well when the extension uses the same hotel as the first or last night of the tour.
For example, if the Gateway Hotel has 20 rooms allocated across an inventory season:
| Allocation | Rooms Used |
|---|---|
| Main tour (Night 1 of the itinerary) | 18 rooms |
| Pre-stay guests (night before the tour) | Draws from the same 20-room pool |
| Available for pre-stay | 20 − bookings on that specific date |
The pre-stay dates and the main tour dates are different calendar days, so they consume allotment on different allotment day records. A pre-stay on 9 March and a tour night on 10 March draw from two separate allotment day records — but both belong to the same inventory season and the same total allocation.
This means the allotment pool is not split between “tour rooms” and “extension rooms.” All rooms are interchangeable. The constraint is simply: does the allotment day record for the extension date have available capacity?
Option 2: Separate Contract
A dedicated, independent allotment is set up specifically for the extension accommodation. This is common when the pre/post stay hotel is different from the main tour hotel, or when the operator wants to manage extension inventory separately — for example, to negotiate a smaller room block at a gateway city hotel without affecting the main tour allocation.
To configure this, create a separate supplier service for the extension hotel with its own inventory season and allotment days. Assign that service to the pre/post stay component. The extension inventory is then entirely independent of the main tour accommodation.
This approach gives more control over extension-specific capacity and release dates, but requires maintaining a separate allotment.
Option 3: On Request
The extension accommodation has no guaranteed allotment. Instead, the operator checks availability with the supplier before confirming the extension for the guest. This is suitable when demand for extensions is unpredictable, when the operator does not want to commit to holding rooms, or when the supplier relationship is ad hoc rather than contract-based.
In this model, the inventory status for the extension service is set to RQ (On Request). When a guest selects a pre/post stay in the booking wizard, the booking is created with an on-request status rather than confirmed. The operator then contacts the supplier to verify availability and confirms the extension manually once a room is secured.
On-request extensions are not guaranteed. Guests should be informed that the extension is subject to availability and may not be confirmed immediately. This trade-off avoids the cost and risk of holding allotment but means some extension requests may be declined.
| Inventory Model | Guaranteed? | Best For |
|---|---|---|
| Shared allotment | Yes — rooms are held in the same pool as the main tour | Extensions at the same hotel used by the tour; simple setup |
| Separate contract | Yes — rooms are held in a dedicated block | Extensions at a different hotel or when independent capacity control is needed |
| On request | No — availability is confirmed case by case with the supplier | Low or unpredictable extension demand; avoiding the commitment of a room block |
Step 3: Verify Inventory Coverage
The most common pre/post stay configuration error is insufficient inventory coverage. The allotment days must exist for the extension dates, which fall outside the main tour date range.
- Open the supplier service assigned to the pre/post stay component.
- Navigate to the Inventory Seasons related list.
- Verify that the inventory season’s date range covers the extension dates.
| Tour Dates | Extension | Dates to Cover | Inventory Season Must Include |
|---|---|---|---|
| Mar 10–20 | 2-night pre-stay | Mar 8–9 | Start date on or before Mar 8 |
| Mar 10–20 | 3-night post-stay | Mar 20–22 | End date on or after Mar 22 |
| Jul 1–10 | 1-night pre-stay | Jun 30 | Start date on or before Jun 30 |
- Open the inventory season and check the Allotment Days list for the extension dates.
- Verify that allotment day records exist for each extension date with status Available and a positive available count.
Screenshot of the allotment days list filtered to show dates just before the tour start date, with status “Available” and positive available counts for the pre-stay dates
If the inventory season starts on the tour start date (e.g., Mar 10) and does not extend earlier, allotment days for pre-stay dates (Mar 8–9) will not exist. The pre-stay will show as unavailable. Always verify that the inventory season starts early enough to cover the maximum pre-stay duration.
Stop Sale Impact
Stop sale flags affect pre/post stays exactly as they affect main tour nights. If a stop sale is applied to the hotel service for a date that falls within an extension window, the extension becomes unavailable for that date.
| Stop Sale Applied To | Effect on Pre/Post Stay |
|---|---|
| Allotment day for a specific pre-stay date (e.g., Mar 8) | Pre-stay blocked for itineraries that would include Mar 8 |
| Allotment day for main tour dates only | Pre/post stay unaffected (different dates) |
| Inventory season level (all dates) | All extensions blocked for that service |
When applying stop sale to a hotel service, remember that it affects both main-tour nights and extension nights. If you intend to block only the extension dates, apply stop sale to the specific allotment day records, not at the season level.
Capacity Planning
When planning allotment totals, account for extension demand on top of core tour demand. If a tour typically books 18 of 20 rooms and 40% of guests add a pre-stay, you need at least 8 additional rooms available on the pre-stay dates (18 × 0.4 ≈ 8).
| Planning Factor | How to Account for It |
|---|---|
| Pre-stay uptake rate | Estimate based on historical data or similar products; 30–50% is common |
| Post-stay uptake rate | Typically lower than pre-stay; 20–35% is common |
| Peak vs off-peak demand | Extension uptake may be higher in peak season when travellers want to maximize their trip |
| Allotment buffer | Ensure total allotment on extension dates ≥ main tour bookings × uptake rate |
If the extension hotel is different from the main tour hotel, its allotment is independent. Plan its allocation based on expected extension demand, not on the main tour’s room block.
Review extension uptake rates quarterly. If actual uptake consistently exceeds your planning estimate, increase allotment on extension dates to avoid turning away revenue.
Part 4: Multiple Extension Options
Offering Multiple Hotels
A package can offer more than one pre-stay (or post-stay) option. For example, a tour departing from a major city might offer:
- Standard: Gateway City Inn — $120/night
- Premium: Riverside Boutique Hotel — $220/night
To configure this, create two separate components, both with PreNight (or PostNight) allocation behaviour, each assigned to a different supplier service.
- Create Component A: “Pre-Tour: Gateway City Inn” → Allocation Behaviour: PreNight → Service: Gateway City Inn
- Create Component B: “Pre-Tour: Riverside Boutique Hotel” → Allocation Behaviour: PreNight → Service: Riverside Boutique Hotel
- Configure per-night pricing on each component’s supplier service independently via the Price Manager.
In the booking wizard, the guest sees both options and selects one (or neither). The two extensions are mutually exclusive — the guest picks one hotel, not both.
Screenshot of the booking wizard showing two pre-stay hotel options with different names and per-night rates, each with a “Select” button
Different Durations
The number of available nights is controlled by two fields on the component: Min Number of Nights and Max Number of Nights. These define the range of nights a guest can select in the booking wizard — for example, setting Min Number of Nights to 1 and Max Number of Nights to 3 lets the guest choose 1, 2, or 3 pre-stay nights. The per-night pricing model means the cost scales linearly with the number of nights selected.
| Nights Selected | Per-Night Rate | Total Extension Cost |
|---|---|---|
| 1 | $180 | $180 |
| 2 | $180 | $360 |
| 3 | $180 | $540 |
Ensure that inventory allotment days cover the maximum possible extension duration. If you offer up to 3 pre-stay nights on a tour starting 10 March, allotment days must exist from at least 7 March onwards.
Pre AND Post Stay
A single package can offer both a pre-stay and a post-stay. These are independent components — one with PreNight allocation behaviour and one with PostNight. The guest can select either, both, or neither.
| Component | Allocation Behaviour | Service | Per-Night Rate |
|---|---|---|---|
| Pre-Tour: Arrival City Hotel | PreNight | Arrival City Hotel — Standard Room | $150 |
| Post-Tour: Departure City Resort | PostNight | Departure City Resort — Garden View | $200 |
Each component has its own inventory, pricing, and optional flag. Configuring both on the same package does not create any dependency between them.
When offering both pre and post stays, verify inventory coverage on both ends of the tour date range. It is common to remember the pre-stay dates but overlook the post-stay dates (or vice versa) when setting up inventory seasons.
Validation Checklist
Before activating a package with pre/post stay components, verify each item:
Component Configuration
- Pre-stay component exists with Allocation Behaviour set to PreNight
- Post-stay component exists with Allocation Behaviour set to PostNight (if offering post-stay)
- Component names clearly indicate whether they are pre-tour or post-tour
- Each extension component is assigned to the correct supplier service
- Components have Selection Type set to Optional
Pricing
- Per-night rates are configured on the supplier service assigned to each extension component (via the Price Manager — see the Cost & Pricing Architecture guide)
- Rates cover all price seasons defined on the service (if using seasonal pricing)
- Rates cover all relevant passenger configurations (double, single, per-person)
- Valid pricing exists for each extension service — open the Price Manager and confirm rates are present for all applicable price seasons (missing pricing causes the extension to be hidden from the booking wizard)
- All price categories on the extension service have a Sort Order value populated (required for the service to appear in Pre/Post Stay tabs — see Common Issues)
- Per-night pricing displays correctly in the booking wizard preview
Inventory
- Inventory season date ranges extend far enough to cover the maximum extension duration
- Allotment days exist for all possible pre-stay dates (before the tour start)
- Allotment days exist for all possible post-stay dates (after the tour end)
- Allotment day status is Available for extension dates
- Available count on extension dates is sufficient to meet expected demand
Activation
- Package is activated (required before running end-to-end tests)
- Extension components are activated (each pre/post stay component must be individually active)
- Services assigned to extension components are activated (the Active flag on each Service record must be checked)
End-to-End Test
- Run a test booking with a pre-stay selection and verify correct dates on the itinerary
- Run a test booking with a post-stay selection and verify correct dates on the itinerary
- Run a test booking with both pre and post stays selected
- Run a test booking with no extensions selected and verify the base package is unaffected
- Verify that selecting more nights than allotment allows results in an appropriate availability message
Common Issues and Solutions
Extension Not Appearing in the Booking Wizard
Data import gotcha: If price categories were bulk-imported rather than created through the Salesforce UI, the Sort Order field may be blank. The UI makes Sort Order mandatory, but data imports can skip it. Extensions with missing Sort Order on their price categories will work in standalone bookings but silently disappear from the Pre/Post Stay tabs in package search — making the issue hard to diagnose.
| Cause | How to Identify | Solution |
|---|---|---|
| Allocation Behaviour not set | Open the component — field is blank or set to Standard | Set to PreNight or PostNight |
| Component not active | Component record is inactive | Activate the component |
| No supplier service assigned | Component has no services in its related list | Assign a supplier service |
| Service assigned to the component is inactive | Open the Service record — the Active flag is unchecked | Check the Active flag on the Service record |
| Service has no inventory for extension dates | Open the service — inventory season does not cover pre/post dates | Extend the inventory season or create a new one covering the extension dates |
| No valid pricing on the extension service | Open the Price Manager for the service — no rates exist for the extension’s price seasons or the relevant passenger configurations | Enter per-night rates for the extension service covering all applicable price seasons, or enable inflation pricing if estimated pricing is acceptable |
| Price categories have no Sort Order | Open the price categories on the extension service — the Sort Order field is blank or null. The service works in standalone bookings but does not appear in Pre/Post Stay tabs | Populate the Sort Order field on all price categories for the extension service. This field is required for the search results builder to include the service in pre/post stay grouping |
Inflation and estimated pricing: If inflation pricing is enabled on the service and prior-year rates exist, the extension will appear in the booking wizard with an estimated price that looks the same as any other price — the guest will not see any difference. After booking, the Costings view on the Itinerary will display EC (Estimated Cost) and ES (Estimated Selling) badges next to affected line items, so you can clearly identify which prices are estimates rather than exact season matches. If no prior-year rates exist either, inflation cannot calculate a price and the extension remains hidden.
Extension Showing Wrong Dates
| Cause | How to Identify | Solution |
|---|---|---|
| Allocation Behaviour is reversed (PreNight on a post-stay) | Pre-stay dates appear after the tour instead of before | Swap PreNight and PostNight on the affected components |
Inventory Conflict — Extension Unavailable Despite Hotel Having Rooms
| Cause | How to Identify | Solution |
|---|---|---|
| Inventory season does not start early enough for pre-stay | Season start date is the tour start date or later | Extend the season start date to cover the earliest possible pre-stay date |
| Inventory season does not end late enough for post-stay | Season end date is the tour end date or earlier | Extend the season end date to cover the latest possible post-stay date |
| Allotment days not generated for extension dates | Allotment day list has no records for the extension dates | Generate allotment days for the full season date range |
| Stop sale on extension dates | Allotment day status is Stop Sale | Remove stop sale if no longer needed |
Pricing Not Displaying Per Night
| Cause | How to Identify | Solution |
|---|---|---|
| No rate entered on the supplier service | Open the service’s Price Manager — cost or sell price is missing | Enter per-night rates on the service for all price seasons and passenger configurations |
| Rate entered for the wrong price season | Rate exists for High season but the departure falls in Shoulder | Enter rates for every price season on the service |
| Component pricing is total rather than per-night | Guest sees a flat charge instead of a nightly rate | Verify the pricing model on the service is set to per-night |
Related Schema Objects
| Object | API Name | Purpose | Key Fields |
|---|---|---|---|
| Package Component | KaptioTravel__PackageComponent__c | Extension component record | Name, Type, Allocation Behaviour, Optional |
| Component Item | KaptioTravel__PackageComponentItem__c | Links a supplier service to the component | Component, Item, Default |
| Service | KaptioTravel__Item__c | Supplier service (hotel room) | Name, Supplier, Item Type, Active |
| Inventory Season | KaptioTravel__InventorySeason__c | Date range with allocation totals | Start Date, End Date, Total Allocation, Stop Sale |
| Allotment Day | KaptioTravel__AllotmentDay__c | Per-date availability record | Date, Total Allotment, Booked, Available, Status |
| Package | KaptioTravel__Package__c | Parent package | Name, Departure Type, Active, Searchable |
See Also
- Package Fundamentals — core package structure, components, and pricing foundations
- Anyday Package Setup Guide — foundational package setup, including components and pricing
- Seasonal Package Setup Guide — time periods and price seasons for seasonal products
- Fixed Departure Management — per-departure configuration for group tours
- Supplier & Service Setup — creating supplier services and inventory seasons
- Inventory Operations Guide — managing allotments, stop sale, and availability statuses