Turizmde AI Müşteri Hizmetleri ve Rezervasyon Yönetimi

Temmuzun ikinci haftası. Deniz manzaralı son oda iki kere satılıyor: biri bir OTA üzerinden, biri telefonda. Kanal yöneticisi stoğu güncelleyene kadar aradan altı dakika geçiyor. Altı dakika. Sonucu ise bir hafta boyunca konuşulacak bir yükseltme, bir özür ve bir yorum puanı. Otelde rezervasyon operasyonunun asıl problemi talebi bulmak değil, dört ayrı yerden gelen talebi tek stok üzerinde tutarlı tutmak. Aşağıda AI müşteri hizmetlerinin bu operasyonun neresinde durduğunu, doluluğa nasıl dokunduğunu ve nerede zarar verdiğini yazıyorum.

Talep dört kanaldan geliyor

Tipik bir tesiste rezervasyon talebi şuralardan düşüyor: OTA'lar, doğrudan telefon, WhatsApp ve Instagram mesajları, bir de web sitesindeki form. İlkinin verisi düzenli, kalan üçü serbest metin. "Ağustosun ilk haftası 2 yetişkin 1 çocuk müsait mi, deniz manzaralı olsun" cümlesi bir rezervasyon sistemine kendiliğinden girmiyor.

Bu talepleri gece 01.00'de kim karşılıyor? Çoğu tesiste kimse. Sabah bakıldığında misafir çoktan başka yerde rezervasyon yapmış oluyor. AI asistanın en somut katkısı burada başlıyor: serbest metni müsaitlik sorgusuna çevirmek ve cevabı beklemeden vermek.

Doğrudan rezervasyonun matematiği

OTA komisyonu her rezervasyonda ciddi bir kalem. Doğrudan kanaldan gelen bir konaklama, aynı fiyattan satıldığında tesise belirgin şekilde daha fazla kalıyor. Dolayısıyla asistanın işi "daha çok rezervasyon" değil, doğrudan kanalı büyütmek olarak tanımlanmalı. Ölçeceğiniz metrik de bu: kanal kırılımında doğrudan rezervasyonun payı.

Yalnız bunu OTA'ları kesmek diye okumayın. OTA görünürlük satıyor ve o görünürlüğü tek başına satın almak çoğu tesis için daha pahalı. Sağlıklı olan şey, OTA'da görülen misafirin ikinci konaklamasını doğrudan yapması. Bunun için de ilk konaklamadan sonra iletişimi elde tutmak gerekiyor — müşteri geri kazanım akışları tam olarak bu iş için var.

Asistanın rezervasyon akışındaki işi

• Müsaitlik sorgusu. Tarih, kişi sayısı, oda tipi. Doğru cevap için stoğu canlı görmesi şart; günlük dosya çekerek çalışan kurulumlar temmuzda çöküyor.

• Fiyat ve koşul bilgisi. Konaklama fiyatı, kahvaltı dahil mi, çocuk politikası, evcil hayvan, erken giriş. Bunlar tesisin en çok sorulan başlıkları ve cevapları neredeyse hiç değişmiyor.

• Ön rezervasyon ve kesinleştirme. Ödeme adımına kadar getirip bağlantıyı göndermek, sonrasını misafire bırakmak. Ödeme bilgisini konuşma içinde toplatmayın.

• Değişiklik talepleri. Tarih kaydırma, oda tipi değiştirme, kişi sayısı güncelleme. Operasyondaki en sıkıcı ve en çok tekrar eden iş bu; devredilmeye en uygun olanı da bu.

Yapmaması gerekenler listesi kısa ama önemli: pazarlık yürütmesin, yetkisi olmayan indirim vermesin, grup taleplerine fiyat çıkarmasın.

İptal, no-show ve iade koşulu

Rezervasyon operasyonunda en çok kavga çıkaran konu iade koşulu. Misafirin "iade edilebilir" sandığı bir tarifeyi asistan yanlış anlatırsa, geriye kalan iş resepsiyondaki tartışmadır. Bu yüzden tarife koşulları asistanın bilgi bankasına serbest metin olarak değil, tarife koduna bağlı olarak girilmeli. Bilmediği bir tarifede cevap üretmesin, aktarsın.

İptali işlerken bir fırsat da var. İptal talebini gören asistan, tarihi kaydırma seçeneğini önerebilir; vazgeçenlerin bir bölümü tesisten değil o tarihten vazgeçmiş oluyor. Bir de bekleme listesi: iptal edilen oda, aynı tarihe daha önce "dolu" cevabı almış misafire otomatik olarak teklif edilebilir. Bunu kuran tesislerde iptal, doluluk kaybı olmaktan çıkıyor.

Overbooking riski senkron gecikmesinde saklı

Dördü de teknik problem gibi görünüyor. Üçü aslında süreç problemi. Entegrasyon tarafını kurmadan asistanı açan tesisler, ilk yoğun hafta sonunda hepsini birden yaşıyor.

Grup ve kurumsal talepler insanda kalsın

Kırk kişilik bir düğün grubu, üç haftalık bir ekip konaklaması ya da acente kontenjanı — bunlar rezervasyon değil, anlaşma. Fiyat kalem kalem konuşuluyor, ödeme planı çıkıyor, iptal koşulu ayrı yazılıyor. Bir asistanın burada yapabileceği tek doğru iş, talebi eksiksiz kaydedip satış sorumlusuna aynı dakikada iletmek.

Aksi halde şu olur: bot standart fiyatı söyler, grup o fiyatı referans alır, satış ekibi daha yüksek bir teklifle geldiğinde güven kaybedilir. Ucuz bir hata değil.

Ön ödeme, depozito ve esneklik dengesi

Tarife yapısı doluluğu doğrudan etkiliyor ve burada sihirli bir cevap yok. Esnek, iade edilebilir tarifeler rezervasyon sayısını yükseltiyor; karşılığında iptal ve no-show oranı da yükseliyor. Ön ödemeli ve katı tarifeler geliri garantiye alıyor ama misafirin bir kısmını daha ilk mesajda kaçırıyor. Çoğu tesis ikisini yan yana satıyor ve doğrusu da bu.

Asistanın işi burada seçim yapmak değil, farkı anlaşılır anlatmak. "Bu fiyat iade edilemez, şu fiyat 48 saat öncesine kadar iptal edilebilir" cümlesi bir tıklama kadar net olmalı. Resepsiyonda çıkan tartışmaların büyük bölümü, bu farkın rezervasyon anında anlaşılmamış olmasından geliyor.

Depozito isteyecekseniz de tutarı ve iade koşulunu aynı mesajda yazdırın. Sonradan söylenen her koşul, misafirin gözünde koşul değil sürpriz.

Pratikte ne yapmalı

Sezon açılmadan iki ay önce başlayın. Önce tarife ve koşul bilgisini tek yere toplayın, sonra stok bağlantısını kurun, en son mesaj kanallarını açın. Ters sırayla giden projeler temmuzda düzeltilmeye çalışılıyor ve orada kimsenin vakti olmuyor.

Doluluk raporunuzda kanal kırılımını görüyorsanız zaten yarısını yapmışsınız demektir. Kalan yarısı için turizm rezervasyon otomasyonu sayfasındaki akış iyi bir başlangıç noktası; kendi tesisiniz üzerinden konuşmak isterseniz AI Agent TR ekibiyle bir demo planlayın.

Sıkça Sorulan Sorular

Asistan ödeme alabilir mi?

Ödemeyi konuşmanın içinde toplamasını önermiyoruz. Güvenli ödeme bağlantısı göndersin, kart bilgisi hiçbir zaman mesajlaşmada dolaşmasın.

Dinamik fiyatlandırma yapabilir mi?

Fiyatı belirleyen sizin gelir yönetiminiz olmalı; asistan o fiyatı doğru okuyup doğru anlatır. İkisini birbirine karıştıran kurulumlar, sonradan kimsenin açıklayamadığı fiyat farkları üretiyor.

OTA rezervasyonlarına da dokunuyor mu?

Doğrudan değil. OTA'dan gelen misafirle konaklama öncesi ve sonrasında iletişim kurabilir; rezervasyonun kendisi platformun kurallarına tabi.

Yoğun sezonda yük kaldırır mı?

Eş zamanlı konuşma sayısı sınırlayıcı değil. Sınırlayıcı olan, stok sisteminizin aynı anda kaç sorguya cevap verebildiği. Yük testini sezon öncesinde yapın, temmuzda değil.