Child ages across channels: one rule in the PMS, the channel manager and every booking site

A child age policy is one internal table that states, for every age, what a child costs, where the child sleeps and whether the child counts toward occupancy. The hotel keeps that table as the single source, maps it band by band to each channel's bands, then proves the mapping with a test booking at every band edge. This is child age configuration across channels, and it belongs to the hotel, not the software.

A family of four arrives late in the evening. The confirmation says two adults and two children, one child free. The front desk system says the room holds three people, and no extra bed was ever sold. Nobody configured anything wrong on purpose: three systems simply held three different ideas of what a child is. After reading this, you will be able to write one policy table, map it to each channel in writing, and prove the mapping before a guest ever sees it.

Where do child age mismatches between channels begin?#

They begin where the same child is described by three different sets of age bands: the hotel's own policy, the booking site's form, and the occupancy rules attached to the rate plan.

Each system stores a different thing. The hotel system, the PMS (the property management system that holds reservations, rooms and bills), stores a guest record with an age or a birth date. The channel manager stores a mapping between the hotel's room and rate codes and the channel's codes. The booking site stores its own age bands and applies its own child logic before the hotel ever sees the booking. To understand what travels between them, it helps to know how a channel manager connection works, including delays and errors.

The booking form asks for the child's age, then decides which band applies and what that band costs. What reaches the hotel is a price and a headcount, not the band and not the reasoning behind it. The hotel system has to reconstruct the meaning, or apply a default.

Mismatches cluster at four points. First, band edges: a six-year-old is a child in one system and an adult in another. Second, the meaning of a free place, which can mean free stay, free breakfast or both. Third, extra bed availability, which the channel may not sell as a product at all. Fourth, whether a child counts toward the room's occupancy. A channel manager forwards numbers, not meanings: if a channel sends two adults and one child with no age, the hotel's system applies a default, and that default is rarely written down anywhere.

The guest sees the difference at the end. The confirmation email shows one total, the bill at check-out shows another, and both were produced correctly by their own system.

The usual root cause is not software. The hotel never wrote its own bands down, so each channel was configured from memory at a different time by a different person. The fix starts with a document, not a setting.

What should a single child policy table contain?#

One table that answers, for each age, three questions: what the child costs, where the child sleeps, and whether the child counts toward the room's occupancy.

Fix the definition of age first. Age on the arrival date, age on the booking date and birth year give three different answers for a child with a birthday in between. Pick one, write it in the table, and use it everywhere, including in conversations with channels.

Separate free stay from free breakfast from free everything. A free place in the parents' room using existing bedding is a different promise from a free child who still pays for breakfast. Write the bed logic explicitly: existing bedding, extra bed, crib, sofa bed, and which room types physically take an extra bed. A child who is free but needs a bed the room does not have is still a problem at 22:00.

Keep commercial occupancy and physical capacity apart. Commercial occupancy is what the channel is allowed to sell; physical capacity is what the room holds in beds and in safety terms. A child can be free commercially and still count physically. For the wider context of bands, free places and extra beds, see hotel child policy: age bands, free places and extra beds.

Name one owner and one version. The table carries a date and a responsible person, usually the reservations manager, and every channel mapping refers to that version. Keep it short enough to print: if the front desk cannot read the whole policy on one page, it will not be applied consistently at check-in.

For example, and this is an illustration, not a recommendation:

In this example, breakfast is free under 6, included in the child rate from 6 to 11, and charged as an adult from 12. The crib is subject to availability, and no extra bed is sold in the 3-5 band. Your own bands will differ; what matters is that every row answers all three questions.

How do you map child age bands to each channel?#

Band by band, in writing, with the channel's own band definitions copied next to the hotel's, and with the price difference and its owner recorded on the same row.

Get each channel's band definition from its own extranet documentation or account contact. Do not assume a channel uses the hotel's bands, and do not assume two channels use the same ones. Build one mapping row per channel and band: hotel band, channel band, what the channel will charge, what the hotel intends to charge, the difference, and who absorbs it.

Where a channel has fewer bands than the hotel, choose the mapping that never under-quotes. A guest who is quoted more than the policy says can be refunded at the desk; a guest who is quoted less has already been promised something, and the promise is the harder problem. Map the extra bed as its own product or rate where the channel supports it. Where it does not, the child price has to sit inside the room rate, and the guest will not see the bed as a separate line.

Keep the mapping in the same document as the policy table, with the channel name and the date checked, so the next person inherits the reasoning and not just the settings. Re-check when a channel changes its booking form: forms change without notice, and a mapping that was right last season can silently become wrong. The same discipline applies to the broader work of channel manager mapping for room types, rate plans and testing.

How do you test child age settings before they go live?#

Make a real test booking on each channel at every band edge, then compare four things line by line: the quote the guest saw, what the channel sent, what landed in the hotel system, and what the bill would be at check-out.

Test the edges, not the middle. The youngest and oldest age in each band, plus one year either side, is where the mapping breaks. A nine-year-old in a 6-11 band proves nothing. Test the configuration the room cannot hold: two adults and two children in a room whose maximum occupancy is three. This is the case that produces the late arrival dispute.

Compare the four records: the quoted total, the booking as the channel reports it, the reservation as it appears in the hotel system, and the projected bill. Any difference between them is a mapping bug, not a guest misunderstanding. Test the missing-age case too: some channels send counts without ages, and you need to confirm what the hotel system does with that, and whether the default matches the policy table.

Cancel the test bookings inside the free cancellation window or use a rate the hotel controls, and keep the cancellation record with the test log. Log the date, the channel, the band tested and the result. Repeat the whole set after any mapping change, and once before the season starts.

How do child ages change price and occupancy?#

A child can move the price in three separate ways: per-person pricing, the extra bed, and breakfast or board. The child can move the occupancy in two: the commercial count the channel sells and the physical capacity of the room.

Per-person pricing: when the rate plan charges per person, the child's band decides whether a third-person rate applies. A band mismatch changes the total even when the room price is untouched. Extra bed: charged as its own line or folded into the room rate; folded in, the channel cannot show it, so the guest sees a lower total than the bill will show. Board and breakfast: often charged per person with no age logic unless the hotel adds it, so a child who is free in the room can still be chargeable at breakfast. The mechanics of this are covered in per-person pricing on booking sites and occupancy-based rates.

Commercial occupancy is what the channel is allowed to sell into a room; physical capacity is what the room holds in beds and in safety terms. Never let a channel sell a configuration the room cannot hold, whatever the price says.

Decide in advance who absorbs a band mismatch. If the answer is always the hotel, say so in the mapping document, because that decision is a cost and it should be a chosen one. Keep the child rules in the rate plan, not only in the room type: two rate plans on the same room can carry different child treatment, and the guest picks the cheaper one.

Why do arrival disputes happen over child ages, and how do you handle them?#

Because the guest holds a confirmation that says one thing and the front desk holds a policy that says another, and each was produced correctly inside its own system.

Three disputes repeat. A child charged at check-out who looked free online. An extra bed that was never sold and is not available. A room sold for a family larger than its physical capacity. Decide the default before the season: settle that stay on the confirmation the guest holds, then fix the mapping afterwards. The difference is usually smaller than the cost of the argument in the lobby.

Do not assume a legal rule settles it. The hotel's own terms and the confirmation define the position, so a legal adviser should confirm the hotel's case before the season starts.

Record every dispute with the channel, the band, the amount and the date. Three disputes on the same channel and band is a mapping bug with a name. Give the front desk the policy table in the same version the channels use: a desk copy that is a season out of date turns a mapping bug into a confrontation. Fix the cause, not the symptom: waiving a charge ends one conversation, correcting the band mapping ends the series.

What should an annual child policy check cover?#

A dated review of the policy table, every channel mapping and the test results, done before the season's family bookings arrive rather than during them.

Re-read the hotel's own policy first: have the bands, the beds, the room types or the board rules changed since the table was written? Re-check each channel's bands and booking form against the mapping, and write the date checked on every row. Re-run the edge test bookings on every channel, including the family configuration the room cannot hold.

Reconcile the year's dispute log against the mapping. A band that produced disputes all season is the first row to change. Update the version, then tell the three groups who act on it: reservations, the front desk, and whoever holds the channel manager account.

Time the review before the season, not after it. A policy corrected in November has already cost a summer of arguments.

What to do next#

Write the policy table this week. One page, one owner, one date, every age band with its charge, its bed and its occupancy rule. Until that page exists, every channel configuration is a guess, and every guess will be tested by a family at 22:00.