1. Dynamic pricing ve dönüşüm raporlarını nasıl birleştirirsiniz?
Kısa cevap
- Fiyat değişimlerini “event” gibi kaydedin (tarih/saat, kanal, oda tipi).
- Aynı pencerede funnel KPI’larını izleyin (arama→checkout→purchase, web/OTA/call).
- Gelir etkisini PMS ile doğrulayın (ADR/RevPAR/gelir).
- “Fiyat artışı → dönüşüm düşüşü” eşiğini (elasticity) trendle belirleyin.
- Kararı “test et–ölç–güncelle” ritmine bağlayın (günlük küçük testler).
Bu yaklaşımın özü şudur: dynamic pricing motoru tek başına fiyat üretmez; dönüşüm sinyalleriyle beslendiğinde akıllanır. Ve rapor, revenue kararının “gözünü” açar.
☑ Mini Check
- •Fiyat değişikliklerini kayıt altına alıyorum (log)
- •Web/OTA/call dönüşüm KPI’ları aynı panelde
- •PMS gelir doğrulaması var
- •Eşik/elasticity için trend okuması yapıyorum
Ne yapmalıyım? (3–6 aksiyon)
- • Fiyat değişim günlüğü (price-change log) oluşturun.
- • Panelde “fiyat–dönüşüm–gelir” üçlüsünü aynı ekranda gösterin.
- • Oda tipi ve kanal kırılımlarını ekleyin (en çok değer burada).
- • Kararı haftalık mini-ritimle izleyin; ay sonunda stratejiye bağlayın.
2. Dynamic pricing ve revenue management’ın 2026 rolü
2026’da revenue yönetimi daha “anlık” ve daha “döngüsel”. Dinamik fiyat motoru, talep sinyallerini (arama, metasearch, lead, OTA pick-up), stok ve fiyat rekabetini bir arada değerlendiriyor. Ancak otelde kritik fark, bu sistemin dönüşüm sinyali ile beslenmesi: fiyat artışı dönüşümü ne kadar düşürdü, hangi segmentte düşürdü, hangi kanal telafi etti?
Revenue sisteminin yeni girdileri (otelde pratik)
- •Web funnel adım kayıpları (checkout drop-off)
- •Kanal karması ve net katkı lensi (Varsayım: komisyon)
- •Segment davranışı (ülke/cihaz)
- •Call center kapanış performansı (özellikle shoulder/düşük sezonda)
Mini örnek (Belek)
Belek’te yüksek talep döneminde fiyat artışı dönüşümü düşürür ama RevPAR’ı artırabilir. Eşik aşıldığında ise hem dönüşüm hem gelir düşebilir; bu eşik “anlık izleme” ile yakalanır.
☑ Mini Check
- •Revenue kararlarını sadece doluluk değil dönüşüm sinyaliyle de okuyorum
- •Segment kırılımı (ülke/cihaz) raporda
- •Kanal karması raporu (web/OTA/call) var
- •Call center “kapanış motoru” KPI’ları ölçülüyor
Ne yapmalıyım? (3–6 aksiyon)
- • Revenue toplantısına “funnel KPI” kartını ekleyin.
- • Ülke/cihaz kırılımı ile “eşik” davranışını ayırın.
- • Call center’ı “fiyat artışı sonrası kapanış” için ölçün.
- • Net katkı lensini (komisyon) rapora ekleyin.
3. Fiyat değişikliklerinin dönüşüme etkisini anlık izlemek (real-time monitoring)
Real-time izleme, “dakika dakika fiyat değiştir” demek değildir; doğru pencerede doğru sinyali okumaktır. Otelde ideal yaklaşım: fiyat değişimi sonrası 24–72 saat içinde dönüşüm trendini ve pick-up’ı kontrol etmek.
İzlenecek sinyaller (çekirdek)
- •Web booking rate ve adım drop-off
- •OTA pick-up ve iptal riski (Varsayım)
- •Call center lead→booking dönüşümü
- •Metasearch click→booking davranışı (Varsayım)
☑ Mini Check
- •Fiyat değişimi sonrası izleme pencerem var (24–72 saat)
- •Web/OTA/call sinyalleri aynı panelde
- •Drop-off artışı görünür
- •Anomali olduğunda aksiyon tetikleniyor
Ne yapmalıyım? (3–6 aksiyon)
- • “Fiyat değişimi sonrası kontrol penceresi” standardı koyun.
- • Anlık panelde sadece 5 KPI tutun (gürültü istemez).
- • Drop-off artıyorsa önce UX/ödeme sürtünmesini kontrol edin.
- • OTA pick-up artarken net katkıyı izleyin.
4. Revenue management sistemi + GA4 + PMS verisini birleştirmek
Bu birleşim, döngünün omurgasıdır:
- •GA4: davranış ve adım kaybı (teşhis)
- •PMS: gerçek gelir ve doluluk (doğrulama)
- •Revenue sistemi: fiyat motoru ve kural setleri (uygulama)
Veri modelinin minimum alanları (pratik)
- •Tarih/saat, oda tipi, kanal, fiyat
- •Booking count, revenue, ADR/RevPAR
- •Funnel adımları (checkout/purchase)
- •Segment (ülke/cihaz)
☑ Mini Check
- •GA4 davranış verisi var
- •PMS gelir doğrulaması var
- •Fiyat log’u var
- •Kanal/oda tipi kırılımları mevcut
Ne yapmalıyım? (3–6 aksiyon)
- • “Fiyat log” olmadan döngü kurulmaz; önce onu oluşturun.
- • GA4 funnel KPI’larını PMS gelir ile aynı dashboard’a koyun.
- • Oda tipi kırılımını ekleyin (elasticity odada farklıdır).
- • Haftalık revenue review’de bu paneli standart yapın.
5. Gerçek zamanlı fiyat–dönüşüm döngüsü (Price → Conversion → Revenue)
Bu bölüm, karar mekanizmasının kalbidir: “fiyat artışı conversion’ı ne kadar düşürürse gelir kaybı başlar?” Burada kesin rakam vermek yerine, otelinize özgü eşik davranışını trendle bulmak hedeflenir.
Eşik mantığı (elasticity okuması)
- •Küçük fiyat artışı → conversion biraz düşer → gelir artabilir
- •Daha büyük artış → conversion daha çok düşer → gelir sabitlenir
- •Eşik sonrası → conversion düşüşü geliri de aşağı çeker
Key Statistics / Data Point (yumuşatılmış)
Fiyat–dönüşüm izleme döngüsünü kuran otellerde, sezonda aynı dolulukla ya da daha düşük dolulukla daha yüksek gelir elde etme senaryoları teorik olarak mümkündür. Buradaki ana kaldıraç, dönüşüm düşüşünün “kabul edilebilir sınırını” veriye göre belirlemektir.
6. Oteller için “Test Et, Ölç, Güncelle” yapısı (her gün küçük testler)
2026’da “her gün küçük testler”, her gün fiyatı rastgele oynatmak değildir. Bu bir ritimdir: küçük değişiklik → ölçüm → karar. Otelde bu yaklaşım özellikle shoulder ve düşük sezonda daha güvenlidir; yüksek sezonda ise “daha az ama daha kontrollü” test yapılır.
Günlük küçük test prensipleri
- •Tek değişken: sadece fiyat veya sadece benefit (Varsayım)
- •Kısa pencere: 24–72 saat izleme
- •Guardrail: minimum fiyat ve marka vaadi (Varsayım)
- •Owner: revenue (karar) + pazarlama (kanal) + ürün/UX (sürtünme)
7. 3 fiyat test senaryosu
Senaryo 1 — Yüksek sezonda fiyat artışı
- •İzleme: booking rate, ADR/RevPAR, drop-off
- •Aksiyon: conversion aşırı düşerse eşik geri çek
Senaryo 2 — Düşük sezonda benefit vs indirim
- •İzleme: booking rate + net katkı lensi
- •Aksiyon: daha az indirimle daha yüksek değer mümkün mü?
Senaryo 3 — OTA baskın, direct zayıf
- •İzleme: channel mix ve net katkı
- •Aksiyon: direct avantaj + booking engine sürtünme azaltma
☑ Mini Check
- •Testler tek değişkenli
- •İzleme penceresi net
- •Guardrail kuralları var
- •Sonuç “güncelle” kararıyla kapanıyor
Ne yapmalıyım? (3–6 aksiyon)
- • İlk 30 gün sadece 3 test yapın (kalite > adet).
- • Her test için “önce/sonra” KPI kartı üretin.
- • Eşik davranışını sezon/pazar kırılımında ayırın.
- • Sonuçları aylık revenue stratejisine bağlayın.
8. Fiyat Testi & Gelir Optimizasyonu Senaryo Rehberini İndir — Satış & Dönüşüm Raporları
Fiyat Testi & Gelir Optimizasyonu Senaryo Rehberini İndir — Satış & Dönüşüm Raporları (v1.0)
Bu mini rehber, dynamic pricing kararlarını dönüşüm raporlarıyla birleştirmek için “fiyat değişimi log’u + KPI seti + izleme penceresi” şablonu sunar. Amaç, fiyat artışı sonrası dönüşüm düşüşünün hangi noktada gelir kaybına döndüğünü trendle yakalayıp “test et–ölç–güncelle” ritmini kurmaktır.
Kim Kullanır?
Revenue manager, pazarlama, BI/raporlama ve GM ekibi.
Nasıl Kullanılır?
- Fiyat değişim günlüğünü (tarih/saat, kanal, oda tipi) doldurun.
- 24–72 saat penceresinde booking rate, ADR/RevPAR ve channel mix KPI’larını izleyin.
- Sonucu “eşik” notuyla kaydedip bir sonraki fiyat güncellemesini buna göre yapın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tarih/saat: ____
- ▢ ✅ Oda tipi: ____
- ▢ ✅ Kanal: web/OTA/call
- ▢ ✅ Eski fiyat → yeni fiyat: ____
- ▢ ✅ Not: ____
- ▢ ✅ Booking rate (web/OTA)
- ▢ ✅ Drop-off (checkout)
- ▢ ✅ ADR/RevPAR
- ▢ ✅ Occupancy (Varsayım)
- ▢ ✅ Channel mix
- ▢ ✅ 24 saat / 48 saat / 72 saat trend okuması
- ▢ ✅ High season fiyat artışı
- ▢ ✅ Low season benefit vs indirim
- ▢ ✅ OTA baskın direct zayıf
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Fiyat kararlarını dönüşüm ve gelir döngüsünde yönetmek isteyen oteller için