Kanal Yönetiminde Room Type ve Rate Plan Mimarisini Doğru Kurmak

RoomType, misafire sunduğunuz oda ürününü temsil eder: Standard, Superior, Family, Suite gibi. RatePlan ise o ürünün fiyatlama kuralını temsil eder: BAR, Non-Refundable, Early Booking, Package gibi. Basit bir ilişki gibi görünür; ama mimariyi doğru kurmazsanız, RoomType sayısı ve RatePlan sayısı çarpan etkisiyle grid’i büyütür.

Net ayrım (kısa):

• •RoomType = ürün (oda kategorisi)
• •RatePlan = fiyat kuralı (iptal, ödeme, promosyon, paket)
• •DerivedRate = ana rate’ten türeyen kural (ör. BAR’dan -%10 NRF)

AIO ilişkileri (doğal):

• •RoomType → has → Multiple RatePlans (her oda tipinin birden fazla fiyat planı olabilir)
• •RatePlan → mappedTo → OTA Rate (her fiyat planı OTA’da bir rate’e bağlanır)

Mini örnek (Belek resort)

Belek’te 5 oda tipi (Standard/Superior/Family/Suite/Villa) ve 4 ana rate plan (BAR/NRF/EB/Package) olduğunu düşünün. Mimari doğruysa 5×4 = 20 satır mantıklı bir grid üretir. Mimari yanlışsa “Standard Sea View”, “Standard Partial Sea View”, “Standard Garden View” gibi gereksiz çoğaltmalar + her biri için ayrı rate plan’lar, grid’i 60–120 satıra çıkarabilir.

☑ Mini Check (Kavram netliği):

• •RoomType = oda kategorisi, RatePlan = fiyat kuralı ayrımı bende net
• •DerivedRate mantığını biliyorum (ana rate’ten türeyen)
• •Grid büyümesinin çarpan etkisini (RoomType×RatePlan) görüyorum
• •Mimariyi “az ama kontrollü” kurgulamak istiyorum

Ne yapmalıyım? (3–6 aksiyon)

1. RoomType isimlerini ürün mantığıyla standartlaştırın (görünüm/kat gibi detayları sınırlayın).
2. RatePlan’ları “ana + türeyen” şeklinde hiyerarşik kurun.
3. Oda ve rate kombinasyonlarını önce tablolaştırın, sonra sisteme uygulayın.

PMS’te oda tipi mimarisinin amacı, operasyonu kolaylaştırmak ve satış kanallarında doğru ürün sunmaktır. “Her farklı manzaraya ayrı oda tipi” gibi aşırı detay, operasyonu ve channel manager mapping’ini zorlar. Doğru yaklaşım; oda tiplerini mantıklı bir ürün ağacı olarak kurmak ve varyasyonları gerekiyorsa “attribute/feature” seviyesinde yönetmektir.

Oda tipi sadeleştirme için 6 kural

• •Kural 1: Oda tipi “satılabilir ürün” olmalı (operasyon ve satış aynı dili konuşmalı).
• •Kural 2: Aynı kapasite ve benzer değer önerisine sahip odaları bölmeyin.
• •Kural 3: Manzara/konum varyasyonlarını sınırlayın (gerçek fiyat farkı yoksa bölmeyin).
• •Kural 4: Suite/Villa gibi premium ürünleri ayrı tutun (upsell ve raporlama için).
• •Kural 5: Çocuk/ekstra kişi farklarını oda tipiyle değil mümkünse policy ile yönetin.
• •Kural 6: Resort tesislerde “family” gibi kullanım amacına göre kategori net olsun.

Antalya/Kemer resort mini örneği

Kemer’de 350 odalı bir resort’te “Standard” oda 4 farklı blokta olabilir. Operasyon için blok önemli; ama satış için her blok ayrı “room type” olmamalı. Oda tipini 4’e bölmek yerine, “Standard” tek ürün; blok/konum iç operasyon attribute’u olarak yönetilebilir. Böylece mapping ve grid okunabilir kalır.

☑ Mini Check (RoomType mimarisi):

• •Oda tiplerim satış ürünü mantığıyla ayrışıyor
• •“Gereksiz varyasyon”ları tespit edebiliyorum (manzara/kat/blok)
• •Premium ürünlerim (suite/villa) ayrı ve net
• •RoomType sayısını kontrol altında tutma hedefim var

Ne yapmalıyım?

1. Mevcut oda tiplerini listeleyip “birleştirilebilir” olanları işaretleyin.
2. “Ürün ağacı” oluşturun: Basic → Upgrade → Premium.
3. Oda tipi değişikliği yapacaksanız, önce mapping etkisini simüle edin (kaç satır azalıyor?).

Rate plan tarafında en büyük hata, her kampanyayı ayrı bir “kalıcı rate plan” olarak açıp kapatmaktır. Bu yaklaşım kısa vadede kolay görünür; uzun vadede onlarca rate plan oluşur, mapping şişer, ekip hataya açık hale gelir. Sağlıklı mimari, rate plan’ları az sayıda ana plan ve bunlardan türeyen DerivedRate mantığıyla kurar.

Temel yapı (önerilen)

• •BAR (ana): esnek, ana referans fiyat
• •NRF (türeyen): BAR’dan belirli indirim + sıkı iptal
• •EB (türeyen/planlı): belirli tarih bloklarında aktif
• •PackageRate (planlı): değer ekleyen paketler (transfer/spa vb.)

Çocuk fiyatları, ekstra kişi ve paketler nasıl düşünülmeli?

• •ChildPolicy: çocuk/ekstra kişi fiyatı, idealde oda tipini çoğaltmadan policy ile yönetilir.
• •PackageRate: paketi ayrı rate plan yapıyorsanız, sayısını sınırlayın ve tarih bloklarıyla yönetin.
• •DerivedRate: NRF gibi türevleri “ana rate” ile bağlı tutmak, fiyat güncellemeyi kolaylaştırır.

Side’de aile segmenti örneği

Side’de aile ağırlıklı resort’te çocuk politikası karmaşıksa, “Family Room + 10 farklı rate” yerine; Family Room için 2–3 ana rate (BAR/NRF/Package) + ChildPolicy ile fiyat farklarını yönetmek daha sürdürülebilir olur.

☑ Mini Check (RatePlan mimarisi):

• •Rate plan sayım kontrollü (ana + türeyen)
• •Kampanyaları kalıcı rate plan’a çevirmiyorum (bloklarla yönetiyorum)
• •ChildPolicy ve PackageRate mantığı net
• •BAR güncelleyince türevlerin etkisini yönetebiliyorum

Ne yapmalıyım?

1. Rate plan envanterini çıkarın ve “kapatılacak/birleştirilecek” planları işaretleyin.
2. BAR’ı tek referans yapın; NRF/EB gibi planları DerivedRate mantığıyla bağlayın.
3. Paket rate’leri için maksimum sayı belirleyin (örn. 2–4).

Mapping, mimarinin gerçeğe dönüştüğü yerdir. Burada hedef, her OTA’da “doğru oda + doğru rate” eşleşmesini tek bir tabloda yönetmek ve değişiklikleri izlenebilir hale getirmektir. Mapping’te yapılan küçük bir hata, canlıda yanlış fiyat ya da yanlış oda satışı demektir.

Mapping’in altın kuralları (7 madde)

• •1) Tek kaynak gerçek: RoomType/RatePlan tanımları PMS’te standart ve güncel olmalı.
• •2) Tek mapping tablosu: Oda ve rate eşleşmeleri tek tabloda tutulmalı (versiyonlanmalı).
• •3) İsim standardı: PMS ve channel manager isimleri tutarlı olmalı.
• •4) Test rezervasyonu: Her yeni mapping değişikliği sonrası test yapılmalı.
• •5) Kanal bazlı farklılıklar: Bazı OTA’lar rate kuralını farklı yorumlayabilir; kontrol şart.
• •6) Değişiklik log’u: Kim, neyi, ne zaman değiştirdi kaydı tutulmalı.
• •7) Basamaklı devreye alma: Önce çekirdek kanallarda doğrula, sonra genişlet.

Örnek mapping tablosu (kısa şablon)

☑ Mini Check (Mapping kalitesi):

• •Tek mapping tablom var ve güncel
• •İsim standardım var (PMS/CM/OTA)
• •Değişiklik sonrası test rezervasyonu yapıyorum
• •Önce çekirdek kanalda doğrulayıp genişletiyorum

Ne yapmalıyım?

1. Mapping tablosunu zorunlu doküman yapın (versiyon + tarih).
2. Yeni rate/room açmadan önce “grid etkisi”ni hesaplayın (kaç satır ekleniyor?).
3. Test rezervasyonunu SOP haline getirin.

Kısa cevap: Hatalı mimari; grid ekranının şişmesine, mapping karmaşasına, fiyat hatalarının artmasına ve kampanya kurulumunun yavaşlamasına yol açar. Bu da hem gelir kaybı hem de operasyonel stres demektir. Özellikle Antalya/Belek gibi yoğun sezon destinasyonlarında, yanlış mimari “toplu güncelleme” sırasında hatayı büyütür.

En yaygın 5 belirti

• •Grid ekranında yüzlerce satır ve benzer isimler
• •Kampanya açmak için çok sayıda rate plan kopyalama
• •OTA’larda tutarsız fiyat/kurallar
• •Mapping hatası yüzünden yanlış oda satışı riski
• •Yeni personelin sistemi öğrenmesinin zorlaşması

Key Statistics / Data Point (sheet, soft benchmark): Oda tipi ve rate plan mimarisini sadeleştiren otellerde grid ekranı kullanımının kolaylaştığı; mapping ve fiyat hatalarının azaldığı; kampanya kurgulamanın hızlandığı senaryolar sık görülür.

☑ Mini Check (Sorun teşhisi):

• •Grid şişkinliğinin mimari kaynaklı olabileceğini kabul ediyorum
• •Rate plan çoğalmasının kampanya yönetimini bozduğunu görüyorum
• •Mapping hatalarının kök nedenini oda/rate yapısında arıyorum
• •Sadeleştirme için adım planım var

Ne yapmalıyım?

1. “İyi vs kötü mimari” karşılaştırmasıyla mevcut durumunuzu teşhis edin.
2. RoomType ve RatePlan sadeleştirmeyi iki sprint’e bölün (oda → rate).
3. Sadeleştirme sonrası mapping’i yeniden doğrulayın (çekirdek kanallarla başlayın).

Bu bölüm, rakip içeriklerde genellikle eksik olan “pratik denetim aracı” boşluğunu kapatır: aynı anda hem örnek karşılaştırma hem de hızlı checklist.

İyi vs Kötü Mimari (kısa tablo)

Mevcut yapınızı gözden geçirmek için 10 soru

1. RoomType sayım, tesis ölçeğime göre gerçekten gerekli mi?
2. Benzer oda tiplerini (manzara/kat) gereksiz bölüyor muyum?
3. BAR tek referans mı, yoksa birden fazla “ana rate” mi var?
4. Rate plan’larımın kaç tanesi “kapanması gereken kampanya” aslında?
5. DerivedRate mantığı (NRF/EB) sistemde tutarlı mı?
6. ChildPolicy oda tipini çoğaltmadan yönetiliyor mu?
7. Mapping tablom tek mi, güncel mi, versiyonlu mu?
8. Değişiklik sonrası test rezervasyonu SOP mi?
9. Grid ekranında “benzer isim” oranı yüksek mi?
10. Kampanya kurmak (yeni sezon) 30 dakikadan uzun sürüyor mu?

☑ Mini Check (Denetim sonucu):

• •En az 3 sadeleştirme fırsatı tespit ettim
• •Mapping dokümantasyon eksiklerimi gördüm
• •Kampanya yönetimini hızlandıracak değişikliklerim netleşti
• •Bir sonraki adımı (analiz / uygulama) belirledim

Ne yapmalıyım?

1. Bu 10 soruyu ekip toplantısında birlikte cevaplayın (GM + revenue + front office).
2. “Sadeleştirme backlog”u çıkarın: hızlı kazanımlar + riskli değişimler.
3. Değişiklikleri önce düşük riskli tarihlerde devreye alın, sonra genişletin.

Kanal yönetiminde sürdürülebilir başarı, ekranda “hızlı tıklamak” değil; doğru RoomType ve RatePlan mimarisi kurmaktır. Oda ürün ağacı sade, rate plan hiyerarşik ve mapping dokümante olduğunda; grid ekranı okunur, fiyat/mapping hataları azalır, kampanya ve paket yönetimi hızlanır. Bu yazı, kanal yönetimi silo’sunda “teknik mimari” otorite içeriği olarak, ileride upsell ve paketleme içeriklerine de sağlam bir temel oluşturur.