The 3 inventory patterns: pooled, allocated, derived

Three patterns govern how channel managers distribute inventory across OTAs. Each has different upside, different risk, and different operational requirements. Most properties run a mix without realizing it — which means they are getting the worst trade-offs of each pattern without the benefits of any one in particular.

Pattern A: pooled inventory

All channels draw from the same total inventory pool. If you have 100 rooms available on July 14, all 14 OTAs see 100 rooms. A booking on any one channel decreases the pool, and all other channels see 99 rooms within 30-60 seconds.

Upside: maximum efficiency, no stranded inventory, you fill rooms wherever demand appears. Downside: requires fast, reliable CM-OTA sync; vulnerable to double-bookings during sync latency; offers OTAs no special treatment so visibility programs (Genius, Preferred) cannot be paid in inventory terms.

Use when: inventory sync is reliable (under 60 seconds for major OTAs), you are not committed to specific allocation deals, and you want maximum flexibility.

Pattern B: allocated inventory

Each OTA gets a fixed allocation. Booking.com gets 40 rooms, Expedia 30, Agoda 15, your direct site 15. Each OTA can sell up to its allocation; once exhausted, that channel is sold out even if you have rooms left for other channels.

Upside: no double-booking risk because allocations are isolated; gives OTAs a guarantee that incentivizes visibility; supports specific commercial deals (a wholesaler with allocated rooms for a known package).

Downside: stranded inventory — rooms allocated to a slow channel sit empty while another channel could have sold them; requires manual reallocation as demand patterns shift; doubles the operational complexity.

Use when: wholesale or tour-operator contracts require committed allocation, or when sync reliability is poor and you must isolate channels to prevent double-booking.

Pattern C: derived inventory

Inventory levels for some channels are calculated from a base pool minus other channels' bookings, with rules. Example: Booking.com sees (total available − Cari bookings − wholesale committed). The CM derives the level dynamically.

Upside: combines pooled efficiency with some allocation logic, allowing complex commercial structures to live alongside dynamic distribution. Downside: very complex to configure correctly, easy to misconfigure into a parity break or double-booking, requires sophisticated CM software (D-Edge, RateGain Connect; SiteMinder and Hotelrunner support derivation but with more friction).

Use when: you have a sophisticated commercial setup (wholesale + direct + multiple OTAs + group contracts) and a strong technical team to maintain the derivation logic.