OTA Üzerinden Gelen Çağrıları Yönetmek: Booking/Expedia Kaynaklı Sorun ve Talep Akışları

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 otel OTA yönetimi tarafında kanal ilişkisini korur. Ayrıca web, OTA ve telefon temaslarını aynı akışta görmek için birleşik satış funnel’ı mantığıyla düşünmek gerekir.

8 Adımlı OTA Çağrı Playbook’u (net liste)

1. Çağrı türü: Soru / Değişiklik / Şikâyet / Ödeme / No-show / Overbooking
2. Kaynak doğrulama: Booking mi Expedia mı? OTA referansı + PMS kaydı eşleşiyor mu?
3. Yetki sınırı: “Benim yapabileceğim / OTA’nın yapması gereken” net mi?
4. Akış seçimi: OTA extranet işlem mi, PMS işlem mi, call-back mi?
5. Script bloğu: Karşılama + kısa empati + net next step
6. Koşul eşitleme: İptal/değişiklikte “kural ve ücret” net; vaat yok
7. Takip standardı: Not/etiket + SLA (geri dönüş süresi)
8. 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?

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

☑ 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?

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. Birçok Booking/Expedia sorun akışı da zayıf OTA entegrasyonu, eksik mapping veya senkronizasyon hatasından beslenir.

Akışın 3 sabit kontrol noktası

1. Kim? Misafir mi, OTA temsilcisi mi, üçüncü kişi mi? (bilgi paylaşımı sınırı)
2. Ne? Değişiklik mi, iptal mi, ödeme mi? (çağrı tipi)
3. 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ı”

Telefon görüşmesi kapandıktan sonra çözümün kaybolmaması için çağrı merkezi CRM ve PMS entegrasyonu ile kayıt standardını kurmak, Booking/Expedia tarafında devam eden yazılı takip için de mesaj yönetimi akışını aynı sistemin parçası haline getirmek gerekir.

☑ 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ı?

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)

1. Empati: “Anlıyorum…”
2. Netlik: “Rezervasyon numarası/OTA referansı ile kontrol ediyorum.”
3. Next step: “Şu işlem OTA üzerinden / PMS üzerinden ilerler; size şu şekilde yardımcı olacağım.”

Örnek script tablosu (Booking/Expedia senaryoları)

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ı?

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. Tarih, oda tipi ve özel talep kararlarının sahada kaybolmaması için her çağrının sonunda rezervasyon yönetimi tarafına net kayıt düşülmelidir. Overbooking, yanlış oda tipi veya ödeme anlaşmazlığı gibi hassas durumlarda ise ayrı bir otel şikâyet ve kriz çağrıları yönetimi çerçevesiyle ilerlemek gerekir.

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?

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?

Booking, Expedia ve diğer OTA kanallarından gelen çağrıları akış, kayıt ve yetki standardıyla yönettiğinizde call center yalnız sorun çözen bir hat değil, misafir güvenini koruyan operasyon merkezi haline gelir. Bu yapıyı otelinizde sistemli kurmak isterseniz otel çağrı merkeziyle OTA çağrılarını yönetmek yaklaşımını inceleyebilir, karar aşamasında ise otel çağrı merkezi hakkında sık sorulan sorular sayfasına geçebilirsiniz.