The itinerary component: the smallest thing a trip can be built from
In short
An itinerary component is 1 purchasable service — a hotel stay, a transfer, a guide, an entrance — carrying its own supplier, service date, duration, pricing basis and cancellation term. The test is independence: if it can be cancelled or repriced without touching anything else, it is a component; if it cannot, it is a field on one. A day is not a component, and neither is a package.
Key takeaways
- A component is 1 purchasable service with its own supplier, date, duration, pricing basis and cancellation term.
- The independence test settles every boundary case: separately cancellable or repriceable means separate component.
- A day is a container and a package is a composition. Modelling either as a component breaks costing and vouchers.
- Pricing basis must be stored, not implied — a per-vehicle transfer multiplied by pax is the classic quoting error.
- Cancellation terms live on the component, which is what makes a payment schedule computable rather than guessed.
A component is 1 thing you buy from 1 supplier for 1 stretch of time. Two nights at a lodge, an airport transfer, a guide for a morning, a park entrance, a domestic flight. Each carries what is needed to buy, price, confirm, document and cancel it, and nothing above it in the model may hold those attributes instead.
Everything a trip business later wants — per-person costing, a voucher a supplier will accept, a payment schedule derived from real deadlines, a readable change history — depends on whether this object was defined properly, the dependency traced in how the trip data model sets the ceiling on quoting.
The attributes a component must carry
| Attribute | What it holds | What breaks without it |
|---|---|---|
| Supplier | The party you buy from, as a record not a name | Vouchers address nobody; payables cannot reconcile |
| Service date | A day offset from departure, plus a local start time | Dates stop moving when the departure moves |
| Duration | Nights, hours or a named unit such as half day | A 3-night stay silently overlaps the next city |
| Pricing basis | Per person, per room, per vehicle, per night or per party | A per-vehicle transfer gets multiplied by the pax count |
| Quantity | Rooms, seats, vehicles or tickets | Costs are correct for 2 travellers and wrong for 7 |
| Cost, currency, rate date | What you pay, in the supplier's currency, and when the rate was set | Margin drifts with the exchange rate from an unknown date |
| Cancellation term | The deadline and the penalty for this service | No computable payment schedule, no defensible refund |
| Confirmation state | Requested, held, confirmed or cancelled, plus the supplier reference | The proposal promises something nobody booked |
The cancellation term is the attribute most often left in an email thread, and the one with the longest reach. Deposit and balance dates compute backwards from supplier deadlines, so a component without a term forces someone to invent a schedule — the object modelled in deposit then balance as a schedule.
The independence test, applied to the cases that cause arguments
One question decides every boundary case: can this be cancelled or repriced without touching anything else? If yes it is its own component. If no it is an attribute, a line or a quantity on one that already exists.
| Case | Model as | Because |
|---|---|---|
| Two nights, same hotel, room type and rate plan | 1 component, quantity 2 nights | One booking, one deadline, one penalty |
| Two nights, room type changes on the second | 2 components | Different rate plan, different terms and price |
| Transfer with a possible waiting charge | 1 component with a conditional charge line | It cannot exist without the transfer |
| Guide booked for a half day | 1 component with a half-day unit | The unit is a basis, not a second service |
| Entrance the supplier bundles and will not itemise | An inclusion attribute of the parent component | It cannot be cancelled or repriced on its own |
| Same guide on 3 days, invoiced once | 3 components sharing a booking reference | Each day can move independently of the invoice |
If it cannot be cancelled or repriced on its own, it is not a component. It is a field on one.
The two things most often modelled as components by mistake
- A day is not a component. It is a container — an offset from departure that services sit in, which is why day 3 has no calendar date until a departure is chosen, as days are not dates in a trip model sets out. Make it buyable and no stay can span 3 of them.
- A package is not a component. It is a composition sold under one name, and collapsing it into a row destroys per-supplier costing, vouchers and change tracking inside it. Whether to sell it as a fixed product is a real trade-off, argued in sell a package or assemble components.
- A markup is not a component. It is a rule applied to them; stored as a line item, the quote cannot be recosted when a rate changes.
- A description block is not a component. Once proposal prose carries commercial meaning, the inclusions and exclusions block starts disagreeing with the trip it describes.
What a correctly defined component makes possible
- A voucher a supplier will honour, because reference, date, quantity and service sit on 1 record rather than being assembled by hand.
- A payment schedule computed from the earliest cancellation deadline in the trip, rather than from habit.
- A change history at the level clients ask about — this hotel, these dates — which is why a document points at a specific version, variant or revision, not the live trip.
- A proposal regenerated without drift, in whichever format you settle on in a PDF they keep or a link you can change.
- A migration path out of a decade of Word documents, because the extraction target is now a defined shape.
Get this record right and the rest of the model follows. Get it wrong and every later capability is bought back at a higher price, usually in spreadsheets. Extracting components at volume is where AI agents and automation helps, with the discipline in what breaks when agents run unattended. The rest sits under itinerary building and the trip data model, in our travel and tourism practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is an itinerary component in travel software?
One purchasable service carrying its own supplier, service date, duration, pricing basis, quantity, cost and cancellation term. A hotel stay, a transfer, a guide booking and an entrance are each components; the day they sit on is not, and the package they are sold inside is not. The test is independence — if it can be cancelled or repriced without touching anything else, it is a component.
Is a two-night hotel stay one component or two?
One, if both nights share a room type, rate plan and cancellation term — a single component with a quantity of 2 nights. Split it the moment anything differs, usually a room change or a rate plan with its own deadline, because 2 cancellation terms cannot live on 1 record without one being lost.
Why does the pricing basis need to be stored rather than assumed?
Because the same number means different things per service, and the error is invisible until the party size changes. A transfer priced per vehicle and a guide priced per day both look flat, while a room is per night and an entrance is per person. Storing the basis explicitly is what lets one itinerary be recosted for 2 travellers and for 7 without re-reading every line.
- data model
- itinerary
- components
- suppliers
The work behind this page
Builds from our portfolio that this page draws on.
QuoteForge
An AI CPQ and proposal platform that builds enterprise quotes from your catalog, guards every discount against the margin floor, routes approvals, and generates the proposal.
Sales AIAskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIRead next
- The trip day: why day three is not a date until a departure is chosenDay 3 becomes 14 March only once a departure exists. Storing the offset instead of the date is what makes shifting a departure and inserting a day survivable operations.definition
- Version, variant, revision: three itinerary objects, not oneA version is a snapshot, a variant is a parallel option, a revision is what the client has actually seen. Collapse them and the invoice, the proposal and the voucher start disagreeing.definition
- The client approved version four, and something movedA client quotes a detail your itinerary does not contain. Usually the builder edited in place and kept no snapshot, so the approved state has to be reconstructed from documents rather than read from the database.diagnostic
- Bookings confirm on your site and the supplier has no recordA confirmation email proves the checkout finished, not that a supplier accepted anything. Here is the timed comparison that shows whether your booking script reads live availability or a copy.diagnostic
- Drafts that put a closed property on day four: fixing seasonal blindnessSeasonal blindness is a metadata failure, not a prompting failure: the closure lives in a sentence nobody can filter on, so the shut property stays in the candidate set the model draws from.diagnostic
- Enquiry-to-booking conversion: the metric that lies at six monthsGroup enquiries by the month they arrived and follow them until they close. The calendar-month ratio moves when volume moves, so a growing month looks like a bad one.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation