1. Ön Ödeme, Depozito ve Ön Provizyon Kavramları

Kavramların karışması, süreçlerin karışması demektir. İlk adım; üç modeli net ayırmaktır.
Bu yaklaşım, daha geniş PMS & OTA yönetimi yapısı içinde, özellikle pre-arrival iletişim ve rezervasyon onay akışı boyunca ödeme şartlarının ne zaman, hangi kanaldan ve hangi tonla aktarılacağını belirleyen bir rezervasyon ödeme politikasıdır.
Ön ödeme, depozito ve ön provizyon arasındaki fark nedir?
- •Ön ödeme (Prepayment): rezervasyon anında tahsilat yapılır.
- •Depozito (Deposit): belirli bir tutar/ oran garanti edilir; tahsilat koşulu politikaya bağlıdır.
- •Ön provizyon (Preauthorization): karttan geçici blokaj alınır; check-in’de tahsilata çevrilir veya serbest bırakılır.
| Model | Ne olur? | En iyi nerede? | Risk | Güçlü yanı |
|---|---|---|---|---|
| Ön ödeme | Tahsilat hemen | İadesiz / yüksek talep | İade tartışması | Gelir güvence |
| Depozito | Garanti tutar | Esnek ama riskli dönem | Takip zayıflığı | Esneklik + güvence |
| Ön provizyon | Blokaj | City/iş segmenti, hızlı check-in | Blokaj düşürme hatası | Tahsilat esnekliği |
Kavram Karşılaştırma Tablosu (pratik)
Mini Check
- • Ekip “blokaj” ile “tahsilat” farkını biliyor mu?
- • Depozito hangi koşulda tahsil/iadeye gider net mi?
- • Ön provizyonun düşürme (release/capture) adımı tanımlı mı?
- • Misafir iletişim metinleri hazır mı?
- • Raporlar modeli doğru ayırıyor mu?
Ne yapmalıyım?
- • 3 modeli tek sayfalık sözlükle yayınla
- • Her modelin “iptal/no-show” sonucunu yazılılaştır
- • Misafire açıklama cümlesini standardize et
- • POS entegrasyonu yoksa ön provizyonu sınırlı kullan

2. Hangi Rezervasyon Tipinde Hangi Model?
Model seçimi “tek doğru” değildir; fiyat planı ve risk profilinin fonksiyonudur.
Özellikle sözleşmeli segmentlerde, kurumsal ve acente fiyat kodları ile tanımlanan farklı kural setleri; hangi rezervasyonda ön ödeme, hangisinde depozito ya da ön provizyon kullanılacağını doğrudan etkiler.
Hangi rezervasyon tipinde ön ödeme, hangisinde depozito kullanmalıyım?
- •İadesiz / çok yüksek talep tarihler: ön ödeme (gelir koruma öncelikli)
- •Esnek plan + orta risk: depozito (garanti + esneklik)
- •City/iş segmenti + hızlı check-in + kurumsal: ön provizyon (blokaj → check-in’de netleştirme)
- •Grup/kurumsal: depozito + takvimli tahsilat (varsayımsal iyi pratik)
| Fiyat Planı | Önerilen model | Tahsilat zamanı | İptal/no-show kuralı | Misafir mesajı (kısa) |
|---|---|---|---|---|
| İadesiz | Ön ödeme | Rezervasyon anı | İade yok / koşullu | “Fiyat avantajı karşılığı iadesiz” |
| Esnek | Depozito | D-7 / D-3 | Politikaya bağlı | “Tarihe göre depozito alınır” |
| Kurumsal | Ön provizyon | Check-in öncesi | Blokaj + tahsilat | “Karttan geçici blokaj” |
| OTA sanal kart | Kanal kuralı | OTA akışına bağlı | OTA kuralı | “Kanal koşulu geçerli” |
Varsayım: “D-7/D-3” günleri otelinize göre farklılaşır; amaç zamanlama mantığını netleştirmektir.
Fiyat Planına Göre Örnek Ödeme Koşulları (şablon)
Ne yapmalıyım?
- • Her rate plan için ödeme modelini dokümante et
- • Call center ve ön büro için “tek cümle açıklama” üret
- • Ödeme başarısızlığında SOP yaz (tekrar deneme/iletişim/iptal)
- • Grup sözleşmelerinde tahsilat takvimini netleştir
3. PMS ve POS/Ödeme Sistemleriyle Entegrasyon
Politika ne kadar iyi olursa olsun, entegrasyon zayıfsa operasyon dağılır: tahsilat kaydı PMS’e düşmez, iade takibi kopar, rapor şaşar. Bu yüzden PMS–POS akışı en az politika kadar önemlidir.
PMS ve POS/ödeme sistemleriyle bu süreçler nasıl entegre edilir?
Özet akış: rezervasyon oluşur → ödeme modeli seçilir → POS’ta tahsilat/blokaj yapılır → PMS’e ödeme durumu işlenir → iptal/no-show olursa politika uygulanır → iade/ceza kaydı rapora düşer. Kritik nokta; her adımın “tek kayıt” ve “audit trail” ile izlenmesidir.
Rezervasyon OTA kaynaklıysa sanal kart, garanti tipi ve ödeme kuralının PMS’e doğru düşmesi için OTA entegrasyonu tarafındaki policy mapping ve ödeme alanları da tutarlı çalışmalıdır.

Sanal kart ve banka POS akışı (pratik not)
- •OTA sanal kartlarında tahsilat penceresi ve koşullar kanala bağlıdır.
- •Direct ödemede POS capture/refund adımları otelin SOP’una bağlıdır.
- •Ön provizyonda “blokajı düşürme/çekme” adımı unutulursa hem misafir hem rapor zarar görür.
Mini Check (Entegrasyon)
- • Ödeme sonucu PMS’e doğru düşüyor mu?
- • İade/ceza kaydı raporda ayrı görünüyor mu?
- • Ön provizyon release/capture adımı SOP’da mı?
- • Sanal kart pencereleri ekipçe biliniyor mu?
- • Muhasebe–rezervasyon–ön büro sorumlulukları net mi?
Ne yapmalıyım?
- • Ödeme akışını 1 sayfa süreç haritası yap
- • POS işlemlerinde “referans no” standardı koy
- • Ön provizyon için günlük kontrol rutini oluştur
- • Raporlama için ödeme türlerini kodla (PREPAY/DEP/PREAUTH)
4. İptal ve No-Show Durumunda Sürecin Yönetimi
Ödeme modeli ile iptal/no-show yönetimi birbirine kilitlidir. Burada amaç “ceza kesmek” değil; politika neyse onu şeffaf ve tutarlı uygulamaktır.
Koşullar misafire eksik ya da muğlak anlatıldığında süreç kolayca rezervasyon uyuşmazlıkları ve şikâyet yönetimi başlığına taşınır; bu yüzden politika kadar anlatım dili de standartlaştırılmalıdır.
İptal ve no-show durumunda tahsilat ve iade nasıl yönetilmeli?
- •Ön ödeme: politika gereği iade/iadeye dönüş (tam/partial) net olmalı.
- •Depozito: depozitonun iade edilip edilmeyeceği ve hangi koşulda tahsilata döneceği yazılı olmalı.
- •Ön provizyon: no-show veya geç iptalde capture (tahsil) şartları net; normal iptalde release (blokaj düşürme) zorunlu olmalı.
Bu etkinin rezervasyon bazında gerçekten çalışıp çalışmadığı, no-show, iade yükü ve net gelir etkisini ayrı kırılımlarda gösteren satış ve dönüşüm raporları ile izlenmelidir.

Ne yapmalıyım?
- • İptal/no-show için 3 net karar ağacı yaz (prepay/dep/preauth)
- • Misafire bilgilendirme şablonu hazırla (kısa, net)
- • İade süreleri ve kanalları (banka/pos) SOP’a bağla
- • No-show işleme saatini ve sorumlusunu netleştir

5. Antalya & City Otel Örnekleri (Resort vs İstanbul)
Antalya/Belek resort — yüksek sezon + paket
- •İadesiz planlarda ön ödeme yaygın; iptal dalgası riskini düşürür.
- •Depozito modelinde D-7/D-3 gibi takvimler sezon yoğunluğuna göre kısalabilir.
- •Misafir iletişiminde “şeffaf koşul + fayda (fiyat avantajı)” dili önemlidir.
İstanbul city — iş segmenti + hızlı revizyon
- •Ön provizyon, hızlı check-in ve esneklik sağlayabilir.
- •Kurumsal ve kısa stay’de blokaj–tahsil netliği ve rapor disiplini kritiktir.
6. Fark Yaratan Mini Bölüm: Politika Metni Değil Operasyon Akışı (Competitor Gap)
Rakip içerikler çoğu zaman hukuki/muhasebe dilinde kalır; sahada ise rezervasyon–muhasebe–yönetim üçlüsünün aynı masada karar verip uygulaması gerekir. Bu rehberin farkı; ödeme modelini PMS & POS entegrasyonu, iptal/no-show senaryosu ve misafir iletişimi ile birlikte ele almasıdır. Böylece politika toplantıları için “tek referans doküman” haline gelir.

7. Ön Ödeme / Depozito & Ön Provizyon Akış Şablonunu İndir — Ödeme Politikası
Ön Ödeme / Depozito & Ön Provizyon Akış Şablonunu İndir — Ödeme Politikası (v1.0)
Bu şablon, ön ödeme–depozito–ön provizyon modellerini fiyat planlarına göre eşleyip PMS–POS entegrasyon akışını standartlaştırır. Amaç; tahsilat ve iade süreçlerini hem misafir hem otel için şeffaf hale getirmek, iptal/no-show gelir korumasını artırmak ve rapor sapmalarını azaltmaktır. “Politika toplantıları” için tek sayfalık karar çerçevesi sunar.
Kim Kullanır?
Rezervasyon + muhasebe/finans + revenue/online satış.
Nasıl Kullanılır?
- Rate plan’ları listele ve her biri için ödeme modelini seç.
- POS adımlarını (tahsilat/blokaj/iade) akışa bağla; sorumluları ata.
- İptal/no-show karar ağacını uygula ve misafir iletişim şablonlarını kullan.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Her rate plan için model belirlendi
- ▢ ✅ POS referans no standardı var
- ▢ ✅ Preauth release/capture SOP yazılı
- ▢ ✅ İade süreleri ve sorumlular net
- ▢ ✅ Raporlama kodları tutarlı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu


8. Sonuç: Doğru ödeme politikası geliri korurken misafir güvenini de güçlendirir
Ön ödeme, depozito ve ön provizyon; yalnız finansal araçlar değil, rezervasyonun güvence seviyesini, no-show riskini ve misafirle kurulan beklenti çerçevesini belirleyen operasyon kararlarıdır.
Süreci hizmet tarafında derinleştirmek için rezervasyon yönetimi hizmeti sayfasına, uygulama detaylarını hızlıca gözden geçirmek için de rezervasyon yönetimi hakkında sık sorulan sorular katmanına geçebilirsiniz.
Bir Sonraki Adım
Fiyat planlarına göre doğru ödeme modelini seçip PMS–POS entegrasyonunu netleştirerek geliri korur ve iade tartışmalarını azaltır.
Sık Sorulan Sorular
Ön ödeme, depozito ve ön provizyon arasındaki fark nedir?▾
Hangi rezervasyon tipinde ön ödeme, hangisinde depozito kullanmalıyım?▾
İptal ve no-show durumunda tahsilat ve iade nasıl yönetilmeli?▾
PMS ve POS/ödeme sistemleriyle bu süreçler nasıl entegre edilir?▾
Ön provizyonun en sık hatası nedir?▾
İlgili İçerikler
