1. OTA Kaynaklı Çağrıları Doğru Yönetmek İçin Hangi Adımları İzlemelisiniz?
OTA çağrılarını doğru yönetmek için şu adımları izleyin: (1) çağrı türünü sınıflandırın, (2) rezervasyon kaynağını doğrulayın, (3) yetki sınırını belirleyin, (4) OTA–PMS akışını uygulayın, (5) senaryo bazlı script kullanın, (6) ödeme/iptal/no-show kurallarını “koşul eşitleyerek” anlatın, (7) call-back ve not standardı ile takip edin, (8) raporlayıp tekrar eden sorunları süreçle azaltın. Bu yapı, “kim ne yapacak?” karmaşasını düşürür ve OTA ilişkisini korur.
8 Adımlı OTA Çağrı Playbook’u (net liste)
- Çağrı türü: Soru / Değişiklik / Şikâyet / Ödeme / No-show / Overbooking
- Kaynak doğrulama: Booking mi Expedia mı? OTA referansı + PMS kaydı eşleşiyor mu?
- Yetki sınırı: “Benim yapabileceğim / OTA’nın yapması gereken” net mi?
- Akış seçimi: OTA extranet işlem mi, PMS işlem mi, call-back mi?
- Script bloğu: Karşılama + kısa empati + net next step
- Koşul eşitleme: İptal/değişiklikte “kural ve ücret” net; vaat yok
- Takip standardı: Not/etiket + SLA (geri dönüş süresi)
- Kapanış: Çözüm özeti + teyit + (uygunsa) sonraki konaklamaya değer önerisi
☑ Mini Check
- •Çağrı türünü ilk 30 saniyede etiketliyor musunuz?
- •Kaynak doğrulama (OTA ref + PMS) net mi?
- •Yetki sınırınız yazılı mı? (iade/şikâyet/değişiklik)
- •Her senaryo için 1 kısa script bloğu var mı?
- •Call-back SLA ve not standardı uygulanıyor mu?
Ne yapmalıyım?
- • “OTA çağrı türleri” için 1 sayfa sınıflandırma tablosu asın.
- • Yetki sınırlarını (kim onaylar?) yazılı hale getirin.
- • Sezonda (Antalya/Belek/Side/Kemer/Bodrum) call-back kapasitesini pik saatlere göre planlayın.
2. OTA Kaynaklı Çağrı Türleri (Soru, Değişiklik, Şikâyet)
OTA çağrılarında ilk hedef, “ne istiyor?” sorusunu doğru tanımlamaktır. Çünkü aynı cümle iki farklı kategoriye girebilir: “tarih değiştirmek istiyorum” bazen değişiklik talebidir, bazen “iptal ücretinden kaçınma” girişimidir. Bu nedenle çağrı türlerini net sınıflandırın; sonra akış ve script otomatikleşir.
6 temel çağrı tipi (pratik sınıflandırma)
- •Bilgi/Soru: rezervasyon detayı, check-in/out, konsept, ulaşım
- •Değişiklik: tarih, oda tipi, kişi sayısı, isim düzeltme
- •İptal/Ücret: iptal koşulu, ücretsiz iptal penceresi, ücret itirazı
- •Ödeme: OTA prepay, otel tahsilatı, kart/teminat soruları
- •Şikâyet: oda/temizlik/hizmet, iletişim, yanlış bilgilendirme algısı
- •No-show/Overbooking: gelmeme, yer bulunamaması, alternatif çözüm
| Çağrı tipi | Tipik cümle | Doğru ilk hamle | Risk |
|---|---|---|---|
| Bilgi | “Rezervasyonum görünüyor mu?” | OTA ref + PMS doğrula | yanlış bilgi |
| Değişiklik | “Tarihi kaydırabilir miyiz?” | kural/ücret netleştir | sözleşme dışı vaat |
| İptal | “Ücretsiz iptal istiyorum” | koşul eşitle + yetki | iade/chargeback |
| Ödeme | “Ödemeyi kim aldı?” | ödeme modelini açıkla | yanlış tahsilat |
| Şikâyet | “Oda beklentim değil” | empati + çözüm akışı | puan/yorum riski |
| No-show/Overbooking | “Geldim, yer yok” | kriz protokolü | itibar/gelir |
☑ Mini Check
- •Operatör çağrı tipini net etiketliyor mu?
- •Her tip için “ilk hamle” cümlesi var mı?
- •İptal/ödeme/şikâyette yetki sınırı net mi?
Ne yapmalıyım?
- • Çağrı tiplerine göre 6 ayrı “kısa script bloğu” yazın.
- • Şikâyet çağrılarında çözüm akışını PMS notlarıyla standardize edin.
- • OTA prosedürlerinin dışına çıkacak yönlendirmelerden kaçının; “yetkili birim” devrini netleştirin.
3. OTA – Çağrı Merkezi – PMS Arasındaki Akış
OTA çağrılarında başarı, doğru sistemde doğru işlemi yapmaktır. Call Center, OTA extranet ve PMS arasında “köprü”dür; ama bu köprü, herkesin kafasında farklı çalışırsa kaos büyür. Akışı görselleştirin: OTA çağrısı → doğrulama → işlem türü → doğru sistem → teyit.
Akışın 3 sabit kontrol noktası
- Kim? Misafir mi, OTA temsilcisi mi, üçüncü kişi mi? (bilgi paylaşımı sınırı)
- Ne? Değişiklik mi, iptal mi, ödeme mi? (çağrı tipi)
- Nerede? İşlem OTA’da mı PMS’te mi? (sistem)
Not standardı (PMS/CRM)
- •“Kaynak: Booking/Expedia”
- •“Talep: tarih değişikliği / iptal / ödeme bilgi”
- •“Kural: ücret/koşul”
- •“Aksiyon: OTA’ya yönlendirme / call-back / onay bekliyor”
- •“SLA: geri dönüş zamanı”
☑ Mini Check
- •Doğrulama yapılmadan işlem başlatılıyor mu? (yapılmamalı)
- •İşlem yeri (OTA mı PMS mi) net mi?
- •PMS not formatı standart mı?
Ne yapmalıyım?
- • Akış diyagramını eğitimde 10 dakikada ezberletin.
- • PMS notları için kopyala-yapıştır şablonu oluşturun.
- • İç linklerle operasyonu bağlayın: https://dgtlface.com/tr/pms-ota/rezervasyon-yonetimi ve https://dgtlface.com/tr/otel/ota-yonetimi
4. Booking/Expedia Çağrıları İçin Script ve Prosedürler
Buradaki amaç “tam script yayınlamak” değil; her senaryo için ekipte aynı dili ve aynı next-step’i üretmektir. Script’ler anonim ve genel kalmalı; otelin marka diline uyarlanmalı. Ayrıca para iadesi/şikâyet gibi konularda yetki sınırlarını aşmamak esastır (hukuki tavsiye değil; ticari/operasyonel çerçeve).
Script blok kuralı (1+1+1)
- Empati: “Anlıyorum…”
- Netlik: “Rezervasyon numarası/OTA referansı ile kontrol ediyorum.”
- Next step: “Şu işlem OTA üzerinden / PMS üzerinden ilerler; size şu şekilde yardımcı olacağım.”
Örnek script tablosu (Booking/Expedia senaryoları)
| Senaryo | Kısa script (anonim) | Next step | Yetki notu |
|---|---|---|---|
| Tarih değişikliği | “Kontrol ediyorum; bu talep için kural ve ücret bilgisi netleşmeli.” | OTA kuralı + müsaitlik kontrol | onay gerektirebilir |
| İptal/ücret itirazı | “Koşulları birlikte eşitleyelim; iptal penceresi ve ücret burada belirleyici.” | OTA koşulunu teyit | iade sözü verme |
| Ödeme kimin? | “Bu rezervasyonda ödeme modeli şu şekilde ilerliyor…” | OTA prepay vs otel tahsil | tahsilat adımı net |
| Şikâyet | “Üzgünüm; detay alıp çözüm için yönlendiriyorum.” | PMS not + çözüm adımı | tazmin/indirim yetkisi |
4 sık OTA senaryosu, 4 çözüm (hızlı kart mantığı)
- •Senaryo-1 (Değişiklik): koşul eşitle → müsaitlik → onay → teyit
- •Senaryo-2 (İptal): kural/ücret net → yetkili devri → kayıt
- •Senaryo-3 (Ödeme): ödeme modeli açıklaması → doğru tahsilat adımı
- •Senaryo-4 (Overbooking): kriz protokolü → alternatif çözüm → yazılı teyit
☑ Mini Check
- •Script “empati + netlik + next step” kuralına uyuyor mu?
- •İade/indirim konusunda yetki sınırı net mi?
- •Her senaryoda PMS notu ve SLA var mı?
Ne yapmalıyım?
- • Operatörlere “vaat yok, kural var” prensibini öğretin.
- • Booking/Expedia çağrılarını ayrı bir etiketle raporlayın.
- • İç link: Rezervasyon desteği operasyonu için https://dgtlface.com/tr/cagri-merkezi/rezervasyon-destegi
5. Ödeme, İptal ve No-Show Senaryolarını Yönetmek
Bu senaryolar, hem misafir memnuniyeti hem gelir riskinin en yüksek olduğu alanlardır. Burada güvenli yaklaşım: koşul eşitleme + net bilgilendirme + doğru sistemde doğru kayıt. Özellikle sezonda (Antalya/Belek/Side/Kemer/Bodrum) hacim artınca “hız” baskısı doğar; bu yüzden standart şarttır.
OTA ödemeli rezervasyonlarda bilgilendirme (Payment)
- •Ödeme modeli: “OTA prepay” vs “otel tahsil” ayrımı netleştirilir.
- •Misafire verilecek bilgi: “kim tahsil etti / iade nasıl ilerler / süre” (kesin süre vaadi değil).
İptal/değişiklik talepleri (Cancellation/Modification)
- •Kural: ücretsiz iptal penceresi, ücret, değişiklik şartları
- •Yetki: “bizim yapabileceğimiz” vs “OTA’nın işlemesi gereken” ayrımı
No-show / overbooking (kriz yönetimi çerçevesi)
- •No-show: kural + kayıt + çözüm dili
- •Overbooking: alternatif çözüm üretme + yazılı teyit + kayıt
☑ Mini Check
- •Ödeme modelini 1 dakikada açıklayan standart cümle var mı?
- •İptal/değişiklikte “kural net, vaat yok” uygulanıyor mu?
- •No-show/overbooking için kriz protokolü dokümante mi?
Ne yapmalıyım?
- • Ödeme modeli için 2 cümlelik “net açıklama” seti hazırlayın.
- • İptal/değişiklikte onay akışını yazın (kim onaylar?).
- • Kriz senaryolarını rol-play ile yılda 2 kez tazeleyin.
6. OTA Çağrılarını Direct Sadakate Dönüştürmek
Burada ince çizgi var: OTA misafirini “direkt kanala geç” diye zorlamak, prosedür/sözleşme riskleri ve deneyim riski yaratabilir. Doğru strateji; mevcut sorunu profesyonelce çözüp, sonraki konaklama için değer önerisini doğru zamanda sunmaktır: “kolaylık, tercih, iletişim, özel talep yönetimi”.
Doğru zamanlama (sorun çözüldükten sonra)
- •Önce çözüm: talep/şikâyet kapanır, misafir rahatlar.
- •Sonra değer: “bir sonraki konaklamada özel taleplerinizi daha hızlı yönetmek için…”
Direct fayda çerçevesi (agresif olmayan)
- •“Tercihlerinizi kaydederiz (oda notu, yastık, transfer)”
- •“Tek noktadan iletişim (hızlı çözüm)”
- •“Özel taleplerde net takip”
Key Statistics / Data Point (yumuşatılmış): OTA çağrı akışını netleştiren otellerde “kim ne yapacak” karmaşası azaldıkça hem misafir memnuniyeti sinyallerinin hem de OTA ilişkilerinin daha stabil hale gelebildiği senaryo bazlı gözlemlenebilir; bu etki özellikle sezon yoğunluğunda daha belirginleşir.
☑ Mini Check
- •Direct öneri “çözüm sonrası” yapılıyor mu?
- •Değer önerisi “kolaylık ve tercih yönetimi” üzerinden mi?
- •Sözleşme/prosedür dışı yönlendirme yok mu?
Ne yapmalıyım?
- • “Çözüm sonrası 1 cümle değer önerisi” hazırlayın (herkeste aynı).
- • CRM/PMS’te “tercih notu” alanını standardize edin.
- • İç link: OTA yönetimi ve rezervasyon yönetimi sayfalarıyla sistemi birleştirin.
7. Booking/Expedia Çağrı Senaryoları & Akış Şablonunu İndir
Booking/Expedia Çağrı Senaryoları & Akış Şablonunu İndir — Otel / OTA Çağrı Yönetimi (v1.0)
Bu şablon, Booking/Expedia kaynaklı çağrıları “çağrı tipi → doğrulama → işlem yeri (OTA/PMS) → yetki → kapanış” akışına oturtur. Amaç, ekip içinde “kim ne yapacak?” karmaşasını azaltmak, sözleşme/prosedür dışına çıkan vaat riskini düşürmek ve çözüm süresini kısaltmaktır. Şablon, script örneklerini anonim ve uyarlanabilir bloklar halinde sunar.
Kim Kullanır?
Rezervasyon/call center müdürü, ön büro lideri, OTA yöneticisi ve PMS sorumlusu.
Nasıl Kullanılır?
- OTA çağrı tiplerini seçin ve her tip için “ilk hamle + işlem yeri” alanını doldurun.
- Yetki matrisini netleştirip ekip eğitiminde 20 dakikada üzerinden geçin.
- 14 günlük sprint planıyla uygulayın; KPI’larda (SLA, tekrar çağrı) trendi izleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Çağrı tipi etiketi girildi
- ▢ ✅ OTA ref + PMS ref doğrulandı
- ▢ ✅ İşlem yeri seçildi (OTA/PMS)
- ▢ ✅ Yetkili onayı gerekiyorsa devredildi
- ▢ ✅ SLA ve not standardı işlendi
- ▢ ✅ Misafire net kapanış özeti verildi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Booking/Expedia çağrılarını sözleşme dışına çıkmadan standardize edip çözüm hızını ve memnuniyeti artırmak isteyen oteller içindir.
Sık Sorulan Sorular
OTA (Booking/Expedia) kaynaklı çağrılar nasıl yönetilmeli?▾
OTA rezervasyonunda iptal/değişiklik talebine çağrı merkezinde nasıl yaklaşılır?▾
OTA ödemeli rezervasyonlarda misafire nasıl bilgi verilmeli?▾
No-show ve overbooking durumunda çağrı merkezi ne yapmalı?▾
OTA misafirini sonraki konaklamada direct kanala nasıl yönlendirebilirim?▾
İlgili İçerikler
İlgili Yazılar