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:
- •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.
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 (raporlama linki: /raporlama/satis-donusum).
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)
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.
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.
- • Rezervasyon yönetimi sayfasına referans: https://dgtlface.com/tr/pms-ota/rezervasyon-yonetimi
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.
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).
- • KVKK/veri uyumu perspektifi için referans: https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
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.
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.
- • Satış-dönüşüm raporlama linki: https://dgtlface.com/tr/raporlama/satis-donusum
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”.
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ışı
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.
İç linkler (otorite güçlendirme)
- •https://dgtlface.com/tr/pms-ota/rezervasyon-yonetimi
- •https://dgtlface.com/tr/raporlama/satis-donusum
- •https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti
- •https://dgtlface.com/tr/pms-ota-yonetimi
- •https://dgtlface.com/tr/pms-ota/ota-entegrasyonu
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.
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