Every booking carries three fields that answer three different questions, and in most PMS setups, two of them hold the same answer. The overlap looks like a naming issue and behaves like a forecasting error. Here is what it does to a segment forecast, worked through with numbers you can check, and a mapping fix that leaves your PMS codes exactly where they are.
Hotel Segments Answer Why the Guest Travels
The segment field answers why the guest travels. The reason belongs to the trip, so it changes slowly: the consultant on a six-month project books the same kind of stay every week. The channel field answers where the guest booked, and it changes often, because the same guest books direct in March and through an OTA in May. The rate code indicates what the guest paid and changes with every booking.
Three questions, three fields. Many hotels fill the segment field with the channel anyway: OTA, Direct Web, GDS, Wholesale. The habit usually arrives with PMS defaults and brand market code lists, which were built around how bookings arrive. It is the most common data structure in the industry, not a mistake any one revenue manager made.
Which guests the hotel should chase is a separate question, covered in Hotel Market Segmentation: The Two Numbers It Hides. The question here is narrower: what the segment field does to the forecast. With the channel in the segment field, you hold channel data twice and segment data not at all.
One Code, Two Booking Windows
Segment data matters to a forecast for one reason: each reason for travel books on its own clock. Business travel is not one reason. A project team, a sales visit, a conference, a training course, and a client event are five different reasons, each with a different lead time. A work meeting books on Tuesday. A congress is booked two years ahead.
Put two of them in one code and watch what happens to pickup, the ratio at the center of the cycle described in the hotel forecasting guide. Take a "Business" code that holds transient business travelers who book within 14 days and conference delegates who book months ahead. In a normal month, 400 transient room nights are 10 percent on the books 30 days out, which is 40 room nights. The 200 conference room nights are fully on the books. The code holds 240 of its final 600 room nights at day 30, so its history says day 30 equals 40 percent of the final number.
Next year, the same month carries a 500-room-night congress. At day 30, the code holds 540 room nights. The pickup model divides 540 by 0.40 and forecasts 1,350. The month closes at 900. The forecast is 450 room nights too high.
The error runs the other way in a quiet month. With no conference on the books, the code holds 40 room nights at day 30, the model forecasts 100, and the month closes at 400. Split the two reasons into separate codes, and both months forecast correctly: 40 divided by 0.10 plus 500 divided by 1.0 gives 900. The model was never wrong. The code fed it two clocks as one.
A Channel Code Forecasts Your Distribution
Channel codes introduce a second error that is harder to detect. Say the hotel moves 10 percent of its OTA share to direct booking over a year, which is exactly what most commercial plans ask for. The "OTA" segment falls. The "Direct" segment grows. A segment forecast built on those codes reports a shift in demand.
Nothing about demand changed. The same guests came for the same reasons, and the hotel paid less to acquire some of them. The pace curves moved because the distribution strategy moved, and a forecast that reads those curves as demand now treats a planned change as a market signal.
The cost shows up wherever the segment forecast feeds a decision: a group displacement call, a marketing budget by segment, the next budget season. Each one gets made on distribution data labeled as demand.
Map Before You Recode
Most revenue managers cannot simply rename the codes. The brand prescribes a market code list, the PMS reports on it, and finance reconciles against it. A rebuild is not the fix. A mapping layer is, and it sits next to the PMS without touching it.
- List every market code, rate code, and source in use, with last year's room nights next to each one.
- Map each line to one reason for travel. Split business into its five reasons, split leisure the same way, and keep three to five working segments.
- Forecast on the mapped segments, and keep reporting the PMS codes unchanged to anyone who needs them.
Whatever falls under 10 percent of room revenue is still received, priced, and counted. It gets no marketing plan and no target of its own. The codes that carry most of the volume map quickly, and the long tail can wait.
The Field Nobody Fills
Mapping solves the codes. It does not solve the booking that arrives with no reason attached, and most OTA bookings arrive that way. Part of the reason can be read from the stay itself: a weekday arrival, one or two nights, a negotiated rate, or a company profile all point to business travel. The rest has to be asked, in the pre-arrival message or at check-in.
Whoever asks determines the forecast. No algorithm fixes an empty segment field. Who in the hotel owns that field is a question for the general manager, and Thursday's post puts it there.
Run the Test on Last Quarter
Pull last quarter's segment report and count how many segment names are really channels or rate codes. Then take the largest code that mixes two booking windows, split it by reason for travel, and rerun the day-30 forecast both ways. The gap between the two numbers is the error your segment forecast has been carrying.
Demand Calendar is a total-revenue forecasting and profit system for hotels. It sits alongside your RMS and PMS, not instead of them.
A forecast can only separate what the data separates. Code the channel as the segment, and the most careful revenue manager in the market still forecasts distribution and calls it demand.
BOOK A STRATEGY CALL → demandcalendar.com/book-a-call
