Misafir Deneyimi Yönetimi: Otelde Tek Profil, Akıllı Öneri

Otelinizde üç gece kalan, iki akşam restoranınızda yemek yiyen ve bir kez spa'ya giren misafiri sistemleriniz büyük ihtimalle üç ayrı kişi olarak tanıyor. PMS'te (otel yönetim yazılımı) bir kayıt, restoran POS'unda (kasa yazılımı) bir masa numarası, spa'nın randevu defterinde bir telefon var; bu üçünü birbirine bağlayan tek şey, o misafirin hafızası. Misafir deneyimi yönetimi denen işin özü bu üç kaydı bir profilde toplamak, sonra da o profili misafir daha kapıdan girmeden işe koşmaktır.

Bu yazı, otel ve restoranın (aynı çatı altında ya da anlaşmalı komşu olarak) tek misafir profili kurmasının adımlarını, yapay zekanın bu profille gerçekten ne yapabildiğini ve KVKK'nın nerede sınır çizdiğini anlatıyor. Tek tesisli butik otelden çok çıkışlı tatil köyüne kadar geçerli. Otelin talep tarafını daha önce otel doluluk tahmini yazısında, geri bildirim tarafını otel yorum analizi yazısında işledik; bu yazı ikisinin arasındaki konaklama süresine odaklanıyor. Sektörün bütünü için sektör sektör yapay zeka haritamız var.

Neden şimdi? Çünkü Türkiye turizminin 2025 tablosu büyümeyi kişi başı harcamaya bağladı: yaklaşık 64 milyon ziyaretçi, 65,2 milyar dolar gelir, kişi başı 1.008 dolar. Bakanlık verilerine dayanan bu rakamların söylediği şey açık: gelir artışı artık gelen sayısından çok, gelen misafirin tesiste ne kadar harcadığına bağlı. Restoran, spa ve ek hizmetler bu harcamanın adresi; tek profil de o harcamayı tesadüfe bırakmamanın aracı.

Misafir deneyimi yönetimi nedir, CRM'den farkı ne?

CRM (müşteri ilişkileri yazılımı) misafirle yazışmaları ve kampanyaları yönetir; misafir deneyimi yönetimi ise konaklama boyunca yaşananları (oda, yemek, spa, şikayet, tercih) tek kayıtta toplar ve operasyona geri verir. Fark, verinin yönünde. CRM misafire mesaj gönderir; deneyim yönetimi resepsiyona, garsona ve kat hizmetlerine "bu misafir kim" bilgisini götürür.

Sektörde bunun teknik adı CDP (müşteri veri platformu): PMS, POS, rezervasyon motoru, spa yazılımı ve anket sonuçlarını tek profilde birleştiren katman. Revinate, Cendyn ve Amadeus gibi büyük sağlayıcılar bunu otelciliğe özel paketliyor; Revinate'in kendi anlatımına göre Mews (PMS), SevenRooms (restoran rezervasyonu) ve Book4Time (spa) verileri doğrudan profile akıyor. Fiyatları teklife dayalı, yani küçük tesis için çoğu zaman bütçe dışı. Aşağıda daha ucuz yolu da anlatacağız.

Şunu baştan netleştirelim: hiçbir CDP veriyi kendiliğinden temizlemiyor. Profil birleştirme, aynı kişiyi tanıyan bir anahtara (e-posta, telefon, pasaport numarası, sadakat kartı) dayanır. Tur operatörü üzerinden gelen bir Alman ya da Rus misafir sisteminize çoğu zaman acentenin kaydı olarak düşer; e-postası yok, telefonu yok. O profil boş kalır. Türkiye'nin en büyük iki kaynak pazarının önemli bir bölümünün paket turla geldiğini düşünürseniz, bunun küçük bir ayrıntı olmadığı görülür.

Otel PMS'i ile restoran POS'u nasıl entegre edilir?

İki ayrı seviyede: folyo entegrasyonu ve profil entegrasyonu. Folyo entegrasyonu restoran adisyonunu oda hesabına yazar; Türkiye'de HMS Otel Programı ile Adisyo bağlantısı tam olarak bunu yapıyor ve çıkış işlemini hızlandırıyor. Profil entegrasyonu ise adisyonun içeriğini (ne yedi, ne içti, kaçta geldi, masayı beğendi mi) misafir kaydına taşır. Çoğu tesis birincisini yapmış olup ikincisini yapmış sanıyor.

Aradaki fark bir örnekle daha net. Folyo düzeyinde otel şunu bilir: 204 numaralı oda salı akşamı restoranda 3.400 TL harcadı. Profil düzeyinde şunu bilir: Herr Weber salı akşamı 20.30'da geldi, deniz manzaralı masayı istedi, levrek ve bir şişe yerli beyaz şarap söyledi, tatlı yemedi, fişte "servis yavaştı" notu var. İlk bilgi muhasebenin işine yarar; ikincisi ertesi akşam garsonun, bir sonraki sezon satış ekibinin.

Profil entegrasyonunun teknik reçetesi üç parça:

• Ortak anahtar: POS'ta masa açılırken oda numarası ya da telefon girilir; oda numarası PMS'teki misafir kimliğine çözülür. Bu tek adım olmadan gerisi çalışmaz.
• Kalem düzeyinde aktarım: POS'un API'si (yazılımlar arası veri kapısı) ya da gece sonu dışa aktarımı, adisyon kalemlerini toplam tutar yerine ürün ürün gönderir. SambaPOS gibi açık mimarili yerli POS'larda bu kolay; kapalı sistemlerde dışa aktarım dosyasıyla idare edilir.
• Tercih alanları: Profilde serbest metin yerine yapılandırılmış alanlar: masa tercihi, alerji, sevdiği içecek türü, çocuklu mu. Yapay zekanın öneri üretebilmesi için alanların tutarlı olması gerekir.

Anlaşmalı komşu restoran senaryosunda (otel sizin, restoran başkasının) aynı reçete geçerli, ama araya bir veri paylaşım sözleşmesi girer; aşağıdaki KVKK bölümünde neden gerektiği var.

Yapay zeka misafir önerisini nasıl yapar?

Büyük bir dil modeliyle değil; işin yüzde 80'i kurallar ve basit istatistikle çözülür. "Tekrar gelen misafire önceki tercih ettiği şarabı öner", "alerji alanı doluysa menü önerisinde o kalemi çıkar", "çocuklu profilde erken saat masası ve çocuk menüsünü öne al" gibi kurallar, tesisinizin yıllardır iyi garsonların kafasında tuttuğu bilgiyi sisteme yazmaktır. Yapay zekanın katkısı iki yerde: kural yazmadığınız örüntüleri POS geçmişinden bulmak ve bunu misafire doğal dilde, doğru dilde söylemek.

Birinci katkı öneri motoru: 200 odalı bir tesisin bir sezonluk POS verisi, hangi ürünlerin birlikte sipariş edildiğini, hangi milliyetin hangi saatte yemeğe indiğini, hangi masaların tekrar istendiğini gösterir. Bu, e-ticaretteki "bunu alanlar şunu da aldı" mantığının restoran hâli; teknik adı işbirlikçi filtreleme, kurulumu birkaç günlük veri bilimi işi. İkinci katkı mesaj katmanı: profil + kural + öneri, misafirin dilinde bir varış öncesi e-postaya ya da WhatsApp mesajına dönüşür. Dil modelleri burada gerçekten iyi; Rusça, Almanca ve İngilizce üç ayrı metin yazan bir çalışana ihtiyacınız kalmıyor.

Somut bir Antalya senaryosu kuralım. 180 odalı, biri a la carte iki restoranı ve bir spa'sı olan bir tatil köyü. Kurulan düzen şu: check-in'de PMS kaydı oluşur, POS'ta oda numarası zorunlu alan, spa yazılımı gece sonunda randevuları profile yazar. Sistem her sabah üç liste üretir: bugün ikinci kez gelen misafirler (garsona "geçen sefer ne söylediği" notuyla), a la carte'a hiç gitmemiş ama ortalama üstü harcayan misafirler (akşam için kişiye özel davet), son 24 saatte şikayet notu düşülen misafirler (misafir ilişkilerine). Üçüncü liste, bu düzenin en değerli çıktısı; buna geleceğiz.

Kişiselleştirme oteller için gerçekten gelir getirir mi?

Getiriyor ama dolaşımdaki rakamların söylediği kadar değil. En çok alıntılanan "kişiselleştirme geliri yüzde 40 artırır" cümlesi McKinsey'nin 2021 araştırmasının çarpıtılmış hâli; orijinal bulgu, hızlı büyüyen şirketlerin gelirlerinin daha büyük bir payını kişiselleştirmeden elde ettiğini söylüyor. Bu, otelinizin cirosunun yüzde 40 artacağı anlamına gelmiyor. "Yüzde 10-30 gelir artışı" bandının da birincil kaynağını bulamadık; üretici bloglarında elden ele dolaşıyor.

Güvenilir sayılabilecek daha mütevazı veriler şunlar. IHG, misafirlerinin odalarını kişiselleştirmek için gecelik ortalama 22 dolar ek harcadığını açıkladı; marka kendi rakamı, ama tesis düzeyinde ölçülmüş. Infor'un otelcilerle yaptığı ankete göre markaların yüzde 71'i kişiselleştirmek istiyor, yalnız yüzde 15'i bunu etkili yaptığını düşünüyor; üretici anketi, ama söylediği şey tanıdık: sorun teknolojiden çok süreç ve personel adaptasyonunda.

Kendi hesabımızı koyalım. Yukarıdaki 180 odalı tesiste yüzde 70 dolulukla ayda yaklaşık 3.800 oda gecesi oluyor. Tek profil düzeninin üç hedefi olsun: a la carte'a davet edilenlerin yüzde 15'i gelsin (ortalama 2.500 TL ek harcama), tekrar gelen misafire doğru öneriyle yemek başına ortalama 300 TL fazla satılsın, erken yakalanan şikayetlerden ayda 10 tanesi yorum sitesine düşmesin. İlk iki kalem ayda kabaca 400-500 bin TL ek ciro demek; bu, bir orta ölçekli entegrasyon projesinin maliyetini bir sezonda karşılar. Üçüncü kalemin değerini rakama vurmak zor, ama yorum analizi yazımızda anlattığımız "8 puan veren misafirin gizli şikayeti" tam olarak bu listede yakalanıyor.

Memnuniyetsizlik erken nasıl tespit edilir?

Sinyal profilde zaten var; birleştirilmediği için görülmüyor. Restoranda yarım bırakılmış bir ana yemek, spa randevusunun iptali, ilk gece 23.00'te resepsiyona açılan iki telefon, kat hizmetlerinin "oda değişikliği istedi" notu. Her biri kendi sisteminde sıradan bir kayıt; aynı misafirde aynı 24 saatte yan yana geldiğinde açık bir uyarı.

Bu uyarıyı üreten şey basit bir puanlama: her olumsuz sinyale ağırlık, eşik aşıldığında misafir ilişkilerine bildirim. Yapay zeka burada serbest metinli notları (garsonun "masadan memnun değildi" yazması, resepsiyonun "klima şikayeti" notu) olumsuz/nötr diye sınıflandırıyor; gerisi toplama işlemi. Tatil köyü senaryosundaki üçüncü liste bundan çıkıyor ve misafir ilişkileri, misafir Booking'e yazmadan önce bir ikram ya da oda değişikliğiyle konuyu kapatıyor. Sahada gördüğümüz kadarıyla tesislerin en hızlı geri dönüş aldığı parça bu; öneri motorundan önce kurulmayı hak ediyor.

KVKK'ya göre misafir verisi profilleme için kullanılabilir mi?

Kullanılabilir, ama otelin zaten yaptığı kimlik bildiriminin dayanağıyla değil. Oteller kimlik verisini 1774 sayılı Kimlik Bildirme Kanunu gereği, yasal yükümlülükle işler; restoran harcamasını, spa ziyaretini ve tercihleri pazarlama amacıyla birleştirmek ise ayrı bir hukuki dayanak ister: açık rıza ya da menfaat dengesi testinden geçmiş bir meşru menfaat. Aydınlatma metninde bu amacın yazması gerekir. Bu bölüm yorum niteliğinde; kendi KVKK danışmanınızla teyit edin.

Üç nokta özellikle dikkat istiyor. Alerji ve engellilik bilgisi sağlık verisidir, KVKK'da özel nitelikli kategoriye girer ve açık rıza olmadan profile yazılamaz; oysa iyi bir restoran deneyimi için en değerli alan tam olarak bu. Çözüm, check-in'de ayrı ve anlaşılır bir rıza satırı. İkinci nokta anlaşmalı restoran: otel ve komşu restoran ayrı veri sorumlusudur; profil paylaşımı için aralarında veri paylaşım sözleşmesi ve aydınlatma metninde paylaşım beyanı gerekir. Üçüncüsü yabancı misafir: AB vatandaşı için GDPR de devreye giriyor; en büyük pazar olan Rusya'nın kendi veri yerelleştirme kuralları var. Profil ne kadar zenginse, uyum dosyası o kadar kalın.

Bir de hukuk dışı sınır var: tırmalama eşiği. Misafirin iki yıl önceki siparişini sormadan hatırlatmak, spa'dan çıktığı dakikada restoran daveti göndermek, çocuğunun adını mesaja yazmak; bunların hepsi teknik olarak mümkün ve hepsi bazı misafirleri rahatsız ediyor. Kural olarak şunu öneriyoruz: profil bilgisi personelin elinde kalsın ve hizmet kalitesine dönüşsün; misafire doğrudan gösterilen kişiselleştirme, misafirin kendisinin verdiği bilgiyle sınırlı olsun.

Küçük ya da butik bir tesis bunu yapabilir mi?

Yapabilir; 30 odalı bir otelin tek profili, Revinate lisansı yerine bir elektronik tablo ve iki entegrasyon kuralıyla başlar. Küçük tesisin avantajı veri hacminin az, personelin misafiri zaten tanıyor olması. Sistem burada personelin hafızasını yazılı ve devredilebilir hâle getiriyor; sezonluk çalışanın gidince bilginin de gitmesini önlüyor.

Asgari düzen şu: PMS'in misafir kaydına 6-8 yapılandırılmış tercih alanı eklenir; POS'ta oda numarası zorunlu olur; haftada bir POS dışa aktarımı profile işlenir; check-in'de rıza satırı alınır. Bu kadarı bir haftalık iş ve çoğu yerli PMS'te (Elektraweb, HMS ve benzerleri) ek modül gerektirmiyor. Öneri motoru ve otomatik mesaj katmanı, veri iki sezon biriktikten sonra anlamlı hâle geliyor; ilk sezon toplama sezonu.

Sık sorulan sorular

Önce hangi sistemi değiştirmeliyiz: PMS mi, POS mu?

Hiçbirini. İlk adım mevcut sistemlerin kalem düzeyinde dışa aktarım yapıp yapamadığını öğrenmek. Yapıyorsa profil katmanı aralarına kurulur; yapmıyorsa önce onu değiştirin, ama tek başına bunun için sistem değiştirmek nadiren gerekiyor.

Sadakat programı şart mı?

Değil, ama en temiz anahtarı verir: kart numarası her sistemde aynı kişiyi işaretler. Sadakat programı olmayan tesiste anahtar oda numarası + konaklama tarihidir; tur operatörü misafirlerinde bile çalışır.

Yapay zeka önerisi menü satışını nasıl etkiler?

Bizim gördüğümüz etki, ortalama adisyona küçük ama düzenli bir katkı: doğru anda önerilen ikinci şişe, tatlı ya da kahvaltıya yükseltme. "Yüzde 30 artış" beklemeyin; çalışan bir düzen yemek başına birkaç yüz TL ekler ve bunu her gün yapar.

Verileri bulutta tutmak KVKK açısından sorun mu?

Yurt dışı sunucuya aktarım ayrı bir aktarım hükmüne tabi. Yerli PMS'lerin çoğu Türkiye'de barındırıyor; yabancı CDP kullanacaksanız aktarım için ek şartlar gerekir. Sözleşmeden önce barındırma ülkesini sorun.

Peki siz ne yapmalısınız?

• Anahtarı seçin: Her sistemde aynı misafiri işaret eden tek alan (sadakat kartı, oda numarası + tarih ya da telefon). Bu karar verilmeden entegrasyon konuşmayın.
• Folyodan kalem düzeyine geçin: POS'un adisyon kalemlerini profile aktarabildiğini doğrulayın; toplam tutar profil değildir.
• Önce şikayet listesini kurun: Üç sistemden gelen olumsuz sinyalleri tek puanda toplayan sabah listesi, öneri motorundan daha hızlı geri döner.
• Rıza satırını check-in'e ekleyin; alerji ve sağlık bilgisini rızasız yazmayın, anlaşmalı restoranla sözleşme yapmadan paylaşmayın.
• Tırmalama eşiğini yazılı kural yapın: Profil bilgisinin hangi kısmı personele, hangi kısmı misafire görünür; bunu sistemden önce kararlaştırın.

Tek profil, yeni bir yazılım satın almaktan çok üç sistemin aynı kişiyi tanımasını sağlamakla ilgili. O sağlandığında yapay zeka önerisi de, erken şikayet uyarısı da, misafirin dilindeki hoş geldiniz mesajı da kendiliğinden gelir. Kendi tesisinizde hangi anahtarın çalışacağını ya da mevcut POS'unuzun kalem düzeyinde veri verip vermediğini çözmek isterseniz, sistem listenizi gönderin; ilk değerlendirmeyi birlikte yapalım.