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.
Ö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)
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.
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.
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.
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.
İ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ı.
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
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