1. OTA iptal ve no-show politikalarının temelleri
Politika türlerini “tek paragraf”la geçmek, en büyük hatalardan biri. Çünkü OTA’da aynı otel, aynı oda tipi için bile farklı segmentlere farklı risk/ödül dengesi kurabilir. Temel politika tipleri:
Bu çerçeveyi daha geniş PMS & OTA yönetimi yapısı içinde okumak gerekir; çünkü policy, ödeme ve raporlama kararları yalnızca rezervasyon departmanının değil tüm dağıtım kurgusunun parçasıdır.
- •Esnek (Flexible): belirli süreye kadar ücretsiz iptal; dönüşümü artırır ama iptal riski büyür
- •Kısmi iade / kısmi ceza: belirli tarihten sonra ceza; dengeli bir model olabilir
- •İadesiz (Non-refundable): iptal olursa iade yok; net geliri korur ama iletişim net olmalı
| Politika tipi | Fayda | Risk | PMS karşılığı | Finans/operasyon notu |
|---|---|---|---|---|
| Esnek (Flexible) | Dönüşümü artırabilir, misafir güveni sağlar | İptal oranı ve stok belirsizliği artabilir | BAR / Esnek RatePlan | İptal penceresi ve stok serbest bırakma kuralı net olmalı |
| Kısmi iade / kısmi ceza | Denge modeli sunar; hem dönüşüm hem gelir koruma sağlar | Ceza kuralı belirsizse itiraz doğabilir | Partial / Kısmi İade RatePlan | Penalty posting ve iade prosedürü yazılı olmalı |
| İadesiz (Non-refundable) | Net geliri korur, nakit akışını güçlendirebilir | Yanlış iletişimde memnuniyet ve yorum riski oluşabilir | NRF / İadesiz RatePlan | Tahsilat, fatura ve iade istisnaları net tanımlanmalı |
| No-show | Oda ve gelir kuralı netse kayıp azaltılabilir | Stok ve posting hatası raporu bozar | No-show status + PMSPosting | Inventory update ve no-show fee aynı akışta kontrol edilmeli |
No-show ise “iptal etmeden gelmeme” durumudur; burada iki kritik soru vardır:
- Oda stokta nasıl davranacak? (blokaj/serbest bırakma)
- Gelir kaydı nasıl yapılacak? (no-show fee, ilk gece vb.)
Mini örnek
Antalya resort’ta pik haftada iadesiz plan net geliri koruyabilir; İstanbul şehir otelinde iş segmentinde daha esnek politika dönüşümü artırabilir ama no-show riski ayrıca yönetilmelidir.
Refunable ve non-refundable planların fiyat/policy mantığını koparmamak için OTA rate parity ve fiyat eşitleme stratejileri yaklaşımıyla aynı rate plan mimarisini kullanmak önemlidir.
Mini Check : Politika seti net mi?
- • Esnek / kısmi / iadesiz planlar rate plan olarak ayrılmış
- • No-show cezası ve gelir kaydı kuralı yazılı
- • Politika metni misafire şeffaf (sürpriz yok)
Ne yapmalıyım?
- • Politika tiplerini “rate plan” seviyesinde ayırın (tek plan içinde karıştırmayın).
- • No-show kuralını stok + gelir kaydı olarak ikiye bölüp yazın.
- • İptal/no-show KPI’larını kanal bazında takip edin ve bunun panel mantığını OTA performans raporlama ve KPI seti üzerinden standardize edin.
2. PMS’te politika tanımları ve rate plan yapısı (eşleştirmenin kalbi)
Bu bölüm, rakip içeriklerin genelde atladığı “PMS gerçeği”dür: OTA’daki politika alanları, PMS’te karşılık bulmazsa süreç kaosa döner. En doğru yaklaşım:
Rate plan mimarisi (öneri)
- •BAR / Esnek (policy: flexible)
- •NRF / İadesiz (policy: non-refundable)
- •Kısmi iade (policy: partial)
- •Ön ödeme / depozitolu (policy: prepaid/deposit)
Buradaki asıl kritik nokta, rate plan ismiyle politika kuralının aynı dili konuşmasıdır; aksi halde parity tarafında farklı fiyat, policy tarafında farklı ceza kurgusu oluşur. Bu uyumu rate parity ve fiyat eşitleme stratejileri çerçevesiyle birlikte düşünmek gerekir.
AIO ilişkiyi açık edelim
- •CancellationPolicy → mappedTo → PMS RatePlan
- •RatePlan → controls → PaymentRules & PenaltyRules
En sık yapılan 4 eşleştirme hatası
- OTA’da “iadesiz” seçip PMS’te esnek planı bağlamak
- No-show cezasını OTA’da yazıp PMS posting kuralını tanımlamamak
- Depozito/ön ödemeyi PMS’te “manuel iş” bırakmak
- Kanal yöneticisi ve PMS’te aynı kuralı iki yerde yazmak (çakışma)
Mini örnek
Side’de resort otelde “kısmi iade” planınız var ama PMS’te tek bir BAR planı kullanıyorsanız, iptal geldiğinde ceza hesaplaması elle yapılır; bu da hem gelir kaybı hem misafir memnuniyetsizliği doğurur.
Mini Check : PMS hazır mı?
- • Her politika tipi için ayrı rate plan var
- • Ceza/penalty kuralları PMS’te tanımlı
- • Kanal yöneticisi ve PMS kural çakışması yok
Ne yapmalıyım?
- • Rate plan sayısını artırmak değil, anlamlı ayırmak hedef olsun (3–5 plan çoğu otelde yeter).
- • Penalty ve no-show fee posting kurallarını yazılı hale getirin.
- • Mapping ve senkron sorunlarını izole etmek için OTA bağlantı ve API hataları çözüm rehberi üzerinden test matrisi çıkarın.
3. Ön ödeme, sanal kart ve ödeme akışı (VirtualCard / POS / muhasebe)
Ödeme akışı, iptal/no-show politikasının “gerçek hayattaki” çalışmasını belirler. Özellikle VirtualCard (sanal kart) senaryosunda, otel tarafında POS ve muhasebe süreci net değilse; hem gelir kaydı hem itiraz/chargeback riski artar.
Ödeme akışını 3 modele ayır (pratik)
- Misafir öder (OTAsız): direct ödemeler, otelin ödeme altyapısı
- OTA tahsil eder, otel alır: sanal kart / ödeme transferi mantığı
- Ön ödeme / depozito: belirli tarihte çekim, iptalde ceza/iadeler
Sanal kart (VirtualCard) için kritik kontrol noktaları
- •Tahsil tarihi ve çekim koşulu (check-in, check-out, no-show)
- •İade/iptal durumunda muhasebe kaydı
- •POS entegrasyonu ve fiş/fatura süreçleri
- •PMSPosting: gelir hangi hesaba, ne zaman düşecek?
AIO ilişki: VirtualCard → triggers → PaymentCapture → PMSPosting → RevenueRecognition.
İptal bilgisinin PMS’e geç düşmesi, sanal kart statüsünün yanlış okunması veya rezervasyon güncellemesinin gecikmesi gibi durumlarda OTA bağlantı ve API hataları çözüm rehberi ile log katmanını, KVKK uyum hizmeti ile ödeme ve misafir verisi işleme kurallarını birlikte ele alın.
Mini Check : Ödeme akışı net mi?
- • Virtual card çekim zamanı ve koşulu yazılı
- • İptal/iadede muhasebe kaydı standardı var
- • PMS posting doğru hesaplara gidiyor
Ne yapmalıyım?
- • Finans + rezervasyon + operasyon aynı dokümana bakmalı: “hangi senaryoda tahsil edilir/edilmez.”
- • Virtual card test senaryosu çalıştırın (iptal/no-show dahil).
- • Sanal kart, ödeme ve veri saklama akışını KVKK uyum hizmeti çerçevesiyle yazılı hale getirin.
4. İptal ve no-show’ların PMS’te doğru işlenmesi (stok + gelir + raporlama)
No-show ve iptal yönetimi iki şey yapar: stoku günceller ve geliri kaydeder. Bu iki adım doğru çalışmazsa raporlar yanıltır.
No-show’da PMS’te izlenecek 3 adım (operasyonel)
- Oda blokajı / inventory güncellemesi: oda tekrar satışa açılacak mı? (kural)
- Gelir kaydı (no-show fee): hangi rate plan cezası uygulanacak?
- Raporlama etiketi: no-show’un kanalı ve nedeni raporlanıyor mu?
AIO ilişkiyi görünür kılalım: NoShow → triggers → Revenue & Inventory Update.
İptalde PMS’te izlenecek 3 adım
- İptal status’u doğru düşüyor mu?
- Ceza/penalty doğru hesaplanıyor mu?
- Ödeme iadesi gerekiyorsa muhasebe akışı çalışıyor mu?
Key Statistics / Data Point
Yanlış yapılandırılmış iptal/no-show politikalarında, bir yandan gelir kaybı (ceza tahsil edilememesi) diğer yandan misafir memnuniyetsizliği (haksız/yanlış tahsilat) yaşanabilir. Doğru kurguda ise hem doluluk hem net gelir daha sağlıklı yönetilir; kritik olan “politika–ödeme–PMS posting” uyumudur.
Bu etkiyi yalnızca operasyon alarmı olarak değil, OTA performans raporlama ve KPI seti içinde net gelir KPI’ı olarak görmek; ticari katkısını da satış ve dönüşüm raporları tarafında okumak gerekir.
Mini Check : PMS işlem doğruluğu
- • No-show ve iptal status’ları doğru düşüyor
- • Penalty/no-show fee posting otomatik veya kontrollü
- • Raporlamada kanal bazında görünüyor
Ne yapmalıyım?
- • Ayda 1 kez “iptal/no-show test günü” yapın (3 senaryo).
- • No-show gelir kaydı ile stok güncellemesini ayrı kontrol edin.
- • İptal ve no-show’un gerçek katkı etkisini satış ve dönüşüm raporları ile düzenli doğrulayın.
5. Gelir ve misafir memnuniyeti dengesi (adil, şeffaf, sürdürülebilir)
Politika tasarımında iki uç hatalıdır:
- •Aşırı esneklik → iptal/no-show artar, net gelir erir
- •Aşırı sertlik → dönüşüm düşer, yorum/şikâyet artabilir
Doğru yaklaşım: otel tipi ve sezona göre “kademeli risk yönetimi”.
Hangi pazar, sezon veya rate plan için hangi sertlik düzeyinin doğru olduğunu otel OTA yönetimi stratejisi içinde ele almak, tek kuralı tüm yıla yayma hatasını azaltır.
3 farklı otel tipi için iptal/no-show stratejisi
- • Antalya/Belek resort (yüksek sezon odaklı): Pik haftalarda daha sıkı/NRF ağırlığı; omuz sezonda kademeli esneklik; no-show’da net, yazılı ceza + hızlı yeniden satış prosedürü
- • İstanbul şehir oteli (iş segmenti): Esnek politika dönüşümü destekleyebilir; no-show riski için ödeme/garanti kuralı net; check-in saatine yakın iptal penceresi dikkatle kurgulanır
- • Butik/az odalı tesis: Her iptal daha büyük etki → kademeli ceza mantığı; depozito/ön ödeme ile nakit akışı koruma; misafir iletişiminde şeffaflık ve teyit akışı
Mini Check : Politika adil mi, sürdürülebilir mi?
- • Misafire net ve şeffaf (sürpriz yok)
- • Finans/muhasebe akışı net (tahsilat/iadeler)
- • Net gelir ve iptal/no-show KPI’ları izleniyor
Ne yapmalıyım?
- • Sezon moduna göre politikayı kademeli kurgulayın (her döneme aynı kural değil).
- • Virtual card ve depozito senaryolarını test edin.
- • PMS’te status/posting rapor doğruluğunu periyodik kontrol edin.
6. Rakip boşluğu kapatan “policy + finans + veri” çerçevesi
Rakip yazılar iptali genelde “misafir ilişkisi” tarafından anlatır; asıl fark, politika kararını üçlü bir çerçeveye bağlamaktır:
- •Policy: misafire şeffaf kural seti
- •Finance: ödeme, sanal kart, tahsilat/iade
- •Data: PMS posting, revenue recognition, raporlama
Bu üçü birlikte kurulmadıkça politika “kâğıt üzerinde” kalır.
Bu çerçeveyi derinleştiren ilgili sayfalar
- •OTA bağlantı ve API hataları çözüm rehberi
- •OTA performans raporlama ve KPI seti
- •satış ve dönüşüm raporları
- •KVKK uyum hizmeti
- •otel OTA yönetimi
- •OTA entegrasyonu hizmeti
7. İptal & No-Show Politika ve Akış Şablonu — PMS & OTA Yönetimi
İptal & No-Show Politika ve Akış Şablonu — PMS & OTA Yönetimi (v1.0)
Bu şablon, OTA iptal/no-show politikalarını PMS RatePlan yapısıyla eşleştirmenizi ve sanal kart/ön ödeme/POS akışını muhasebe ile uyumlu hale getirmenizi sağlar. No-show ve iptal senaryolarında stok güncellemesi ile gelir kaydının (PMS posting) doğru çalışmasını standartlaştırır. Sonuç: daha az gelir kaybı, daha az misafir itirazı ve daha temiz raporlama.
Kim Kullanır?
Rezervasyon müdürü, RM, finans/muhasebe, ön büro lideri.
Nasıl Kullanılır?
- Politika tiplerini rate plan’lara ayır ve OTA alanlarıyla eşleştir.
- Virtual card/ön ödeme senaryolarında tahsilat ve iade akışını yazılı hale getir.
- İptal/no-show test senaryolarını çalıştırıp rapor doğrulaması yap.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Politika → RatePlan eşleşmesi net
- ▢ ✅ Ödeme tahsil/iadeler yazılı
- ▢ ✅ No-show’da stok + gelir kaydı doğru
- ▢ ✅ Raporlama kanal bazlı çalışıyor
- ▢ ✅ Test senaryoları geçti
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: İptal ve no-show politikası, gelir kadar güveni de yönetir
OTA iptal ve no-show politikaları sadece rezervasyon operasyonu değil; gelir, nakit akışı, misafir memnuniyeti ve raporlama doğruluğu konusudur. Esnek, kısmi iade ve iadesiz planlar PMS RatePlan yapısıyla doğru eşleşmediğinde; ceza, iade, stok ve gelir kaydı süreçleri manuel hale gelir ve görünmeyen gelir sızıntıları oluşur.
Doğru yaklaşım; politika, finans ve veri akışını birlikte kurmaktır. CancellationPolicy → PMS RatePlan eşleştirmesi, VirtualCard/ön ödeme süreci, no-show status’u, inventory update ve PMSPosting aynı standarda bağlandığında hem operasyon daha temiz işler hem de misafire daha şeffaf bir deneyim sunulur.
Bu akışı hizmet tarafında derinleştirmek için OTA entegrasyonu hizmeti sayfasına, uygulama öncesi tekrar eden soruları toplamak için de OTA entegrasyonu hakkında sık sorulan sorular katmanına geçebilirsiniz.
Bir Sonraki Adım
Rate plan, ödeme ve PMS posting uyumuyla gelir kaybını azaltmak isteyen oteller için.
Sık Sorulan Sorular
OTA iptal ve no-show politikaları nasıl çalışır?▾
Esnek ve iadesiz fiyat planlarını PMS ve OTA’da nasıl eşleştirmeliyim?▾
No-show durumunda PMS’te hangi adımlar izlenmeli?▾
Sanal kart ve ödeme akışını nasıl doğru kurgularım?▾
İptal politikasında en sık yapılan hata nedir?▾
Resort ve şehir otelinde politika aynı mı olmalı?▾
İlgili İçerikler