The week you load your inventory into a new system is the week you find out what your contracts actually say. It is tedious, it is where most portal projects stall, and it is almost entirely avoidable pain if you go in with the right mental model.
Here is the shape of each of the three verticals, and the traps in each.
The principle: a product is not a price list
The instinct is to create "Bali Sunrise Trek — $45" and move on.
That instinct is what makes the system fight you in month two, because none of your three product types is really "a thing with a price". Each has a different unit of sale, and the unit is what you have to model.
| Vertical | What you actually sell | Priced by |
|---|---|---|
| Hotels | A room type on a rate plan, for a date range | Occupancy, per night |
| Tours & attractions | An option on a date, sometimes a time slot | Person, by age band — or per group |
| Transfers | A route between two points | Vehicle (private) or seat (shared) |
Get the unit right and everything downstream — availability, cancellation, the voucher — falls into place. Get it wrong and you will be entering the same hotel four times, once per season.
Hotels: room type × rate plan × season
The structure that matches nearly every hotel contract in existence:
Room types — Deluxe Garden View, Family Suite. Each has a real maximum occupancy and usually a maximum number of children. Enter these from the contract, not from the hotel's website, because the website is marketing and the contract is what you can sell.
Rate plans — Room Only, Bed & Breakfast, Half Board. A rate plan is where the cancellation policy lives, along with minimum stay and how far ahead it can be booked. The same room on two plans is two different products commercially, and that is correct.
Seasons — dated periods with prices per occupancy: single, double, triple, extra bed, child. Not one price with fractions applied.
Availability per night — allotment or freesale, plus stop-sell.
The traps
Overlapping seasons. Contracts routinely have a general period and a peak period inside it. You need one unambiguous rule for which wins — most specific covering period, decided once — or you will quote peak rates in low season.
Half-open date ranges. A stay from the 10th to the 13th is three nights: 10, 11, 12. Not four. This sounds obvious and it is the single most common off-by-one in travel systems. Decide that check-out day is excluded and hold that line everywhere.
Allotment is not a suggestion. If two agents book the last room at the same moment, the count has to be consumed inside the same transaction that creates the booking, under a lock. Otherwise you will oversell on precisely the dates that are tight.
Supplements. Compulsory gala dinners, city taxes, peak-season surcharges. They are per person, per room, per night or per stay, and which one it is changes the total materially. Model them explicitly rather than folding them into the rate, or you will not be able to explain the price to an agent.
Tours and attractions: options, not products
One product — "Waterbom Bali" — with several options: standard entry, entry with hotel transfer, the fast-track ticket. Each option is a real SKU with its own price, its own capacity and sometimes its own operating days.
Age bands. Adult, child, infant, with real age boundaries from the operator. Children are usually not half price, and infants are usually not free. Take the numbers from the contract.
Time slots. Some options need one (timed-entry attractions, a boat that leaves at 09:00 and 14:00) and some do not. Slots have their own capacity, which is not the option's daily capacity.
Operating days. This is the master switch. The rule worth writing on the wall: operating days are the only thing that decides open or closed. A special price on a closed date does not open it. A capacity override on a closed date does not open it. Overrides may close, re-cap or re-price — never force open. Without that rule you will eventually sell a tour on Christmas Day because somebody set a festive price.
Cut-offs. "Book by 16:00 the day before" is a rule about the product's local time, not yours. An operator in Bali and a desk in Dubai disagree about when tomorrow starts, and the customer is always in the third place.
E-tickets. If you hold pre-purchased ticket codes, treat the stock as inventory: it gates the sale like any other capacity. A code assigned to a booking is never re-pooled, even after cancellation — it has been spent whether or not it was used.
Transfers: a route, and how it is sold
A transfer is a route — from somewhere, to somewhere — and the two ends are the product.
Each end is one of three kinds, and the kind is the rule:
- Airport — fixed meeting point, and the agent must give a flight number.
- Named place — a hotel, a pier, a station. Fixed meeting point.
- City or area — no fixed point, so the agent types the address at booking.
That is the whole taxonomy, and it is worth resisting the urge to add a fourth. Resist harder the urge to pre-create a list of zones covering every city you might one day serve: you will spend a fortnight filling in a table you never finish, when the endpoint an agent needs is the one they type.
Then two ways to price the same route:
Private, per trip. A vehicle with a capacity and a luggage limit. Extra passenger, extra bag and extra stop are add-ons. The price is per vehicle regardless of how many people sit in it.
Shared, per seat. A departure at a time, with a seat count that runs down as it sells, and age-band pricing.
Plus the rules that apply to the route as a whole: a night window with a surcharge, closed date ranges, a booking cut-off, and — if you run it — the return leg, which is its own route and should be created as one rather than inferred.
Practical sequence for the loading week
- One product per vertical, end to end, first. One hotel, one tour, one transfer — loaded, priced, published, and test-booked by you. You will find three misunderstandings, and finding them on product one is cheap.
- Then the top twenty by revenue. Not everything. Twenty products will cover most of what your agents ask for, and they will surface every structural question your catalogue contains.
- Then the long tail, as it sells. Products nobody has booked in a year can wait, or never arrive.
The check before you publish
Before anything goes live, one question per product: could the system quote this right now?
Rooms on sale, every room type with a rate plan, prices that cover future dates, options with prices above zero, slots for the options that need them, operating days set, ticket stock available. If the answer is no, the product should not be publishable — not warned about, not publishable. An advisory quality check gets ignored by the third product. A gate does not.
That single rule is worth more than any amount of data validation elsewhere: an agent never sees a product that cannot be sold, so an agent never fills in a booking form that ends in an error.
