1. Overbooking nedir ve ne zaman bilinçli kullanılır?
Overbooking, satılabilir kapasitenin üzerinde rezervasyon alınmasıdır. Bu, iki şekilde ortaya çıkar: • Sistemsel (hata): Envanter yanlış senkron olur, oda tipi yanlış eşleşir, kısıtlar çalışmaz. • Planlı (strateji): İptal/no-show tahminine dayanarak kontrollü limitlerle “bilinçli” uygulanır.
Planlı overbooking, ancak şu şartlarla “strateji” olur: 1. İptal/no-show davranışınız ölçülür (tahmin değil, trend) 2. Limitler oda tipi ve kanal bazında tanımlanır 3. Walk/relocation kapasitesi ve anlaşmaları hazırdır 4. Misafir iletişim ve çözüm akışı yazılıdır
☑ Mini Check (H2-1): Overbooking’in türü belli mi?
- • Overbooking olunca “hangi kök neden?”i 30 dakikada teşhis edebiliyoruz
- • İptal/no-show trendi veriye dayanıyor (tahmin değil)
- • Planlı strateji ile sistem hatasını birbirinden ayıran prosedür var
Ne yapmalıyım?
- • Overbooking’i “hata mı strateji mi?” diye ikiye ayıran bir kayıt şablonu oluşturun.
- • Hata kaynaklı ise önce mapping/senkron/limitleri düzeltin.
- • Strateji ise limit tablosu ve kriz planıyla güvenceye alın.
2. PMS–OTA entegrasyonunda overbooking’in temel nedenleri
Sistemsel overbooking genellikle “tek bir hata” değil; zincirde bir-iki zayıf halka ile oluşur. Tipik nedenler: • Mapping hatası: RoomType yanlış eşleşir → OTA’da satılmaması gereken ürün satılır • Senkron gecikmesi (latency): Stop-sell geç işler → kapalı sandığınız oda açık kalır • Çift panel yönetimi: PMS + channel manager aynı anda envanter/kural yazar → çakışma • Min–max limit yokluğu: Bazı kanallarda “0” olması gereken envanter açık kalır • Rezervasyon/iptal akışı bozuk: İptal PMS’e düşmez → kapasite yanlış hesaplanır
| Risk Belirtisi | Olası Kök Neden | Hızlı Aksiyon (24 saat) | Kalıcı Aksiyon (7–14 gün) |
|---|---|---|---|
| Stop-sell çalışmadı | Senkron gecikmesi / kural çakışması | Kanal bazlı satış kapama + log kontrol | Tek kaynak gerçek + latency izleme |
| Yanlış oda satıldı | RoomType mapping hatası | İlgili oda tipini kanalda kapat | Room mapping audit + isim standardı |
| İptal kapasiteyi açmadı | Status mapping / connector | Manuel düzeltme + iptal örnekleri | İptal/modifikasyon test senaryosu |
| Sadece bir OTA’da sorun var | Kanal ayarı / min limit yok | Kanal bazlı min limit koy | Min–max limit tablosu + süreç |
| “Sürpriz” overbooking | Plan yok / ölçüm yok | Walk planı devreye al | Planlı senaryo + eğitim |
☑ Mini Check (H2-2): Zincirde zayıf halka neresi?
- • Room mapping ve rate mapping düzenli denetleniyor
- • Stop-sell ve kısıtlar kanalda gerçekten test edildi
- • İptal/modifikasyon akışı PMS’e doğru düşüyor
Ne yapmalıyım?
- • “En çok satan 3 oda tipi” için mapping audit’i aylık rutin yapın.
- • Yüksek sezonda latency’yi izleyin (kapanma/güncelleme gecikmesi).
- • İptal ve değişiklik senaryolarını test rezervasyonuyla doğrulayın.
3. Overbooking riskini azaltmak için neler yapmalısınız?
Aşağıdaki liste, teknik (mapping/senkron) ve operasyonel (limit/plan) tarafı birlikte kapatır: 1. Mapping kontrolü yapın: RoomType → OTA Room eşleşmesini oda tipi bazında doğrulayın. 2. Tek kaynak gerçek belirleyin: Envanter ve kısıtlar tek panelden yönetilsin (PMS veya channel manager). 3. Min–max envanter limitleri tanımlayın: Oda tipi + kanal bazlı sınırlar koyun; “0 olmalı” kanalı açık bırakmayın. 4. Senkron takibi kurun: Stop-sell ve fiyat güncellemesinin kaç dakikada yansıdığını ölçün; anomaliyi alarmla yakalayın. 5. Test senaryosu şartı koyun: İptal, modifikasyon, stop-sell, min stay gibi senaryoları canlı öncesi ve sezon başında test edin. 6. Kriz planı yazın: Overbooking olursa “kim, ne söyler, ne teklif eder, nasıl kapatır?” akışını netleştirin.
☑ Mini Check (H2-3): 6 adımın hangisi eksik?
- • Limitler yazılı ve güncel
- • Test senaryoları dokümante
- • Kriz iletişim şablonu hazır
Ne yapmalıyım?
- • Bu 6 adımı bir “haftalık kontrol ritmi”ne bağlayın.
- • Sezon açılışında (Antalya/Belek) 2 haftalık stabilizasyon sprint’i planlayın.
- • Operasyon ve revenue ekibine aynı prosedürü öğretin (tek dil).
4. Envanter yönetimi ve limit tanımlama (Min/Max) — pratik model
Overbooking’i azaltmanın “en hızlı” kaldıraç noktası, envanteri akıllı kısıtlamaktır. Basit bir prensip: • Min limit: “Bu kanal bu oda tipinde en az şu kadar satabilir” (çoğu otelde yanlış kullanılır) • Max limit: “Bu kanal bu oda tipinde şu tavanı aşamaz” (risk azaltır)
Pratikte oteller için daha doğru yaklaşım: • Kanal bazlı “max” sınırı ile risk düşürmek • Kritik oda tiplerinde “buffer” bırakmak (özellikle yoğun sezonda)
Mini örnek (GEO): Belek’te yüksek sezonda “family” oda tipi en kritik ürünse, tüm kanallara sınırsız açmak yerine; max limit + stop-sell prosedürüyle yönetmek, sürpriz overbooking’i azaltır.
☑ Mini Check (H2-4): Limit mantığı doğru mu?
- • Oda tipi bazında max limit var
- • Kanal bazında risk profiline göre farklı limit uygulanıyor
- • Stop-sell hangi durumda devreye gireceği yazılı
Ne yapmalıyım?
- • Oda tiplerini “kritik / standart / esnek” diye sınıflayın.
- • Kritik oda tiplerinde max limit + buffer kurgulayın.
- • Kanal bazlı risk profilini (iptal/no-show/ödeme) limitlere yansıtın.
5. Yüksek sezonda overbooking stratejileri (3 planlı senaryo kutusu)
Yüksek sezonda (Antalya/Belek) iki tür risk aynı anda büyür: talep artar, operasyon yükü artar. Bu dönemde planlı stratejiniz yoksa sistemsel bir hata “krize” dönüşür.
Yüksek sezonda overbooking için 3 planlı senaryo (kutusu)
- • Senaryo-1: “Sıfır tolerans – kritik oda tipi” — Kritik oda tiplerinde planlı overbooking yok; Max limit + buffer yüksek; Hedef: misafir deneyimini sıfır riskle korumak
- • Senaryo-2: “Kontrollü – düşük riskli segment” — İptal/no-show yüksek segmentte küçük bir limit; Ön ödeme/NRF koşulu ile risk azaltma; Hedef: gelir fırsatı + kontrol
- • Senaryo-3: “Relocation hazır – pik günler” — Walk/relocation anlaşmaları ve alternatif tesis planı hazır; Önceden belirlenmiş teklif/upgrade politikası; Hedef: olası krizi “standart” çözüme çevirmek
☑ Mini Check (H2-5): Sezon senaryosu hazır mı?
- • Kritik oda tipleri belirlendi
- • Relocation planı ve iletişim metinleri hazır
- • Limitler sezon moduna göre güncelleniyor
Ne yapmalıyım?
- • Bu 3 senaryodan birini seçip yazılı hale getirin.
- • Ön büro ve rezervasyon ekibine 30 dakikalık mini eğitim yapın.
- • İlk 30 gün boyunca günlük spot-check ve log tutun.
6. Kriz yönetimi ve misafir deneyimi (hata → çözüm standardı)
Overbooking yaşandığında en kritik konu “oda” değil; misafirin güvenidir. Bu yüzden çözüm akışı, hızlı ve tutarlı olmalı:
Kriz akışı (özet): • Durumu teyit et (mapping mi, limit mi, gerçek kapasite mi?) • Satışı durdur (ilgili oda tipi/kanal) • Alternatif çözüm üret (upgrade, partner otel, transfer, iade/gesture) • Tek mesaj dili kullan (ön büro + call center + satış aynı şeyi söylemeli) • Sonrası: kök neden analizi + düzeltme backlog’u
Industry gözlemi (yumuşatılmış veri noktası): Doğru limit yönetimi ve senkronizasyon disipliniyle teknik kaynaklı overbooking vakalarının belirgin şekilde azaldığı görülür. Planlı overbooking tarafında ise doğru segment ve prosedürle yönetildiğinde gelir fırsatı oluşabilir; ancak misafir memnuniyetinden ödün verilirse uzun vadeli maliyet yükselir.
7. Overbooking Yönetim & Limit Tanımlama Checklist’i — PMS & OTA Yönetimi (v1.0)
Overbooking Yönetim & Limit Tanımlama Checklist’i — PMS & OTA Yönetimi (v1.0)
Bu asset, OTA entegrasyonunda sistemsel overbooking’i azaltmak için mapping denetimi, min–max limit tanımı, senkron takibi ve test senaryolarını tek bir standarda bağlar. Yüksek sezonda (Antalya/Belek) “sürpriz” vakaları azaltmayı ve overbooking yaşanırsa misafir deneyimini koruyan kriz akışını devreye almayı hedefler. Sonuç: daha az operasyon krizi, daha kontrollü gelir yönetimi.
Kim Kullanır?
Ön büro lideri, rezervasyon müdürü, RM ve ajans/IT entegrasyon sorumlusu.
Nasıl Kullanılır?
- Oda tiplerini “kritik/standart/esnek” diye sınıflayın ve mapping audit yapın.
- Kanal bazlı min–max limit tablosunu oluşturun ve stop-sell prosedürünü yazın.
- 14 günlük sprint planıyla test + izleme ritmini devreye alın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Overbooking tanımı ikiye ayrıldı: sistemsel vs planlı
- ▢ ✅ Tek kaynak gerçek belirlendi (PMS mi CM mi?)
- ▢ ✅ Kritik oda tipleri listelendi (ilk 3 ürün)
- ▢ ✅ RoomType mapping audit tamamlandı
- ▢ ✅ İptal/modifikasyon akışı test edildi
- ▢ ✅ Kanal bazlı max limit tanımlandı
- ▢ ✅ Stop-sell devreye alma eşiği yazıldı
- ▢ ✅ Senkron gecikmesi (latency) izleme yöntemi belirlendi
- ▢ ✅ Kriz iletişim şablonları hazır (ön büro + call center)
- ▢ ✅ Haftalık risk log’u tutuluyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Yüksek sezonda sürpriz overbooking yaşamadan limit ve süreçlerinizi güvenceye almak isteyen oteller için.
Sık Sorulan Sorular
Overbooking nedir, oteller için ne anlama gelir?▾
PMS–OTA entegrasyonunda overbooking neden oluşur?▾
Overbooking riskini azaltmak için en kritik 3 şey nedir?▾
Envanter limit tanımlama overbooking’i nasıl azaltır?▾
Yüksek sezonda planlı overbooking nasıl güvenli yapılır?▾
Overbooking yaşandığında misafir memnuniyeti nasıl korunur?▾
İlgili İçerikler