1. Çok Kanallı Rezervasyon Yapısı Nedir?
Çok kanallı rezervasyon yapısı; farklı satış kanallarından (OTA, web sitesi, çağrı merkezi, walk-in) gelen rezervasyonların PMS’te tek bir PMSReservation kaydına dönüştüğü, her kaydın Channel + SourceCode ile etiketlendiği ve bu etiketlerin hem raporlama hem de risk kontrolü için kullanıldığı modeldir. Bu modelde amaç “kanalları çoğaltmak” değil; kanallar çoğalırken operasyonun ve verinin dağılmamasıdır.
Çok kanallı rezervasyon yönetimi nedir?
Çok kanallı rezervasyon yönetimi; OTA, web ve çağrı merkezi rezervasyonlarını PMS’te doğru source kodlarıyla birleştirip, kanal bazlı raporlamayı netleştirerek overbooking/çift satış riskini envanter kurallarıyla kontrol etmektir.
☑ Mini Check (Tanım netliği)
- • PMS’te “Channel” ve “SourceCode” alanı var mı/aktif mi?
- • Her kanal için tekil ve anlaşılır source kodları tanımlı mı?
- • Aynı rezervasyonun “kaynağı” raporlarda güvenilir mi?
- • Web/OTA envanter okuması birbiriyle tutarlı mı?
- • Çakışma ve overbooking için günlük risk raporu var mı?
Ne yapmalıyım?
- • 1 sayfalık “Kanal & Source Kod Sözlüğü” çıkar
- • Mapping kontrolü: oda tipi + rate plan + politika eşleşmesi yap
- • Raporlarda “direct vs OTA” ayrımını source koduna bağla
- • Envanter koruma kuralları belirle (buffer, stop-sell, min stay vb.)
- • Günlük risk kontrol rutini (alarm listesi) oluştur
2. OTA, Web ve Çağrı Merkezi Kanallarının Rolü
Çok kanallı yapıda kanalların rolü aynı değildir. Her kanal, farklı hız ve veri kalitesiyle gelir; bu yüzden PMS’te “hepsi aynı” gibi davranmak hata üretir. Rolü netleştirmek, doğru source kodu vermek kadar kritiktir.
OTA (Online Travel Agencies)
OTA rezervasyonları çoğunlukla otomatik düşer ve genelde “onaylı” statüyle gelir. Avantaj; hacim ve hızdır. Riskler; yanlış mapping, iptal/no-show politikalarının tutarsız uygulanması, komisyon kaynaklı net gelir okumalarının yanlış yapılmasıdır. Antalya/Alanya gibi yüksek doluluk dönemlerinde OTA overbooking riski, yanlış stop-sell veya yanlış allotment ile büyüyebilir.
Web (Direct / Website Booking Engine)
Web rezervasyonu, direct gelir için en değerli kanaldır; fakat web motoru–PMS–channel manager senkronu doğru değilse “fiyat/müsaitlik” tarafında kayma olur. Ayrıca kampanya kodları, paketler ve ödeme akışı daha çok varyasyon üretir; bu yüzden source kodu kadar “rate plan disiplini” önemlidir.
Çağrı Merkezi (Call Center / Reservation Desk)
Çağrı merkezi rezervasyonları genellikle manuel açılır; bu da hem veri kalitesi hem de hız açısından risk taşır. Fakat doğru süreçle çağrı merkezi; upsell, özel istek yönetimi ve yüksek değerli lead kapamada güçlüdür. Burada kritik nokta: çağrı merkezinin açtığı opsiyonların PMS’te doğru source + doğru statü ile yaşaması.
☑ Mini Check (Kanal rolü)
- • OTA rezervasyonları otomatik düşüyor mu, manuel müdahale nerede?
- • Web motoru senkron gecikmesi için buffer kuralı var mı?
- • Çağrı merkezi için zorunlu alan seti ve form var mı?
- • Kanal bazlı iptal/no-show kuralları net mi?
- • Her kanalın rapor sorusu net mi (hacim mi, marj mı, hız mı)?
Ne yapmalıyım?
- • OTA: mapping ve stop-sell kurallarını sezon öncesi test et
- • Web: rate plan sözlüğünü sadeleştir, kampanya varyasyonlarını kontrol et
- • Call center: zorunlu alan seti + opsiyon SLA + kapanış rutini yaz
- • Tüm kanallar: source kod sözlüğünü aynı terminolojiyle kullan
3. PMS’te Kanal Kodları ve Kaynak Takibi (Source Codes)
Buradaki temel problem şudur: Birçok otel, “rezervasyon kaynağını” PMS’te ya hiç tutmaz ya da tutsa bile tutarsız tutar. Sonuç: raporda direct/OTA ayrımı yanlış çıkar, gelir yönetimi yanlış karar alır, ekipler birbirini suçlar. Çözüm: Channel + SourceCode mimarisi.
OTA, web ve çağrı merkezi rezervasyonlarını PMS’te nasıl ayırt ederim?
PMS’te her rezervasyona “Channel” (OTA/Web/Call Center) ve bunun altında standart “SourceCode” (örn. OTA_BKG, WEB_BE, CC_INBOUND) atayarak ayırt edersiniz. Bu kodlar, raporlamada tek filtre olur; ayrıca risk yönetimi (çakışma, overbooking, mapping hatası) için alarm koşulları tanımlarsınız.
Kanal kodları (source) nasıl tanımlanmalı?
İyi bir source kod sistemi:
- •Kısa ve okunur olmalı (ekip kolay öğrenmeli)
- •Tutarlı hiyerarşi içermeli (OTA_, WEB_, CC_*)
- •Rapor ihtiyacına hizmet etmeli (direct vs OTA, inbound vs outbound)
- •Tek anlama gelmeli (aynı kod iki farklı şeyi anlatmamalı)
Aşağıdaki örnek tablo, pratik bir “source kod sözlüğü” başlangıcıdır.
| Channel | SourceCode | Açıklama | Kim kullanır? | Rapor sorusu |
|---|---|---|---|---|
| OTA | OTA_BKG | Booking.com rezervasyonu | Sistem (otomatik) | OTA hacim & komisyon etkisi |
| OTA | OTA_EXP | Expedia rezervasyonu | Sistem (otomatik) | OTA payı & iptal oranı |
| Web | WEB_BE | Booking engine direct | Sistem (otomatik) | Direct gelir & dönüşüm |
| Web | WEB_FORM | Web form lead (manuel onay) | Rezervasyon ekibi | Lead→onay dönüşümü |
| Call Center | CC_IN | Inbound çağrı | Rezervasyon/CC | Hız & kapanış oranı |
| Call Center | CC_OUT | Outbound takip/geri arama | Rezervasyon/CC | Takip verimliliği |
| Walk-in | WI_FD | Walk-in front desk | Ön büro | Overbooking riski & anlık stok |
| Corporate | CORP | Kurumsal anlaşmalı | Rezervasyon/Gelir | ADR ve doluluk dengesi |
Mini Check (Source kod yönetişimi)
- • Source kod listesi yazılı mı ve ekipte paylaşıldı mı?
- • Kodlar PMS’te dropdown olarak seçilebilir mi?
- • “Boş source” rezervasyon oranı takip ediliyor mu?
- • Kodlar sezon içinde değiştirilmiyor mu (disiplin var mı)?
- • Raporlar source kodu “tek filtre” olarak kullanıyor mu?
Ne yapmalıyım?
- • 10–20 kodla başla, sonra genişlet (en başta yüzlerce kod açma)
- • Kod hiyerarşisini sabitle: OTA_* / WEB_* / CC_* / WI_*
- • Call center manuel girişte source’u zorunlu yap
- • Haftalık “boş/yanlış source” raporu çıkar
4. Overbooking ve Çift Satış Riskini Azaltmak (Inventory + Risk Control)
Çok kanallı yapıda risk tek cümleyle özetlenir: aynı envanteri iki farklı sistem aynı anda satarsa overbooking çıkar. Bunu sıfırlamak çoğu otelde gerçekçi değildir; hedef “riskin görünür ve yönetilebilir” olmasıdır.
Overbooking riskini pratikte hangi kaldıraçlarla düşürürüm?
Aşağıdaki kaldıraçlar, PMS + channel manager + web motoru üçlüsünde uygulanır:
- Buffer (Güvenlik stoğu): Özellikle yüksek sezon ve yüksek iptal dalgalanmasında, belirli oda tiplerinde “satılabilir stok”tan küçük bir payı tampon olarak ayırmak.
- Stop-sell kuralları: Kritik oda tiplerinde belirli koşullarda satış kapatma (örn. son 1 oda kaldıysa OTA kapat, web açık bırak).
- Rate plan disiplinı: Çok fazla rate plan, mapping ve fiyat hatasını artırır; sadeleştirme risk azaltır.
- Minimum stay / CTA (close to arrival): Sezon yönetimi için, yanlış yerde uygulanırsa “talep kaçırma” üretir; doğru yerde uygulanırsa risk ve gelir dengesini kurar.
- Çakışma alarmı: Günlük “çifte satış adayı” listesi (aynı oda tipi–aynı tarih) erken uyarı sağlar.
Key Statistics / Data Point (yumuşatılmış veri dili):
Kanal/source kod yapısı oturduğunda, birçok tesiste “hangi rezervasyon nereden geldi?” sorusu saniyelere iner ve raporlama hataları belirgin biçimde azalır; direct vs OTA performansını okumak ve stratejiyi değiştirmek çok daha kolay hale gelir.
☑ Mini Check (Risk kontrol rutini)
- • “Son 5 oda” gibi kritik eşiklerde stop-sell kuralı var mı?
- • Buffer kuralı oda tipine göre tanımlı mı?
- • Mapping hatası için kontrol listesi var mı?
- • Günlük çakışma/overbooking aday raporu çalışıyor mu?
- • Walk-in girişleri anlık PMS’e giriliyor mu?
Ne yapmalıyım?
- • Antalya/Belek/Side/Kemer/Bodrum gibi yüksek sezon bölgelerinde “kritik oda tipleri” listesi çıkar
- • Kritik oda tiplerinde buffer + stop-sell kombinasyonu uygula
- • Günlük risk raporunu (10 dk) bir kişiye sorumluluk olarak ata
- • “En çok hata veren 3 mapping”i tespit et ve düzelt
5. Antalya & City Otel Örnekleri (Resort vs İstanbul)
GEO gereksinimini “spam” yapmadan, iki farklı işletme gerçekliği üzerinden düşünmek faydalı: Antalya–Alanya hattında yüksek sezon ve paketli konaklama baskısı; İstanbul’da daha kısa kalış, kurumsal ve hafta içi dalga.
Senaryo 1: Antalya / Belek resort — OTA hacmi yüksek
- •OTA rezervasyonları hızla gelir; iptal dalgası da yüksektir.
- •Risk: son oda satışı ve yanlış stop-sell, overbooking’i büyütür.
- •Çözüm: OTA source kodları net, kritik oda tipleri için buffer + son-oda kuralı, günlük çakışma raporu.
Senaryo 2: Side / Kemer — Web kampanya + çağrı merkezi upsell
- •Web’den kampanya ile talep gelir, ardından çağrı merkezi oda yükseltir.
- •Risk: çağrı merkezi ayrı kayıt açar; source karışır; rapor bozulur.
- •Çözüm: tek PMSReservation üzerinde “modification/upsell” ve source disiplini (WEB_BE + CC_IN ilişkilendirme notu).
Senaryo 3: Bodrum — Kanal karışımı + kısa konaklama
- •Çok kanal var, stay kısa; hız önemli.
- •Risk: senkron gecikmesi + opsiyon disiplinsizliği.
- •Çözüm: web senkron buffer, opsiyon SLA, “boş source” raporu.
Senaryo 4: İstanbul city — Kurumsal + çağrı merkezi ağırlığı
- •Kurumsal anlaşmalar ve hızlı check-in baskısı.
- •Risk: rate plan karmaşası ve yanlış kodlama; direct performans yanlış okunur.
- •Çözüm: CORP source kodu ve rate plan sözlüğü sadeleştirme + haftalık rapor rutini.
Ne yapmalıyım?
- • Resort’ta (Antalya/Belek/Alanya) kritik oda tiplerine özel risk kuralları tanımla
- • City’de (İstanbul) rate plan sadeleştir, kurumsal source kodlarını netleştir
- • Her iki modelde: günlük risk raporu + haftalık source doğruluk raporu
6. 90 Günde Çok Kanallı Rezervasyon Yapınızı Toparlamak İçin 7 Adım
Bu kutu, yöneticiler için “başlangıç planı”dır; 90 gün sonunda hedef; source kod disiplininin oturması, mapping hatalarının düşmesi, raporların güvenilir hale gelmesidir.
- Kanal envanter haritasını çıkar: OTA’lar, web motoru, çağrı merkezi, walk-in, kurumsal.
- Source kod sözlüğünü yaz ve PMS’e uygula: 10–20 kodla başla.
- Mapping kontrolü yap: oda tipi, rate plan, politika eşleşmeleri.
- Envanter koruma kuralları tanımla: buffer, stop-sell, kritik eşikler.
- Günlük risk raporu kur: çakışma/overbooking aday listesi (10 dk rutin).
- Haftalık rapor rutini kur: direct vs OTA, kanal bazlı gelir/doluluk, “boş/yanlış source” oranı.
- Eğitim + denetim: çağrı merkezi ve ön büro için zorunlu alanlar ve örnek senaryolar.
7. Fark Yaratan Mini Bölüm (AI Competitor Gap Notes → Kapatma)
Rakip içerikler çok kanallı yapıyı çoğu zaman “satış/pazarlama” diliyle anlatır; fakat otelin gerçek problemi PMS içindeki source kodları ve bununla bağlı risk yönetimi + rapor doğruluğudur. Bu içerikte farkı yaratan şey:
- •Source kod sözlüğü (yönetişim)
- •Mapping kontrol listesi (teknik doğruluk)
- •Envanter koruma kuralları (risk kontrol)
- •90 gün/7 adım plan (uygulama)
8. Source Kodları & Kanal Takibi Planlama Şablonunu İndir — PMS & OTA Yönetimi (v1.0)
Source Kodları & Kanal Takibi Planlama Şablonunu İndir — PMS & OTA Yönetimi (v1.0)
Bu şablon, OTA/web/çağrı merkezi/walk-in ve kurumsal kanalları PMS’te source kodlarıyla standartlaştırmak için tek sayfalık bir planlama dokümanı sunar. Amaç; hem raporlamada direct vs OTA performansını doğru okumak, hem de overbooking/çift satış riskini yönetmek için gerekli kontrol rutinlerini kurumlaştırmaktır. 90 gün içinde uygulanacak aksiyonları sorumlu–SLA–kontrol metrikleriyle birleştirir.
Kim Kullanır?
Gelir yönetimi + rezervasyon lideri + ön büro müdürü + çağrı merkezi lead’i (ajans/teknoloji partneriyle birlikte).
Nasıl Kullanılır?
- Kanal envanterini ve sistemleri yaz (PMS, channel manager, web engine, call center).
- Source kod sözlüğünü doldur ve PMS’te dropdown/kurallarını uygula.
- Haftalık rapor ve günlük risk kontrol rutinini şablona göre işlet.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kodlar okunur olsun: OTA_BKG, WEB_BE, CC_IN gibi.
- ▢ ✅ Kod sayısını başta az tut (10–20); öğrenildikçe genişlet.
- ▢ ✅ “Boş source” bıraktırma: call center/ön büro için zorunlu alan yap.
- ▢ ✅ Raporu source koduna bağla: direct/OTA ayrımı tek filtreden çıksın.
- ▢ ✅ Risk kontrolü için tetikleyici yaz: son-oda eşiği, buffer, stop-sell net olsun.
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Source kod kurgusu, mapping ve envanter risklerini netleştirip 90 günlük uygulama planı çıkarır (kim için: resort/city otel yöneticileri ve operasyon liderleri).
Sık Sorulan Sorular
Çok kanallı rezervasyon yönetimi nedir?▾
OTA, web ve çağrı merkezi rezervasyonlarını PMS’te nasıl ayırt ederim?▾
Kanal kodları (source) nasıl tanımlanmalı?▾
Çok kanallı yapıda overbooking riskini nasıl azaltırım?▾
Web motoru–PMS senkron gecikmesi neye yol açar?▾
Çağrı merkezi rezervasyonlarında en sık hata nedir?▾
Direct vs OTA performansını doğru okumak için ne şart?▾
Antalya gibi yüksek sezonda hangi kural kritik?▾
İlgili İçerikler
İlgili Yazılar