1. En Sık Görülen Rezervasyon Uyuşmazlıkları
Uyuşmazlıkların çoğu 5 kümeye düşer. Bu kümeler netleştiğinde ekip “panik” yerine “triage” ile hareket eder.
En sık görülen rezervasyon uyuşmazlıkları nelerdir?
En sık uyuşmazlıklar: (1) yanlış tarih, (2) yanlış oda tipi, (3) fiyat farkı (OTA vs otel), (4) rezervasyon görünmüyor/senkron kopukluğu, (5) iptal/no-show yorum uyuşmazlığıdır. Her biri için standart çözüm akışı ve telafi sınırı olmalıdır.
| DisputeType | Tipik belirti | Olası kaynak | İlk kontrol | Hızlı çözüm opsiyonu |
|---|---|---|---|---|
| Tarih çakışması | Giriş/çıkış yanlış | Misafir/OTA/PMS | Voucher + PMS history | Revizyon + fiyat farkı |
| Oda tipi çakışması | “Suit aldım” | OTA mapping / satış dili | OTA ekran görüntüsü + PMS oda tipi | Eşdeğer oda / upgrade |
| Fiyat uyuşmazlığı | “Sitede daha ucuz” | Kanal farkı/kur | OTA net/brüt ayrımı | Açıklama + alternatif |
| Rezervasyon görünmüyor | PMS’te yok | Senkron gecikme | OTA ref no + channel manager | Manuel create + not |
| İptal/no-show anlaşmazlığı | “İade istiyorum” | Politika iletişimi | Politika + ödeme kaydı | Kısmi çözüm/eskalasyon |
Uyuşmazlık Tipleri Tablosu (örnek)
Ne yapmalıyım?
- • Vaka tiplerini 5 başlıkta posterleştir
- • Her vaka için “ilk 3 kontrol” listesi yaz
- • Yetki sınırlarını (kim ne verebilir) netleştir
- • “Kayıt altına alma” zorunluluğu koy (case ID)
2. Tarih, Oda ve Fiyat Çakışmaları
Bu üçlü, uyuşmazlıkların “klasik” kısmıdır. Burada hedef; misafiri suçlamadan doğrulamak, şeffaf açıklamak ve hızlı alternatif sunmaktır.
Tarih/oda/fiyat uyuşmazlığında ne yapmalıyım?
- Kanıtı topla (voucher/e-posta/OTA ekranı)
- PMS’te karşılaştır (history + rate plan + oda tipi)
- Farkın kaynağını açıkla (mapping/kur/vergiler/politika)
- 2 çözüm seçeneği sun (eşdeğer oda, revizyon, kısmi telafi)
- Onay al ve kayda geçir (case ID + not)
“2 seçenek” kuralı (hız için)
- •Seçenek A: Misafirin beklentisine en yakın çözüm
- •Seçenek B: Otelin riskini azaltan alternatif (tarih kaydırma/oda değişimi)
3+ seçenek, karar yorar ve krizi uzatır.
Ne yapmalıyım?
- • “Şeffaf açıklama” şablonunu hazırla (1 paragraf)
- • Fiyat uyuşmazlığında net/brüt dilini standartlaştır
- • Oda tipi mapping sorunlarını entegrasyon ekibine haftalık raporla
- • Revizyon SOP’u ile entegre çalış (Blog-12)
3. OTA–Otel Arasındaki İletişim Kopuklukları
“Rezervasyon görünmüyor” vakalarının önemli kısmı burada çıkar: OTA’da var, PMS’te yok; channel manager gecikmiştir; sanal kart/ödeme bilgisi gelmemiştir. Bu vakalarda misafiri bekletmek en büyük hatadır.
“Rezervasyon görünmüyor” şikayetini nasıl yönetirim?
Önce misafire güven verip “bulacağız” yaklaşımı kurun, sonra paralel kontrol yapın: OTA ref no + misafir adı ile channel manager/PMS araması, senkron kuyruğu kontrolü, gerekirse geçici rezervasyon oluşturma (manual create) ve kayda “pending verification” notu düşme. Misafir beklerken çözüm çalışmalıdır; misafir asla “bizde yok” diye kapıdan dönmemelidir.
10 dakikalık “kayıp rezervasyon” protokolü
- •Dakika 0–2: Misafire güven cümlesi + ref no alma
- •Dakika 2–5: Channel manager/PMS araması
- •Dakika 5–7: Manuel create (gerekirse) + oda güvence
- •Dakika 7–10: OTA ile iletişim/mesaj + case kaydı
Ne yapmalıyım?
- • “Kayıp rezervasyon protokolünü” yazılı SOP yap
- • Manuel create yetkisini rol bazında tanımla
- • OTA iletişim kanalını (extranet mesaj) standardize et
- • Bu vakaları mapping/senkron sorunu olarak root-cause listesine ekle
4. Şikayet Yönetimi ve Çözüm Adımları (Service Recovery)
Uyuşmazlık şikayete dönüştüğünde “haklı-haksız” değil, “çözüm ve telafi” dili gerekir. Telafi vermek bir zayıflık değil; doğru kullanıldığında misafiri tutan kontrollü bir araçtır.
Hangi durumlarda misafire upgrade veya ikram gibi telafi sunmalıyım?
Telafi; otelin hatası netse, misafir ciddi zaman/konfor kaybı yaşadıysa veya çözüm süresi uzadıysa devreye girer. Telafi türü hatanın büyüklüğüyle orantılı olmalı; standart bir “telafi merdiveni” (küçük→orta→büyük) belirlenmelidir.
Telafi merdiveni (pratik)
- •Küçük telafi: içecek/ikram, geç check-out
- •Orta telafi: oda konumu iyileştirme, küçük indirim, transfer desteği
- •Büyük telafi: upgrade, 1 gece farkı, paket telafisi (yetki sınırına bağlı)
Ne yapmalıyım?
- • Telafi yetki limitlerini yaz (FO/Rezervasyon/GM)
- • Telafi merdivenini ekip eğitimine koy
- • Telafiyi “özür + net çözüm” ile birlikte ver (tek başına değil)
- • Şikayet sonrası yorum takibini rutine bağla
5. KPI’lar ve “Service Recovery” Örnekleri
İzlenecek temel KPI seti
- •Çözüm süresi (median)
- •İlk temasta çözüm (FCR)
- •Telafi oranı ve telafi maliyeti
- •Şikayet sonrası yorum skoru trendi
- •Tekrar rezervasyon sinyali (CRM/segment)
Ne yapmalıyım?
- • Case ID ile kayıt açmayı zorunlu yap
- • Haftalık “en çok tekrar eden 3 vaka” raporu çıkar
- • Root-cause aksiyonlarını takip et (mapping/senkron/süreç)
- • Rol-play eğitimlerinde gerçek vakaları kullan
6. Şikayet Anında Söylememeniz Gereken 5 Cümle
- “Bizde görünmüyor, yapacak bir şey yok.”
- “Siz yanlış anlamışsınız.”
- “OTA ile konuşun, bizim işimiz değil.”
- “Kurallar böyle, size yardımcı olamam.”
- “Şu an çok yoğunum, sonra arayın.”
Yerine: “Hemen kontrol ediyorum, iki seçenekle döneceğim” gibi güven ve aksiyon dili kullanın.
7. Fark Yaratan Mini Bölüm: Uyuşmazlığı “Vaka”ya Çevirip Tekrarını Önlemek (Competitor Gap)
Rakip içerikler genelde genel müşteri ilişkileri tavsiyesi verir; oysa rezervasyon uyuşmazlığı “vaka tipi + çözüm akışı + yetki sınırı + KPI” ile yönetilmelidir. Bu rehberin farkı; uyuşmazlığı anlık kriz olmaktan çıkarıp, case ID ile kayıt altına alan, root-cause’a bağlayan ve service recovery merdiveniyle standartlaştıran bir sistem sunmasıdır. Böylece rol-play eğitimleri için de temel metin olur.
8. Rezervasyon Uyuşmazlıkları Çözüm Akışı & Telafi Şablonunu İndir — CX Recovery
Rezervasyon Uyuşmazlıkları Çözüm Akışı & Telafi Şablonunu İndir — CX Recovery (v1.0)
Bu asset, rezervasyon uyuşmazlıklarını 5 temel vaka tipinde sınıflandırıp “tespit → iletişim → çözüm → kayıt → önleme” akışını standardize eder. Amaç; çözüm süresini kısaltmak, misafir kaybını azaltmak ve OTA–otel ilişkisini zedelemeden service recovery telafilerini kontrollü uygulamaktır. Rol-play eğitimlerinde kullanılacak net cümle bankası ve telafi merdiveni içerir.
Kim Kullanır?
Ön büro + rezervasyon + çağrı merkezi satış sonrası destek (GM/revenue sponsorluğunda).
Nasıl Kullanılır?
- Uyuşmazlığı 5 tipten birine sınıflandır ve ilk 3 kontrolü çalıştır.
- Misafire 2 seçenekle dön, gerekiyorsa telafi merdivenine göre çözüm sun.
- Case ID ile kaydet, kök neden aksiyonunu takip listesine ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ DisputeType sınıflandı mı? (Tarih/Oda/Fiyat/Kayıp rez/İptal-no-show)
- ▢ ✅ Kanıtlar toplandı mı? (ref no, voucher, ekran görüntüsü)
- ▢ ✅ İlk 60 saniye güven cümlesi kuruldu mu?
- ▢ ✅ 2 çözüm seçeneği hazır mı?
- ▢ ✅ Telafi gerekiyorsa seviye belirlendi mi?
- ▢ ✅ Case ID + neden kodu kaydedildi mi?
- ▢ ✅ Root-cause aksiyonu açıldı mı (mapping/senkron/eğitim)?
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Vaka tipleri, çözüm SLA’sı ve telafi politikasını standardize ederek çözüm süresini kısaltır ve misafir kaybını azaltır.
Sık Sorulan Sorular
En sık görülen rezervasyon uyuşmazlıkları nelerdir?▾
Tarih/oda/fiyat uyuşmazlığında ne yapmalıyım?▾
“Rezervasyon görünmüyor” şikayetini nasıl yönetirim?▾
Hangi durumlarda misafire upgrade veya ikram gibi telafi sunmalıyım?▾
Şikayet sonrası tekrarını nasıl önlerim?▾
İlgili İçerikler