1. Esnek Rezervasyon (Flexible Booking) Nedir?
Esnek rezervasyon; misafire iptal ve/veya değişiklik hakkı tanıyan, genellikle bu esneklik karşılığında farklı fiyat/koşul içeren bir modeldir. Burada esnekliğin “bedeli” ya daha yüksek fiyat ya da belirli sınırlar (değişiklik limiti, son tarih, ücret farkı) şeklinde gelir.
Esnek rezervasyon nedir?
Esnek rezervasyon, misafire belirli kurallar içinde iptal ve/veya tarih-oda değişikliği hakkı tanıyan rezervasyon modelidir. Dönüşümü artırabilir; ancak değişiklik limiti, son tarih ve fiyat farkı kuralları net değilse yield ve doluluk dengesini bozabilir.
Ne yapmalıyım?
- • Esnekliği 3 parametreyle tasarla: limit + son tarih + fark kuralı
- • Esnek model için ayrı rate plan / kod kullan
- • Kritik günlerde esnekliği daralt (guardrail)
- • Misafir mesajlarını tek paragrafta standardize et
2. Flex-Stay, Open-Date ve Multi-Stay Modelleri
2026’da esneklik “tek format” değil; farklı ürünleşme biçimleriyle geliyor.
Flex-stay ve open-date modelleri ne demek?
- •Flex-Stay: Misafir belirli bir aralık içinde giriş/çıkışı esnek seçer (kurallı esneklik).
- •Open-Date Voucher: Misafir tarih seçmeden voucher alır, daha sonra kural setiyle tarih seçer.
- •Multi-Stay: Tek rezervasyon altında birden fazla konaklama (ör. 2 kısa stay) veya paketli yapı.
Model Karşılaştırma Tablosu (özet)
| Model | Misafire ne verir? | Otele risk | Otele fırsat | En kritik kural |
|---|---|---|---|---|
| Flexible Booking | iptal/değişiklik hakkı | iptal/yield | dönüşüm | son değişiklik tarihi |
| Flex-Stay | esnek giriş/çıkış aralığı | envanter kilidi | doluluk stabilitesi | aralık + min/max gece |
| Open-Date | tarihsiz satın alma | yüksek belirsizlik | nakit akışı | blackout + kullanım süresi |
| Multi-Stay | çoklu stay esnekliği | operasyon karmaşıklığı | paket geliri | her stay kuralı |
Ne yapmalıyım?
- • Her model için ayrı rate plan ve kod mantığı kur
- • Open-date için blackout date ve kullanım süresi şartlarını yaz
- • Flex-stay’de min/max gece ve aralık net olsun
- • Multi-stay’de değişiklik limitlerini daha sıkı tut
3. 2026’da Misafirin Değişen Davranışları
Misafir “planını kesinleştirmeden satın alma” eğiliminde. Bu da esneklik taleplerini artırıyor. Ancak otel için kritik olan: esnekliğin kontrolsüz değil kurallı olması.
Kaç kez tarih değişikliği verebilirim?
Değişiklik sayısı (ChangeLimit) ürün tasarımıdır: örneğin 1–2 ücretsiz değişiklik + sonraki değişikliklerde ücret farkı veya işlem ücreti. Doğru sayı; segment, sezon ve kanal karmasına göre belirlenir ve “son değişiklik tarihi” ile birlikte tanımlanmalıdır.
Ne yapmalıyım?
- • ChangeLimit’i ürün seviyesinde belirle (rate plan)
- • Ücretsiz pencereyi sezon/tempo ile dinamik tut (guardrail)
- • İptal yerine revizyon teşvikini planla (Blog-12)
- • Kampanya dilini “kurallı esneklik” olarak yaz
4. PMS ve Politikaların Bu Modellerle Uyumlandırılması
Esnek modelin başarısı, PMS’te doğru işlenmesine bağlıdır. Aksi halde; change history karışır, raporlar bozulur, misafirle iletişim kopar.
Flex-stay ve open-date rezervasyonlar PMS’te nasıl yönetilir?
Esnek modeller PMS’te ayrı rate plan (LongStayRate/FlexibleBookingRate) ve kural setiyle (PolicyRules) yönetilmelidir. Değişiklikler ReservationChange olarak kaydolmalı; change history, ücret farkı/penaltı ve son değişiklik tarihi net tutulmalıdır. Open-date voucher’da “kullanım süresi, blackout ve rezervasyon dönüşümü” adımları ayrı akış olarak tasarlanmalıdır.
Ne yapmalıyım?
- • Esnek modeller için “policy rules” dokümanı üret
- • PMS’te değişiklikleri kodla (neden kodu)
- • Raporlamada esnek modelleri ayrı segment olarak izle
- • Kanal yönetimiyle çakışmayan kısıtları belirle (stop-sell/min stay)
5. Gelir ve Operasyon Etkileri
Esneklik; doğru fiyatlanmazsa yield’i düşürür, ama doğru kurgulanırsa dönüşüm ve memnuniyet artar. Operasyon tarafında ise değişiklik akışı artacağı için süreç ve otomasyon şarttır.
Esnek değişiklik hakları gelir ve doluluğu nasıl etkiler?
Esnek haklar dönüşümü artırabilir; ancak değişiklik/iptal oranını yükseltme riski taşır. Bu yüzden esnek model; güçlü günlerde daha kısıtlı, zayıf günlerde daha açık tasarlanmalı; fiyat farkı ve penaltı kurallarıyla yield korunmalıdır.
Ne yapmalıyım?
- • Esnek model KPI’larını ayrı takip et (conversion/iptal/net ADR)
- • Güçlü günlerde esneklik daralt, zayıf günlerde genişlet
- • Revizyon SOP’u ile entegre et (Blog-12)
- • Call center fallback SLA koy (manuel onay gereken vakalar)
6. Esnek Model Tasarlarken Sorulacak 10 Soru
- Hangi model(ler)i sunuyoruz (flex/flex-stay/open-date/multi-stay)?
- ChangeLimit kaç? (ücretsiz + ücretli)
- Son değişiklik tarihi ne?
- Ücret farkı hesabı nasıl? (rate plan mantığı)
- İptal penceresi ve penaltı ne?
- Blackout date var mı (open-date için)?
- Kritik gün/oda tipinde esneklik kısıtımız ne?
- PMS change history ve rapor ayrımı nasıl?
- Manuel onay SLA’sı ne?
- KPI seti ne ve ne sıklıkla gözden geçirilecek? (180g)
7. Antalya ve Şehir Otelleri İçin Örnek Senaryolar
Antalya/Belek/Side/Kemer/Bodrum (resort)
- •Misafir esneklik ister, ama sezon zirvesinde esneklik daraltılmalı
- •Open-date voucher, kış–ilkbahar gibi daha düşük talepte cazip olabilir
- •Flex-stay, düşük sezonda doluluğu stabilize edebilir; blackout şart
Şehir oteli (İstanbul)
- •İş segmenti “tarih kaydırma” ister; change limit + son tarih net olmalı
- •Multi-stay (proje bazlı) mümkün; operasyon akışı net tasarlanmalı
8. Fark Yaratan Mini Bölüm: Esnekliği “Slogan” Değil “Kural Seti” Yapmak (Competitor Gap)
Rakip içerikler “esnek iptal”i kampanya mesajı gibi ele alıyor; 2026’da esnek modellerin asıl zorluğu PMS, politika ve gelir yönetimi tarafındaki karmaşıklıktır. Bu rehber; FlexibleBooking → ChangeLimit → PolicyRules → PMS akışı hattını kurarak esnekliğin kontrolsüz maliyete dönüşmesini engellemeyi hedefler. Hukuki detaylara girmez; tasarımın mutlaka hukuk ve gelir yönetimiyle birlikte yapılması gerektiğini not eder. (Refresh: 180 gün.)
9. Esnek Rezervasyon / Flex-Stay Model Tasarım Şablonunu İndir — 2026
Esnek Rezervasyon / Flex-Stay Model Tasarım Şablonunu İndir — 2026 (v1.0)
Bu şablon, flex-stay/open-date/multi-stay gibi esnek modelleri 2026 perspektifinde kural setine bağlamak için hazırlanmıştır: change limit, son değişiklik tarihi, fiyat farkı/penaltı otomasyonu ve PMS uyumu tek çerçevede planlanır. Amaç; dönüşüm artışı sağlarken iptal ve düşük yield riskini kontrol altına almaktır. Hukuki detaylar yerine prensip düzeyi kurallar verilir; uygulama için hukuk + revenue birlikte çalışmalıdır.
Kim Kullanır?
Revenue + rezervasyon lideri + online satış/ürün/politika ekibi.
Nasıl Kullanılır?
- Esnek model tipini seç ve hedef segmenti tanımla.
- PolicyRules (limit/son tarih/penaltı) setini doldur.
- PMS change history ve rapor ayrımını kontrol et; KPI setiyle izle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Model tipi seçildi
- ▢ ✅ ChangeLimit tanımlandı
- ▢ ✅ Son değişiklik tarihi yazıldı
- ▢ ✅ Fiyat farkı/penaltı kuralı net
- ▢ ✅ PMS change history ve rapor ayrımı kontrol edildi
- ▢ ✅ Hukuk + revenue birlikte değerlendirdi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
TEMPLATE – Model Kural Kartı
TEMPLATE – PMS Uyum Checklist
- •Ayrı rate plan/kod
- •Change history log
- •Fiyat farkı otomasyonu
- •İptal/no-show rapor ayrımı
- •Kanal kısıt uyumu
TEMPLATE – KPI Seti
- •Dönüşüm değişimi (flex vs klasik)
- •İptal oranı farkı
- •Net ADR/yield etkisi
- •Modification (değişiklik) oranı
- •Call center iş yükü etkisi
Bir Sonraki Adım
Change limit, son tarih ve fiyat farkı kurallarını yield ve iptal riskini dengeleyecek şekilde tasarlamanıza yardımcı olur.
Sık Sorulan Sorular
Esnek rezervasyon (flex) modelleri nelerdir, klasik rezervasyondan farkı nedir?▾
Flex-stay ve open-date rezervasyonlar PMS’te nasıl yönetilir?▾
Esnek değişiklik hakları gelir ve doluluğu nasıl etkiler?▾
Esnek rezervasyon politikalarını belirlerken nelere dikkat etmeliyim?▾
İlgili İçerikler