Hotel Rate Plan ve Fiyatlama Modelleri
Rate plan, occupancy pricing, length-of-stay pricing, restriction ve derived rate kavramlarının hotel distribution ve metasearch içinde nasıl birlikte çalıştığını öğrenin.
Hotel rate plan yalnızca fiyat etiketi değildir. Occupancy, cancellation, meal, satış restriction'ları ve bazen market eligibility ile birlikte ticari bir ürün tanımlar. Metasearch sistemi bu semantics'i korumazsa eşdeğer olmayan ürünleri aynıymış gibi karşılaştırır.
Rate plan bir offer sözleşmesidir
Aynı oda için iki offer ciddi biçimde farklı olabilir. Biri breakfast dahil refundable iken diğeri room-only ve non-refundable olabilir. Bu nedenle sağlıklı bir rate-plan modeli yalnızca monetary amount değil, bu fiyatın hangi kurallarla geçerli olduğunu da içerir.
“Room + price” hotel comparison için yetersiz bir modeldir.
Pricing type fiyatın anlamını değiştirir
Booking.com Standard, derived, Occupancy-Based Pricing ve Length Of Stay gibi farklı pricing yaklaşımlarını dokümante eder. Buradaki önemli ders vendor ismi değil; fiyatın yalnız oda ve tarihe değil occupancy ve stay duration'a da bağlı olabilmesidir.
Normalization katmanı supplier fiyatının şu tiplerden hangisi olduğunu bilmelidir:
- room-based,
- occupancy-based,
- guest-based,
- length-of-stay-based,
- parent rate'ten derived,
- promotional veya conditional.
Occupancy product identity'nin parçasıdır
Bir yetişkin için fiyatlanan double room ile iki yetişkin için aynı room type her zaman aynı offer değildir. Supplier occupancy bazlı fiyat dönüyorsa hepsini tek “lowest room price” altında toplamak bilgi kaybına ve misleading comparison'a yol açar.
Adults, children, gerektiğinde child ages ve room count normalize edilmelidir.
Length of stay fiyatı değiştirebilir
LOS pricing kullanıldığında toplam konaklama fiyatı her zaman tek gecelik fiyatın gece sayısıyla çarpılması değildir. Minimum stay, stay-level discount ve duration bazlı fiyatlar total amount'ı değiştirebilir.
Bu nedenle metasearch price key'inde check-in ve number of nights gibi itinerary boyutları bulunmalıdır.
Derived rate lineage tutun
Child rate, parent rate üzerinden percentage veya fixed adjustment ile üretilebilir. Sistem yalnız final numeric amount'ı saklarsa rate'in neden o değerde olduğunu kaybeder ve reconciliation zorlaşır.
Faydalı alanlar:
- parent rate-plan ID,
- derivation rule,
- discount/markup tipi,
- effective dates,
- eligibility conditions.
Restriction rate plan ile birlikte düşünülmeli
Cancellation policy, meal inclusion, advance purchase, minimum stay, member-only ve market conditions yaygın örneklerdir. Bazı platformlarda conditional/fenced rate yapıları da bulunur.
Comparison UI bu farkları tek fiyat sıralamasının arkasına saklamamalıdır.
Normalize edin ama supplier semantics'i koruyun
İyi mimari comparison için normalized shape üretirken booking için gereken supplier-specific ID ve payload bilgisini de korur. Normalized model sorting/filtering için, supplier identifiers ise doğru handoff ve booking için kullanılır.
Amaç supplier farklarını silmek değil, karşılaştırılabilir hale getirmektir.
Meta Search yorumu
Rate plan çok boyutlu ticari üründür. Price, occupancy, stay length, cancellation, meal ve eligibility birlikte offer contract'ını oluşturur. Metasearch kalitesi, aynı tip ürünleri karşılaştırıp booking için gerekli supplier semantics'i kaybetmediğinde yükselir.
Rate plan lineage nasıl saklanmalı?
Derived veya child rate yalnız final amount olarak saklanırsa neden o fiyata geldiği kaybolur.
rate_plan_id
parent_rate_plan_id
pricing_type
derivation_type
derivation_value
meal
cancellation_policy
payment_timing
eligibility
effective_from/toBu lineage reconciliation ve promotion debugging'i kolaylaştırır.
Pricing model'i normalized amount'a çevirmek neden risklidir?
Occupancy-based veya LOS-based price'ı nightly room price'a zorla indirgemek source semantics'i kaybedebilir.
Örneğin 3-night package price:
night 1 = 100
night 2 = 80
night 3 = 0 promotional
total = 180"60/night" göstermek comparison için faydalı olabilir fakat original pricing basis korunmalıdır.
Failure mode'lar
- child rate parent update'i almıyor,
- occupancy price yanlış guest count'a uygulanıyor,
- LOS discount nightly flatten edilirken kayboluyor,
- promotion eligibility herkese açılıyor,
- cancellation rate-plan'den kopuyor.
KPI'lar
- rate-plan mapping coverage,
- derived-rate calculation mismatch,
- occupancy pricing error,
- promotion mismatch,
- rate-plan stale age,
- booking rejection by pricing-rule reason.
Rate plan numeric price değil, price + eligibility + policy + lineage bütünüdür.
Benzer bir entegrasyon mu planlıyorsunuz?
Gereksinim, feed/API tasarımı ve production yaklaşımını birlikte değerlendirebiliriz.