1. PMS & OTA entegrasyonu neden önemli?
PMS “oda, fiyat, müsaitlik ve rezervasyon kartı”nın tek kaynağıdır; OTA ise talebin ve rezervasyonun önemli bir kısmının geldiği dağıtım kanalıdır. 4 dilli çağrı merkezi bu ikisini aynı operasyon standardında birleştirmezse, agent’lar kanallar arasında “göz kararı” ilerler: bir yanda OTA mesajları, diğer yanda telefon/WhatsApp talepleri… Sonuç; yanlış müsaitlik, gecikmiş yanıt, çift kayıt ve en kritik risk: overbooking.
Özellikle resort bölgelerde sezon piklerinde iki senaryo çok görülür: 1. OTA’dan “müsaitlik sorusu” gelir, aynı anda telefonda başka bir agent aynı oda tipini sözlü opsiyonlar. 2. WhatsApp’ta “ön rezervasyon” diye işaretlenen talep PMS’e düzgün düşmez; misafir daha sonra OTA’dan satın alır, sistemde iki ayrı kayıt oluşur.
Entegrasyonun otel tarafındaki 3 somut sonucu
- •Tek rezervasyon kartı: Misafir bilgisi, notlar, özel istekler tek yerde toplanır.
- •Anlık karar: Agent PMS’te müsaitlik/fiyatı görür; “bekleyin kontrol ediyorum” azalır.
- •Risk azaltma: Mapping ve ID standardı ile overbooking/çift kayıt ihtimali düşer.
Mini Check (Hızlı teşhis)
- • Aynı misafir farklı kanallardan yazdığında iki farklı “kayıt” oluşuyor mu?
- • OTA mesajındaki talep, PMS’te “rezervasyon kartına” bağlanıyor mu?
- • Agent’lar ülke/dil/kanal alanlarını farklı mı dolduruyor?
Ne yapmalıyım?
- • PMS’i “tek kaynak” (source of truth) olarak tanımlayın; herkes aynı ekrana bakmalı.
- • PMS’te ülke / dil / kanal alanlarını standardize edin (sonradan rapor için kritik).
- • OTA–PMS mapping’inizi yazılı hale getirin (oda tipi, rate plan, rezervasyon ID).
2. 4 dilli çağrı merkezi ile PMS & OTA rezervasyon akışı nasıl kurulmalı?
Kısa cevap: Kanal → Agent → PMS → Onay/Follow-up zincirini tek kurala bağlayarak. Akışın “dil” tarafı (TR–EN–DE–RU) bir kapasite/kalite konusu; “sistem” tarafı ise mapping ve ID standardı konusudur. İkisi birlikte tasarlanmazsa, çok dilli ekip hızlı yanıt verir ama rezervasyon kartı dağılır.
Checklist (5–7 madde) — Uçtan uca akış
- Kanalı tanımla: Telefon / WhatsApp / OTA mesajı (Booking/Expedia vb.)
- Agent routing: Dil (TR–EN–DE–RU) + senaryo (rezervasyon / değişiklik / iptal)
- PMS kontrolü: Anlık müsaitlik + fiyat + kural seti (iptal/ön provizyon)
- Tek rezervasyon kartı: Misafir kimliği + ülke/dil + kanal + notlar
- Onay & takip: Teklif/opsiyon/ödeme adımı + follow-up zamanı
- Mapping doğrulama: Oda tipi–rate plan–rezervasyon ID eşleşmesi
- Risk kontrolü: Çift kayıt/overbooking tetikleyicileri ve escalation
Akışın “rezervasyon funnel” mantığı (mini örnek)
- •Talep: “2 yetişkin, 4 gece, deniz manzarası” (DE dilinde)
- •Netleştirme: tarih/kişi/oda/özel istek
- •Teklif: PMS’ten doğru rate plan ile 1 ana + 1 alternatif
- •Kapanış: opsiyon süresi + ödeme/ön provizyon + follow-up
Mini Check (Akış sağlam mı?)
- • “Opsiyon” veriyorsanız PMS’te bir “durum” (status) var mı?
- • Follow-up zamanı yazılmadan görüşme kapanıyor mu?
- • Agent “kanal” alanını doğru işaretliyor mu?
Ne yapmalıyım?
- • “Opsiyon/ön rezervasyon” sürecini yazılılaştırın (kaç saat, hangi oda bloklanır?).
- • Her talebin PMS’te bir iz bırakmasını zorunlu kılın (not + durum + takip).
- • İç link önerisi: Rezervasyon destek operasyonu için /tr/cagri-merkezi/rezervasyon-destegi sayfasına bağlayın.
3. 4 dilli agent için rezervasyon akışı (rol, ekran, alanlar)
TR–EN–DE–RU agent’ların işi yalnız konuşmak değil; konuşmayı doğru kayıt haline getirmektir. Bunun için agent ekranında (ve PMS/CRM’de) minimum ortak alanlar net olmalı: ülke, dil, kanal, oda tipi, rate plan, özel istek, takip zamanı. Bu alanlar tutarlı kullanılmazsa raporlama bozulur; kalite yönetimi “his” ile yapılır.
PMS’te standardize edilmesi gereken alanlar (konsept)
- •Country (ülke): pazar analizi için
- •Language (dil): agent planlama + kalite için
- •Channel (kanal): OTA/Direct/Call/WhatsApp ayrımı için
- •Reservation ID: OTA ID + iç ID eşleştirme için
- •Notes / Special requests: 4 dilde anlaşılır kısa format için
Mikro kural: Not alanına “roman” yazmayın; 3 satır: İstek / Risk / Takip.
4 dilde not yazımında pratik standart
- •Kısa, net, kodlanabilir: “Late check-out?” yerine “Late CO 요청 / 16:00 talep / ücret?” gibi yapılandırılmış yazın.
- •Çeviri tuzağı: Misafir cümlesini aynen yapıştırmak yerine “operasyon dili”ne çevirin.
- •Özel istekleri etiketleyin: (Bebek yatağı / diyet / transfer / oda konumu)
Mini Check (Agent ekran standardı)
- • Agent’lar notu aynı formatla mı yazıyor?
- • Ülke/dil/kanal alanları boş kalıyor mu?
- • Özel istekler operasyon ekiplerine net gidiyor mu?
Ne yapmalıyım?
- • Agent onboarding’de “PMS alan standardı” modülünü zorunlu yapın.
- • İç link önerisi: PMS notları/segmentler için ilgili cluster sayfasına bağlamak üzere /tr/pms-ota/rezervasyon-yonetimi.
- • DGTLFACE yaklaşımıyla (Multilingual Call Center + Reservation Funnel) tek paragrafta ilişkilendirin: “DGTLFACE modelinde TR–EN–DE–RU ekip, PMS kartını funnel’ın merkezine koyar.”
4. OTA mesajlarından PMS’e doğru veri aktarımı (Booking/Expedia vb.)
OTA mesajları çoğu otelde “ayrı bir evren” gibi yönetilir. Oysa doğru modelde OTA mesajı; PMS’teki rezervasyon kartına bağlanır ve aynı misafirle telefonda/WhatsApp’ta konuştuğunuzda tek geçmiş görünür. Burada kritik konu: mapping (oda tipi/rate plan) ve ID standardı (rezervasyon kimliği).
OTA mesajı → PMS kartı bağlama mantığı
- Mesaj thread’ini tanı (OTA rezervasyon ID / tarih / isim)
- PMS’te mevcut kartı bul veya yeni kart aç
- Kartta kanal=OTA, dil, ülke alanlarını işle
- Mesaj özeti + aksiyon + follow-up zamanını not et
- Değişiklik/iptal ise kart durumunu güncelle
“OTA mesajları (Booking, Expedia vb.) çağrı merkezi üzerinden PMS’e nasıl işlenir?” Net cevap: Thread’i PMS kartına bağla, aksiyonu kart durumuna yaz, ID’yi standardize et, takip zamanını koy.
Mapping & ID standardı (overbooking’i düşüren çekirdek)
- •Oda tipi mapping: OTA’daki oda kodu → PMS oda tipi
- •Rate plan mapping: OTA rate plan → PMS rate plan
- •Reservation ID standardı: PMS iç ID + OTA ID birlikte tutulur (tek alan ya da ilişki)
| Kanal | PMS alanları | Risk | Kontrol |
|---|---|---|---|
| Telefon | Ülke / Dil / Kanal / Oda tipi / Rate plan / Not / Follow-up | Teklif verilip kart açılmaması | Kayıt açmadan teklif yok kuralı |
| Ülke / Dil / Kanal / Kart durumu / Follow-up / Özel istek | Duplicate kayıt / eksik takip | Özet + aksiyon + takip standardı | |
| OTA Mesajı | Kanal=OTA / OTA ID / Dil / Ülke / Kart durumu | Yanlış karta bağlanma / mapping hatası | OTA ID standardı + mapping tablosu |
| Değişiklik / İptal | Eski-yeni tarih / Oda tipi / Fiyat farkı / Durum | Yanlış rezervasyonun güncellenmesi | ID standardı + durum güncelleme zorunluluğu |
Mini Check (Mapping sağlıklı mı?)
- • OTA’daki oda tipi PMS’te doğru oda tipine düşüyor mu?
- • OTA ID PMS kartında her zaman görünüyor mu?
- • Değişiklik/iptal mesajı geldiğinde “doğru karta” gidiyor mu?
Ne yapmalıyım?
- • Mapping tablosunu yazılı hale getirin ve sürümleyin (sezon kampanyalarında değişir).
- • OTA mesaj akışında “kim, ne zaman, hangi durumda PMS’e işler?” rol tanımı yapın.
- • İç link önerisi: PMS-OTA yönetimi için /tr/pms-ota-yonetimi.
5. Telefon & WhatsApp rezervasyonlarının PMS ile senkronu (direct akış)
Telefon ve WhatsApp “direct” rezervasyonun ana damarlarıdır; ama PMS’e doğru işlenmezse en büyük çift kayıt riski burada çıkar. Çünkü misafir önce WhatsApp’tan sorar, sonra telefonda konuşur, sonra OTA’dan satın alabilir. Bu nedenle direct akışta 3 şey zorunlu olmalı: tek misafir kimliği, durum/pipeline, follow-up.
Telefon/WhatsApp → PMS akışının pratik adımları
- •Talep al → PMS’te kart aç/bağla
- •Müsaitlik/fiyat doğrula → teklif gönder
- •Opsiyon/ön provizyon gerekiyorsa kartta işaretle
- •Follow-up zamanı koy → dönüşüm takibi yap
Ön provizyon, iptal ve değişiklik akışı (konsept)
- •Ön provizyon varsa: “koşul + süre + iptal kuralı” PMS notlarında net olmalı.
- •Değişiklikte: eski yeni tarihler, oda tipi ve fiyat farkı tek kartta görünmeli.
- •İptalde: “neden” alanı raporlanabilir şekilde tutulmalı (genel kategori).
Mini Check (Direct akış kontrolü)
- • WhatsApp’ta konuşulan teklif PMS’te kayıtlı mı?
- • Telefonda verilen opsiyonun süresi PMS’te var mı?
- • Değişiklik/iptal bilgisi kartta tek yerde mi tutuluyor?
Ne yapmalıyım?
- • WhatsApp konuşması bittiğinde 1 “özet + aksiyon + takip” mesajını standart yapın.
- • Direct rezervasyonlarda “kayıt açmadan teklif yok” kuralını koyun.
- • İç link önerisi: çağrı merkezi rezervasyon desteği /tr/cagri-merkezi/rezervasyon-destegi ve rezervasyon yönetimi /tr/pms-ota/rezervasyon-yonetimi.
6. Hata, overbooking ve çift kayıt risklerini azaltmak
Bu işin “gerçek” kısmı burada başlar: akış kurarsınız ama sezon pikinde hata çıkar. İyi haber: çoğu hata 5 noktada toplanır ve doğru kontrol listesiyle belirgin biçimde azalır. Saha içgörüsü olarak; PMS & OTA entegrasyonu doğru kurulan yapılarda telefon/WhatsApp–OTA kanal karışıklığı azalır, overbooking şikâyetleri düşer ve yönetim raporlaması kolaylaşır.
Overbooking’in 3 ana nedeni (ve pratik önlem)
- Kaynak belirsizliği: “Hangi ekran doğru?” → PMS tek kaynak kuralı
- Opsiyon disiplini yok: Oda bloklama net değil → opsiyon süre standardı
- Mapping / ID hatası: Yanlış karta düşme → ID standardı + mapping tablosu
Sık yapılan 5 hata (kutusu)
- Kanal alanı boş bırakmak → raporlar “çöp olur”, risk görünmez
- OTA mesajını PMS’e bağlamamak → aynı misafir iki yerde yaşar
- WhatsApp’ta teklif verip PMS’te kayıt açmamak → çift kayıt tetiklenir
- Rezervasyon ID’lerini standardize etmemek → değişiklik/iptal yanlış karta gider
- Notları serbest metin yazmak → operasyon ekipleri özel istekleri kaçırır
Fark yaratan mini bölüm (Competitor Gap’i kapatır)
Fark Yaratan Yaklaşım: “Tek Rezervasyon Kartı + 4 Dil” Birçok içerik PMS&OTA entegrasyonunu teknik doküman gibi, çağrı merkezini ayrı anlatır. Buradaki fark: TR–EN–DE–RU Multilingual Call Center ekibinin, OTA mesajları ve telefon/WhatsApp akışını aynı Reservation Funnel üzerinde, PMS kartında birleştirmesidir. Bu, “entegrasyon”u BT projesi olmaktan çıkarır; operasyon standardına çevirir.
Mini Check (Risk azaltma)
- • Opsiyon verilen oda PMS’te bloklanıyor mu?
- • OTA değişiklik mesajı geldiğinde doğru karta gidiyor mu?
- • Notlar “İstek/Risk/Takip” formatında mı?
Ne yapmalıyım?
- • Rezervasyon ID standardını yazın: “PMS ID + OTA ID birlikte tutulur.”
- • Mapping tablosunu sezon başında yeniden kontrol edin (rate plan değişir).
- • “Sık hata 5’lisi”ni duvara asın; haftalık 10 dk kontrol rutini kurun.
- • Teknik detaylar için BT/hukuk onayı gerektiğini not edin (platform/API özelinde).
Hemen kontrol edebileceğiniz 10 rezervasyon adımı (final checklist)
- Talep kanalını işaretle (Telefon/WhatsApp/OTA/DM)
- Dil ve ülke alanını doldur (TR–EN–DE–RU + ülke)
- PMS’te mevcut misafir kartı var mı kontrol et
- Yoksa yeni kart aç; varsa mevcut karta bağla
- Müsaitlik ve fiyatı PMS’ten doğrula (tek kaynak)
- Teklif/alternatif sun; opsiyon süresi yaz
- OTA mesajı ise OTA ID’yi karta ekle (ID standardı)
- Özel istekleri “İstek/Risk/Takip” formatında not et
- Follow-up zamanı belirle (bugün/yarın/48 saat)
- Değişiklik/iptal varsa kart durumunu güncelle ve özet not düş
7. PMS & OTA–Çağrı Merkezi Akış Diyagramı Şablonunu İndir — Çağrı Merkezi / PMS-OTA Akışı
PMS & OTA–Çağrı Merkezi Akış Diyagramı Şablonunu İndir — Çağrı Merkezi / PMS-OTA Akışı (v1.0)
Bu şablon, telefon/WhatsApp + OTA mesajlarından gelen rezervasyon taleplerini tek PMS rezervasyon kartına bağlayan uçtan uca akışı (kanal → agent → PMS → onay) standardize etmek içindir. Mapping, rezervasyon ID standardı ve sorumlulukları tek sayfada netleştirerek overbooking ve çift kayıt riskini azaltmanıza yardımcı olur.
Kim Kullanır?
GM, rezervasyon lideri, çağrı merkezi yöneticisi, operasyon/BT koordinatörü, ajans yöneticisi.
Nasıl Kullanılır?
- Kanal envanterini çıkarın ve akış kutularını doldurun (30–45 dk).
- Mapping & ID standardı bölümünü BT/analitik ekiple netleştirin.
- Pilot uygulamada “hata-çözüm” ve kontrol listesiyle 14 gün izleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kanal envanteri tamam
- ▢ ✅ Routing kuralları yazıldı
- ▢ ✅ PMS alan standardı net
- ▢ ✅ Mapping tablosu dolduruldu
- ▢ ✅ Rezervasyon ID standardı yazıldı
- ▢ ✅ Pilot izleme planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Çok dilli rezervasyon operasyonunda akış varsa hız, kontrol ve görünürlük vardır
4 dilli çağrı merkezi, yalnızca farklı dillerde yanıt vermek için değil; telefon, WhatsApp ve OTA mesajlarından gelen talebi tek rezervasyon kartında buluşturmak için değer üretir. PMS tek kaynak olduğunda, agent karar kalitesi artar; follow-up, opsiyon ve değişiklik süreçleri daha izlenebilir hale gelir.
Bu yaklaşım, entegrasyonu yalnızca teknik bir kurulum olmaktan çıkarır; rezervasyon operasyonunun günlük standardına dönüştürür. Özellikle yüksek sezon baskısı yaşayan resort bölgelerde, doğru mapping ve ID standardı hem overbooking riskini hem de duplicate kayıt sorununu azaltır.
Bir Sonraki Adım
Telefon/WhatsApp ve OTA rezervasyonları çakıştırmadan yönetmek isteyen oteller için.
Sık Sorulan Sorular
4 dilli çağrı merkezi PMS’e nasıl bağlanır?▾
OTA mesajları (Booking, Expedia vb.) çağrı merkezi üzerinden PMS’e nasıl işlenir?▾
Telefon ve WhatsApp rezervasyonlarını overbooking yaratmadan nasıl yönetirim?▾
PMS not alanına 4 dilde bilgiyi nasıl doğru kaydederim?▾
Overbooking’in en sık nedeni nedir?▾
Çift kayıt (duplicate) nasıl oluşur ve nasıl önlenir?▾
Mapping neden bu kadar kritik?▾
Bu akışı kurarken BT/hukuk tarafında nelere dikkat edilmeli?▾
İlgili İçerikler