Sezon fiyatlandırma takvimi nasıl hazırlanır?

Otellerde en yaygın fiyat belgesi şudur: ocak ayında bir Excel açılır, üç sezon yazılır, her sezona bir fiyat verilir ve dosya kapanır. Temmuzda talep beklenenden yüksek gelir, fiyat aynı kalır. Kasımda talep düşer, fiyat yine aynı kalır. Bu belge bir takvim değil, ocak ayının tahminidir.

Bu yazıda sezon fiyat takvimini beş adımda kuruyorum: geçmiş veriyi gün bazında okumak, talep takvimini çıkarmak, sezon bantlarını belirlemek, taban ve tavanı koymak, güncelleme ritmini kurmak. Sonunda kurgu bir örnek tablo ve sahada en sık gördüğüm dört hata var.

Sezon takvimi nedir, ne değildir

Sezon takvimi, yılın her günü için başlangıç fiyatını (BAR — Best Available Rate) belirleyen belgedir. "Her günü" kelimesi önemli: takvim aylara ya da üç sezona değil, günlere fiyat verir. Aynı hafta içinde çarşamba ile cumartesi farklı bantta olabilir; bayramın ilk günü ile son günü farklı fiyat taşıyabilir.

Takvim dinamik fiyatlandırmanın alternatifi değil, tabanıdır. Dinamik fiyat o gün için belirlenen BAR'ı pickup ve rakip fiyatına göre yukarı ya da aşağı oynatır. Takvim yoksa oynatılacak referans yoktur; dinamik fiyat yoksa takvim ocakta donar.

Adım 1: Geçmiş veriyi gün bazında okuyun

Aylık doluluk ortalaması sezon takvimi için işe yaramaz; temmuzun %85 doluluğu, içinde %60'lık salılar ve %100'lük cumartesiler barındırır. İhtiyacınız olan, son iki yılın gün bazında doluluk ve ADR verisidir. PMS'ten gün sonu raporlarını dışa aktarın; iki yıl 730 satır eder, bir tabloda rahat okunur.

Her gün için üç sütun yeterli: doluluk, ADR, haftanın günü. Dördüncü sütun olarak o gün özel bir şey olup olmadığını yazın: bayram, fuar, konser, okul tatili. Bu sütun bir sonraki adımın hammaddesidir.

İki yıldan biri olağandışıysa (büyük tadilat, pandemi yılı, bölgesel bir olay) o yılı referans almayın; tek yıl eksik veriyle çalışmak yanlış veriyle çalışmaktan iyidir.

Adım 2: Talep takvimini çıkarın

Talep takvimi, önümüzdeki yıl talebi olağan seyrinden çıkaracak her şeyin listesidir: resmi tatiller ve köprü günleri, okul tatilleri (hem yerel hem ana pazarınızın), dini bayramlar, şehirdeki fuar ve kongreler, konser ve spor etkinlikleri, bölgesel festivaller. Şehir otelinde fuar takvimi, resortta okul tatili takvimi listenin en ağır kalemidir.

Bu listeyi geçmiş verinin dördüncü sütunuyla karşılaştırın: geçen yıl fuar haftasında doluluk ve ADR ne oldu? Bu karşılaştırma, hangi etkinliğin gerçekten talep yarattığını, hangisinin yalnızca takvimde durduğunu gösterir.

Adım 3: Sezon bantlarını belirleyin

Bant, benzer talep taşıyan günlerin grubudur. Üç bant (düşük, orta, yüksek) çoğu otelde yetersiz kalır çünkü talep yılı üçe bölmez. Pratik kural: bir bant içindeki günlerin doluluğu birbirinden 15 puandan fazla ayrılıyorsa bant ikiye bölünür. Çoğu otel bu kuralla beş ile yedi bant arasında bir yapıya ulaşır.

Bantlar tarihe değil güne atanır. Yani "1 Temmuz–31 Ağustos: yüksek sezon" değil; "temmuz-ağustos hafta sonları: en yüksek, hafta içi: yüksek, bayram haftası: tepe" gibi. Aynı ay içinde üç farklı bant olması normaldir.

Adım 4: Taban ve tavanı koyun

Her bantın bir BAR'ı, tüm takvimin ise bir tabanı ve bir tavanı vardır. Taban, satılan oda başına maliyettir (CPOR): oda departmanının toplam maliyeti bölü satılan oda. Hiçbir bantın fiyatı, hiçbir indirim ve hiçbir kontrat fiyatı bu tabanın altına inmez; inen her oda doluluğu artırır, kârı düşürür.

Tavan iki şeyle sınırlanır: rekabet setinin en yüksek sezon fiyatı ve otelin geçmişte gerçekten satabildiği en yüksek fiyat. İkincisi çoğu zaman birincisinden düşüktür ve daha güvenilirdir; bir fiyatı listede tutmak ile o fiyattan satmak farklı şeylerdir.

Adım 5: Güncelleme ritmini kurun

Takvim yayına girdiği gün eskimeye başlar. Güncelleme ritmi haftalıktır: her hafta önümüzdeki 90 günün OTB'si geçen yılın aynı tarihindeki OTB ile karşılaştırılır. Bir tarih geçen yılın belirgin üstündeyse o günün bantı bir kademe yukarı, altındaysa fiyat değil önce kısıtlar (minimum kalış, kanal) gözden geçirilir.

Talep düşük geldiğinde ilk refleks fiyat indirmek olmamalı. Önce sorulacak soru: bu tarihe hangi kanaldan, hangi segmentten rezervasyon gelmiyor? Cevap çoğu zaman fiyatta değil görünürlükte ya da kısıtlarda çıkar.

Örnek: Örnek Otel'in takvimi

Aşağıdaki rakamlar kurgudur, gerçek bir tesise ait değildir. Örnek Otel 120 odalı, şehir merkezinde, yıl boyu açık bir tesis; CPOR'u 1.400 TL, geçmişte satabildiği en yüksek fiyat 4.000 TL olsun. Beş bantlı yapı:

Dikkat edilecek nokta: bantlar aya göre değil, gün türüne göre dağılmış. Mart ayının içinde hem 2. hem 4. bant var; fuar haftası hangi aya düşerse düşsün 5. bantta. Takvim yılın 365 gününe bu beş etiketten birini verir, sonrasında haftalık ritim etiketleri oynatır.

Sahada en sık yapılan dört hata

1. Takvimi yapıp dokunmamak

En yaygın hata bu. Ocakta yapılan takvim temmuzda pickup'a bakılmadan aynen uygulanır; talep yüksek geldiğinde masada para kalır, düşük geldiğinde son dakika indirimine koşulur. Haftalık güncelleme ritmi bu hatanın tek ilacıdır.

2. Üç sezonla yetinmek

Düşük-orta-yüksek yapısı, aynı bant içinde %55 ile %85 doluluklu günleri aynı fiyata satar. Bant sayısı talebin gerçek dağılımından gelir; kolaylık için üçe indirilen takvim, kolaylığın bedelini yüksek talepli günlerde öder.

3. Hafta içi ve hafta sonunu ayırmamak

Neredeyse her otelde haftanın günleri farklı talep taşır. Aynı bant içinde iki BAR (hafta içi, hafta sonu) tanımlamak takvimin en ucuz ve en etkili iyileştirmesidir.

4. Etkinlik takvimini fiyata yansıtmamak

Fuarın tarihini bilmek ile o haftayı 5. banta almak farklı şeylerdir. Etkinlik takvimi çoğu otelde satış ekibinin bilgisinde durur, fiyat dosyasına geçmez. Talep takvimi (Adım 2) tam olarak bu kopukluğu kapatmak için var.

Kendi otelinizde nasıl kurarsınız

1. 01PMS'ten son iki yılın gün sonu raporlarını dışa aktarın: gün, doluluk, ADR, haftanın günü, o günün notu.
2. 02Önümüzdeki yılın talep takvimini çıkarın: tatiller, okul tatilleri, fuarlar, etkinlikler. Geçen yılki etkisiyle birlikte yazın.
3. 03Günleri doluluğa göre bantlara ayırın; 15 puan kuralını uygulayın. Bantları tarihe değil gün türüne atayın.
4. 04CPOR'u hesaplayın ve taban olarak yazın; tavanı geçmişte gerçekten satılan en yüksek fiyatla sınırlayın. Bant çarpanlarını bu iki sınır arasında dağıtın.
5. 05Haftalık güncelleme toplantısı kurun: 90 günlük OTB'yi geçen yılla karşılaştırın, sapan tarihlerin bantını oynatın. Toplantı 20 dakikadan uzun sürüyorsa takvimde bir sorun vardır.

İlgili kavramlar

• BAR — takvimin her güne verdiği başlangıç fiyatı.
• CPOR — taban fiyatın geldiği yer; altına inen oda zarar üretir.
• Pickup ve OTB — haftalık güncellemenin iki girdisi.
• MLOS ve varışa kapalı — talep düşükken fiyattan önce dokunulacak kısıtlar.
• Rate shopping — tavanın rekabet setine göre kontrolü; bir sonraki yazılardan birinin konusu.

Özet

1. 01Sezon takvimi aya değil güne fiyat verir; aynı ayda üç bant olması normaldir.
2. 02Bant sayısı talepten gelir: bir bant içinde 15 puandan fazla doluluk farkı varsa bölün.
3. 03Taban CPOR, tavan gerçekten satılmış en yüksek fiyattır.
4. 04Hafta içi ve hafta sonu aynı bantta bile ayrı BAR taşır.
5. 05Etkinlik takvimi fiyat dosyasının içindedir, satış ekibinin aklında değil.
6. 06Takvim haftalık güncellenir; ocakta yapılıp temmuzda aynı kalan belge takvim değil tahmindir.