1. Overbooking Nedir, Oteller İçin Neden Risklidir?
Overbooking, aynı oda tipinin aynı tarih için birden fazla kez satılması veya “gerçek” müsaitliğin üzerinde satış yapılmasıdır. Bazen bilinçli overbooking (no-show beklentisiyle) stratejik olarak yönetilebilir; ancak OTA kaynaklı overbooking çoğunlukla sistem ve süreç hatası olarak ortaya çıkar. Risk sadece misafiri başka otele göndermek değildir; şikâyet, puan düşüşü, ekip stresinin artması ve sosyal medyada negatif dalga gibi zincir etkiler üretir.
Overbooking’in görünmeyen maliyetleri (relocation + itibar)
- •Relocation maliyeti: alternatif otel + transfer + telafi (upgrade/kupon)
- •Operasyon maliyeti: ön büro/rezervasyon ekip yükü, kriz yönetimi
- •İtibar maliyeti: olumsuz yorumlar, puan düşüşü, tekrar satış kaybı
- •Gelir maliyeti: sonraki dönemlerde ADR baskısı (güveni geri kazanma)
Mini örnek (Bodrum – hafta sonu pik)
Bodrum’da hafta sonu pik talepte iki oda tipinin mapping’i karıştığında, sistem “boş” görünüp satış açabilir. Sonuç; front office misafiri başka otele yönlendirir, telafi maliyeti yükselir ve yorumlarda “rezervasyonum vardı ama yer yoktu” cümlesi kalıcı hasar bırakır.
Mini Check (Risk fotoğrafı)
- • Overbooking’i “talihsizlik” değil süreç riski olarak görüyor muyum?
- • Relocation maliyetini ve şikâyet etkisini ölçüyor muyum?
- • Riskin kaynağını (senkron/manuel/limit) ayrıştırabiliyor muyum?
Ne yapmalıyım?
- • Son 12 ay overbooking olaylarını listeleyin (tarih/oda tipi/kök neden).
- • Relocation maliyetini ve yorum etkisini ayrı KPI olarak takip edin.
- • “Tek kaynak envanter” prensibini yazılı hale getirin.
- • Pik günler için ayrı kontrol ritmi tanımlayın.
2. PMS, Kanal Yöneticisi ve OTA Arasında Envanter Akışı
Overbooking riskini azaltmanın temel şartı, envanterin tek bir “kaynak gerçek”ten yönetilmesidir. En sık hata: aynı oda tipini hem PMS’te hem channel manager’da hem de OTA extranet’inde ayrı ayrı “elle” düzeltmeye çalışmak. Bu, kısa vadede problemi çözüyor gibi görünür; uzun vadede kural karmaşası ve “drift” üretir.
Tek kaynak prensibi (inventory single source of truth)
- •PMS: gerçek rezervasyon/çıkış-giriş, oda blokajları
- •Channel Manager: dağıtım kuralları, limitler, stop-sale, mapping
- •OTA: satış vitrini (manuel oynama “son çare” değil, “yasak” yaklaşımı)
Senkron hataları ve manuel müdahale riskleri
- •Gecikmeli senkron: pik talepte 5–10 dakikalık gecikme bile risk yaratabilir
- •Yanlış mapping: oda tipi eşleşmesi yanlışsa sistem yanlış oda satar
- •Manuel extranet müdahalesi: bir kanalda “açık” kalır, diğerinde “kapalı” sanılır
Teknik not (kilitli): Envanter sadece channel manager üzerinden yönetilmeli; OTA arayüzünden manuel oynama yapılmamalıdır. Pik talepte PMS logları ve rezervasyon akışı günlük kontrol edilmelidir.
Mini örnek (Antalya – yoğun check-in günü)
Antalya’da yoğun check-in gününde ön büro, OTA extranet’inde “son oda”yı kapattığını sanır; ama CM hâlâ satış açık kalır. Senkron bir yerde kopmuşsa overbooking kaçınılmaz hale gelir. Çözüm: müdahaleyi tek noktadan yapmak ve logla doğrulamak.
Mini Check (Akış)
- • Oda tipleri mapping’leri dokümante mi?
- • Tek kaynak (CM) üzerinden yönetim zorunlu mu?
- • Senkron gecikmesini ölçüyor muyum?
- • Pik günlerde log ve kontrol rutini var mı?
Ne yapmalıyım?
- • Mapping denetimi yapın (oda tipleri, meal plan, occupancy).
- • “Manuel extranet müdahalesi”ni SOP ile yasaklayın (istisna prosedürüyle).
- • Pik günlerde 2 kontrol saati koyun (ör. 11:00 ve 18:00).
- • Senkron sorunlarında “kimin karar verdiği” RACI’yi netleştirin.
3. OTA Üzerinden Overbooking Riskini Nasıl Azaltırsınız?
Bu bölüm, en çok aranan soruya madde madde, uygulanabilir bir cevap verir.
- Envanteri tek noktadan (channel manager) yönetin; OTA extranet’inde manuel oynamayın.
- Oda tipleri için minimum/maksimum limit tanımlayın (özellikle yüksek riskli tiplerde).
- Pik talep günlerinde stop-sale ve “kademeli kapama” kuralları kullanın.
- Allotment/opsiyon/garanti rezervasyonları ayrı yönetip net müsaitliğe doğru yansıtın.
- Senkronu sıklaştırın; pik günlerde günlük kontrol ve log doğrulama yapın.
- Overbooking olursa “5 adım misafir yönetimi” planını devreye alın.
Minimum / maksimum limitler (oda tipi bazlı kural tasarımı)
Her oda tipi aynı riskte değildir. Örn. “tek kalan son suite” ile “standart oda havuzu” aynı şekilde yönetilmez. Limit yaklaşımı:
- •Riskli oda tiplerinde maksimum satılabilir adet kısıtlamak
- •Bazı günlerde minimum kalış/CTA-CTD gibi kurallarla talebi yönetmek
- •Oda tipi değişimlerinde mapping tutarlılığı
Stop-sale (satışı durdurma) kuralları ve kademeli kapama
Stop-sale, “her şeyi kapat” demek değildir. Kademeli kapama:
- •Önce en riskli oda tipini kapat
- •Sonra belirli kanalları kapat (pazar/komisyon/iptal riskine göre)
- •En son tüm kanalları kapat (gerçekten gerekirse)
Opsiyon, allotment ve garanti rezervasyonların etkisi
- •Opsiyonlar: gerçek satış gibi görünürse kapasiteyi çabuk tüketir
- •Allotment: acente/partner blokları yanlış yönetilirse “sahte doluluk” üretir
- •Garanti rezervasyon: ödeme/koşul farkı nedeniyle iptal/no-show davranışı değişebilir
Bu kalemler net müsaitlik hesabına doğru oturmazsa, overbooking riski artar.
| Oda Tipi | Risk Seviyesi | Maks Satış Limiti | Stop-Sale Eşiği | Pik Gün Kuralı | Not |
|---|---|---|---|---|---|
| Standard Room | Düşük | Müsait havuzun büyük kısmı açık | Pickup pace anormal hızlanırsa kontrol | Gün içi 2 kontrol | Yüksek adetli tiplerde senkron takibi kritik |
| Family Room | Orta | Kontrollü satış limiti | Belirlenen eşiğe gelince kademeli kapama | Öğlen ek kontrol | Pik talepte hızlı tükenebilir |
| Junior Suite | Yüksek | Düşük maksimum limit | Son oda/son iki oda eşiğinde stop-sale | Gün içi sık log doğrulama | Mapping hatalarına karşı hassas |
| Executive / Premium Suite | Yüksek | Tekil satış disiplini | Erken kapama | Role bağlı onayla aç/kapat | Relocation maliyeti çok yüksek |
Mini Check (Önleme)
- • Oda tipi bazlı maksimum limitlerim var mı?
- • Stop-sale “kademeli” mi, panik kapama mı?
- • Opsiyon/allotment/garanti kayıtları doğru sınıflanıyor mu?
- • Pik günlerde kontrol saatleri ve sorumlular belli mi?
Ne yapmalıyım?
- • Oda tiplerini “risk seviyesine” göre 3 gruba ayırın (yüksek/orta/düşük).
- • Yüksek risk grubuna maksimum limit + stop-sale eşiği koyun.
- • Opsiyon/allotment kurallarını yazılı hale getirip CM’ye işleyin.
- • Pik günlerde “günlük kontrol checklist” uygulayın.
4. Talep Zirvelerinde Overbooking Yönetimi (Peak Demand Playbook)
Peak demand dönemlerinde risk artar çünkü pickup hızlanır, ekip baskılanır ve küçük senkron hataları büyür. Bu nedenle “pik gün modu” diye ayrı bir işletim modu tanımlamak gerekir.
Pik gün işletim modu (günlük rutin)
- •Sabah: PMS log + bugünkü check-in/out + blokaj kontrolü
- •Öğlen: pickup pace + limit eşiği kontrolü
- •Akşam: stop-sale doğrulama + kanallar arası tutarlılık kontrolü
Daha sık senkron ve kontrol
Senkronun teknik olarak anlık olması ideal; pratikte gecikme olabilir. Pik günlerde amaç, gecikmeyi “operasyonel kontrol”le tamponlamaktır.
Mini örnek (Belek – bayram dönemi)
Bayram döneminde Belek resortta “family room” hızla satarken, mapping hatası “junior suite”e kayabilir. Pik gün işletim modu, öğlen kontrolünde bu sapmayı yakalayıp stop-sale ve limit düzeltmesiyle krizi büyümeden keser.
Mini Check (Pik gün)
- • Pik günlerde kontrol saatleri belirli mi?
- • Pickup pace ile limit eşiğini birlikte izliyor muyum?
- • Stop-sale kararını kim veriyor net mi?
Ne yapmalıyım?
- • Pik gün SOP yazın (3 kontrol penceresi + sorumlular).
- • “Riskli oda tipi listesi”ni pik günlerde ayrı izleyin.
- • Stop-sale kararını bir kişiye değil, role bağlayın (revenue + ön büro onayı).
5. Overbooking Yaşandığında Misafir Memnuniyetini Nasıl Korursunuz?
Ne kadar iyi sistem kurarsanız kurun, ekstrem talep/teknik hata durumunda overbooking yaşanabilir. Bu noktada hedef, krizi “hasar büyüten” bir deneyim olmaktan çıkarıp “kontrollü telafi”ye çevirmektir.
Overbooking durumunda 5 adım
- Doğrula: PMS/CM/OTA verisini hızlı doğrula; gerçek durumu netleştir.
- Önceliklendir: garanti rezervasyon/uzun konak/özel ihtiyaç gibi durumlara göre öncelik ver.
- Alternatif hazırla: aynı segmentte alternatif otel + transfer planı.
- İletişimi yönet: sakin, çözüm odaklı dil; seçenekleri net anlat.
- Telafi et ve kaydet: telafi paketi + olay kaydı + kök neden aksiyonu.
Misafire yaklaşım dili (tartışma değil çözüm)
- •Suçlayıcı dil yok, “sistem hata verdi” diye detay boğma yok
- •Net seçenek: “Şu otelde şu oda + transfer + şu telafi”
- •Sonrasında: olay kaydı + tekrar yaşanmaması için aksiyon
Mini örnek (Kemer – çift misafir)
Balayı çifti relocation yaşarsa itibar riski büyür. Çözüm: aynı/üst segment alternatif + transfer + küçük telafi (ör. oda upgrade, akşam yemeği) + hızlı iletişim.
Key Statistics / Data Point (soft, senaryo): Doğru kurgulanmış limit ve stop-sale kurallarına sahip otellerde, overbooking kaynaklı şikâyet ve relocation maliyetlerinde anlamlı düşüş elde edilebildiği senaryo bazlı anlatılabilir.
Mini Check (Kriz)
- • 5 adım planım yazılı mı?
- • Alternatif otel listem güncel mi?
- • Olay kaydı ve kök neden aksiyon süreci var mı?
Ne yapmalıyım?
- • Alternatif otel/relocation anlaşmalarını sezon öncesi netleştirin.
- • Overbooking olay formu oluşturun (tarih, oda tipi, kök neden, maliyet).
- • Her olaydan sonra 48 saat içinde kök neden aksiyonu kapatın.
6. Overbooking Önleme & Kriz Yönetimi Kontrol Listesini İndir — Otel / Inventory
Overbooking Önleme & Kriz Yönetimi Kontrol Listesini İndir — Otel / Inventory (v1.0)
Bu asset, OTA kaynaklı overbooking riskini “günlük şans” olmaktan çıkarıp envanter kural tasarımı + pik gün rutini + kriz yönetimi olarak sistemleştirir. PMS–channel manager–OTA akışında tek kaynak prensibi, oda bazlı limit/stop-sale kuralları ve overbooking durumunda 5 adım yaklaşımıyla hem şikâyet hem relocation maliyetini azaltmayı hedefler.
Kim Kullanır?
Ön büro, rezervasyon, revenue, operasyon ve kanal yöneticisi (ajans dahil).
Nasıl Kullanılır?
- Envanter akışını doğrulayın (mapping + senkron + manuel müdahale yasağı).
- Oda bazlı limit/stop-sale kurallarını pik gün senaryolarıyla kurun.
- 5 adım kriz planını SOP haline getirip olay kaydıyla sürekli iyileştirin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Envanter tek kaynak: yalnız channel manager üzerinden yönetiliyor
- ▢ ✅ OTA extranet manuel müdahale SOP ile kapalı (istisna prosedürü var)
- ▢ ✅ Oda tipleri mapping denetimi tamamlandı
- ▢ ✅ Riskli oda tipleri için maksimum limit tanımlandı
- ▢ ✅ Stop-sale kademeli kapama kurgusu yazıldı
- ▢ ✅ Pik gün kontrol saatleri belirlendi (log + pickup + doğrulama)
- ▢ ✅ Opsiyon/allotment/garanti rezervasyon kuralları net
- ▢ ✅ Overbooking 5 adım misafir planı yazılı
- ▢ ✅ Alternatif otel/relocation listesi güncel
- ▢ ✅ KPI paneli: olay sayısı + relocation maliyeti + şikâyet + net ADR
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: Overbooking riski doğru kural tasarımıyla sistematik azaltılır
OTA kaynaklı overbooking, çoğu zaman “şanssızlık” değil; envanter akışı, mapping, limit ve kontrol rutmi eksikliğinin birleşimidir. Doğru yaklaşım, PMS–channel manager–OTA üçgeninde tek kaynak prensibi kurmak, riskli oda tipleri için limit/stop-sale kurgusu oluşturmak ve pik günleri ayrı bir işletim modu olarak yönetmektir.
Proper Inventory Rules → reduce → Overbooking Risk mantığıyla çalışan oteller, hem relocation ve şikâyet maliyetini düşürür hem de ekip stresini azaltır. Buna kriz anında devreye girecek 5 adım misafir planı, alternatif otel listesi ve KPI takibi eklendiğinde, overbooking riski operasyonel olarak kontrol altına alınabilir.
Bir Sonraki Adım
Envanter akışınızı, limit/stop-sale kurallarınızı ve pik gün rutinlerinizi çıkarıp 30 günlük risk azaltım planı alırsınız.
Sık Sorulan Sorular
Overbooking nedir, oteller için ne gibi sorunlar yaratır?▾
OTA üzerinden overbooking nasıl oluşur?▾
PMS ve kanal yöneticisi ile overbooking riski nasıl azaltılır?▾
Overbooking yaşandığında misafire nasıl yaklaşılmalı?▾
Stop-sale ne zaman uygulanmalı?▾
İlgili İçerikler
İlgili Yazılar