1. Zincir ve çok otelli yapılarda mesaj trafiği nasıl değişir?
Multi-Property yapılarda mesaj trafiği üç nedenle farklılaşır:
Bu mimariyi daha geniş operasyon resmi içinde değerlendirmek için yapıyı çağrı merkezi hizmetleri çatısı altında konumlandırmak faydalı olur.
- Marka ortak kanalları (tek Instagram hesabı, tek WhatsApp hattı gibi)
- Otel bazlı kanallar (her otelin ayrı hesabı)
- Destinasyon dalgaları (Antalya/Belek/Bodrum sezon farklılığı gibi)
Bu yüzden tasarım, sadece “kaç mesaj var” değil; “hangi otele ait ve kim yanıtlayacak” sorusuna dayanır.
Key Statistics / Data Point (yumuşatılmış): Çok otelli yapılarda iyi kurgulanmamış mesaj mimarisinin karışan talepler, yanlış otele yönlenen rezervasyonlar ve takip zorlukları yaratabildiği; net mimaride ise bu risklerin azaldığı yönünde pratik çıkarımlar vardır (kesin rakam iddiası olmadan).
Mini Check
- • Mesajlarınız marka hesabından mı, otel hesabından mı geliyor?
- • Her mesajın “hangi otele ait” işareti var mı?
- • Peak sezonda kapasiteyi grup düzeyinde yönetebiliyor musunuz?
Ne yapmalıyım?
- • Kanalları “marka” ve “otel” diye ikiye ayırıp envanter çıkar.
- • Her kanala bir property ID stratejisi ata (aşağıda).
2. Zincir ve çok otelli yapılarda mesaj yönetimi mimarisini nasıl kurmalısınız?
AEO – 4–6 maddelik temel karar noktaları:
Property bazlı ayrıştırma ve kuyruk mantığının operasyonel karşılığını görmek için ortak inbox ve routing kuralları yaklaşımı iyi bir referans sunar.
- Önce inbox modelini seçin: Shared Inbox mı, otel bazlı inbox mı, hibrit mi?
- Her mesaj için property eşleştirme (hangi otele ait?) kuralı yazın (property ID / destinasyon / marka hesabı).
- Routing Rules’ı çok otelli yapıya uyarlayın: kanal + konu + dil + property → doğru Message Team/otel ekibi.
- Tag standardını grup seviyesinde kilitleyin: kanal/dil/niyet + otel etiketi (property tag).
- KPI’ları iki seviyede tasarlayın: grup KPI (yönetim) + otel KPI (operasyon).
- Yetki ve veri ayrıştırmayı yazın: kim hangi otelin verisini görebilir, rapor filtreleri nasıl olacak?
Mini Check
- • Inbox modeli kararı yazılı mı?
- • Property eşleştirme hatalarını ölçüyor musunuz?
- • Grup ve otel KPI’ları ayrışıyor mu?
Ne yapmalıyım?
- • 3 modelden birini seçip 2 haftalık pilot yap.
- • “Yanlış otele yönlendirme” KPI’ını ilk günden ölç.
3. Marka, otel ve kanal bazlı yapı
Çok otelli mimaride en kritik tasarım, “marka hesabı” ile “otel hesabı” arasındaki ayrımı netleştirmektir.
Merkezi mesaj ekibi ile yerel operasyonların nasıl birlikte çalışacağını planlarken mesaj ekibi ile call center entegrasyonu modelini de aynı tasarımın parçası olarak düşünmek gerekir.
3 yapı tipi (özet)
- •Brand-led: Tek marka hesabı (DM/WhatsApp) → merkezi ekip → otel devri
- •Property-led: Her otelin kendi hesabı → otel ekibi yanıtlar
- •Hybrid: Marka hesabı + otel hesapları birlikte; marka hesabı triage yapar
Franchise / management contract farkı (pratik)
- •Franchise’da otellerin operasyonel bağımsızlığı daha yüksek olabilir → property-led daha uygun olabilir.
- •Yönetim sözleşmesinde (management contract) merkezi standartlar daha baskın olabilir → brand-led/hybrid uygun olabilir.
- •(Varsayım: grup yapısına göre değişir.)
Mini Check
- • Marka hesabından gelen mesajın “hangi otele gideceği” net mi?
- • Otel hesaplarında tone of voice tutarlı mı?
- • Hybrid modelde çifte yanıt riski var mı?
Ne yapmalıyım?
- • Çifte yanıt riskini SOP ile engelle (tek owner kuralı).
- • Marka hesabında “otel seçimi” sorusunu şablonlaştır.
4. Ortak inbox mı, otel bazlı inbox mı?
Bu karar, mimarinin kalbidir. “Tek doğru” yok; doğru olan, hacim + ekip + marka standardı ile uyumlu olandır.
Bu noktada shared ve property-led kararını verirken, ekip atama ve sahiplik kurallarını ortak inbox ve routing kuralları ile birlikte netleştirmek gerekir.
Ortak (Shared) Inbox avantajları
- •Marka tonu ve şablon tutarlılığı
- •7/24 kapasiteyi merkezi yönetme
- •KPI ve raporlamada tek standart
- •Dil bazlı yetkinliği havuzlamak
Otel bazlı Inbox avantajları
- •Yerel operasyon bilgisi daha güçlü
- •Otel özelindeki paket/stoğu hızlı yönetme
- •Misafire “yerinden” destek hissi
Hibrit model (çoğu grup için pratik)
- •Marka hesabı: triage + lead toplama + doğru otele devir
- •Otel hesabı: operasyonel detay ve kapanış
Karar matrisi (kısa)
| Durum | Önerilen model | Ana gerekçe |
|---|---|---|
| Hacim yüksek + çok dilli + merkezi call center | Shared / Hibrit | Standartlaşma ve kapasite yönetimi |
| Hacim orta + otel bilgisi kritik + bağımsız oteller | Property / Hibrit | Yerel bilgi ve operasyon yakınlığı |
Mini Check
- • Merkezi ekipte otel bilgisini “doğru” tutabiliyor musunuz?
- • Otel bazlı modelde raporlama standardı var mı?
- • Hibritte devir notu ve SLA net mi?
Ne yapmalıyım?
- • Hibrit pilot başlat (en düşük risk).
- • Devir kalitesi KPI’ı ekle (eksiksiz bilgi devri).
5. Routing, tag ve KPI’ların çok otelli yapıya uyarlanması
Burada amaç; routing/tag’leri bir kez tasarlayıp tüm grupta standartlaştırmaktır.
Property eşleştirme (en kritik kural)
Her mesaj, bir property ID ile işaretlenmelidir. 3 yöntem:
- •Explicit: Misafir “hangi otel?” seçer (destinasyon/otel listesi)
- •Implicit: Mesaj kanalı zaten otele bağlıdır (otel hesabı)
- •Rule-based: Anahtar kelime/destinasyon + önceki konuşma + rezervasyon kodu (Varsayım: sistem destekliyorsa)
Tag seti (grup standardı)
- •property_id (zorunlu)
- •channel (dm/wa/webchat/ota)
- •language (tr/en/de/ru)
- •intent (saleslead/support/complaint/review)
- •topic (price/availability/cancel/transfer…)
Çok otelli routing örneği (mantık)
channel=dm + intent=saleslead + property_id=belek-resort-01 → Belek otel satış ekibi / merkezi rezervasyon
intent=complaint → grup misafir ilişkileri + otel GM escalation (Varsayım)
Mini Check
- • property_id zorunlu mu?
- • Routing kuralları grup seviyesinde kilitli mi?
- • Yanlış otele giden mesaj “neden kodu” ile izleniyor mu?
Ne yapmalıyım?
- • property_id’siz kapanışı engelle (operasyon standardı).
- • “Yanlış property” kodlarını haftalık analiz et.
6. Raporlama ve yönetim modeli
Multi-Property KPI seti iki katmanlıdır:
Grup seviyesi KPI (yönetim dashboard)
- •Toplam hacim (tüm oteller)
- •Ortalama FRT/RT
- •Yanlış property yönlendirme oranı
- •Grup conversion (lead→rezervasyon)
- •Şikâyet trendi (grup)
Otel seviyesi KPI (operasyon dashboard)
- •Otel hacmi + peak saat heatmap
- •Otel conversion (lead→rezervasyon)
- •Otel şikâyet kapanışı
- •Tag/routing doğruluğu
Merkezi görünürlüğü kurarken hem mesaj yönetimi performans raporlama ve dashboard yapısını hem de yönetsel ekran tarafında Looker Studio kullanımını birlikte düşünmek gerekir.
Tesisler arası performans farklarını ve grup içi standardizasyon seviyesini anlamak için de benchmark analizi perspektifi faydalı olur.
Mini Check
- • Grup dashboard’ı otel bazında filtrelenebiliyor mu?
- • Yönetim KPI’ları ile otel KPI’ları karışmıyor mu?
- • Otel performansını kıyaslamak için standart tanım var mı?
Ne yapmalıyım?
- • KPI sözlüğünü grup düzeyinde kilitle.
- • Dashboard’da “otel filtresi”ni zorunlu yap.
7. Teknik not: Yetkiler, veri ayrıştırma ve rapor filtreleri
Çok otelli yapılarda veri ayrıştırma şarttır:
- •Hangi temsilci hangi otelin mesajlarını görür?
- •Grup yönetimi hangi verileri toplu görür?
- •Franchise otellerde erişim sınırı nasıl çizilir?
Rol bazlı erişim (pratik)
- •Merkezi Message Team: tüm otelleri görebilir ama “kapanış” yetkisi sınırlı olabilir (Varsayım)
- •Otel ekibi: yalnız kendi property’si
- •Yönetim: dashboard seviyesinde toplu + filtreli
Raporlama filtreleri
- •property_id
- •destinasyon
- •segment (resort/city)
- •kanal (dm/wa/ota)
- •dil
Grup Otel Mesaj Yapısı Tasarım Şablonunu İndir — Multi-Property Messaging (v1.0)
Bu şablon, Hotel Group yapılarında mesaj yönetimi mimarisini tasarlamak için inbox modeli seçimi (shared/property/hibrit), property eşleştirme, routing/tag standardı ve KPI katmanlarını tek dokümanda toplar. Amaç; yanlış otele yönlendirme riskini azaltmak, marka tutarlılığını korumak ve grup–otel raporlamasını netleştirmektir.
Kim Kullanır?
Grup operasyon lideri, merkezi mesaj ekibi, otel GM’leri, raporlama/BI ve IT.
Nasıl Kullanılır?
- Inbox modelini seçin ve gerekçesini yazın (hacim/segment/operasyon).
- property_id eşleştirme kurallarını ve routing/tag sözlüğünü kilitleyin.
- Grup ve otel KPI dashboard’larını tasarlayıp pilot uygulama yapın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Seçim: Shared / Property / Hybrid
- ▢ ✅ Gerekçe: ________
- ▢ ✅ Riskler & önlemler: ________
- ▢ ✅ Misafirden otel seçimi (Evet/Hayır): ________
- ▢ ✅ Anahtarlar: destinasyon / önceki kayıt / rezervasyon kodu: ________
- ▢ ✅ Zorunlu alan: property_id (Evet): ________
- ▢ ✅ channel: dm/wa/webchat/ota
- ▢ ✅ language: tr/en/de/ru
- ▢ ✅ intent: saleslead/support/complaint/review
- ▢ ✅ property_id: ________
- ▢ ✅ topic: ________
- ▢ ✅ Grup KPI: ________
- ▢ ✅ Otel KPI: ________
- ▢ ✅ Yanlış property KPI: ________
- ▢ ✅ Merkezi ekip erişimi: ________
- ▢ ✅ Otel ekip erişimi: ________
- ▢ ✅ Franchise sınırı (varsa): ________
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Ölçeklenen mesaj mimarisi, standart ve görünürlük ister
Zincir ve çok otelli yapılarda mesaj operasyonu büyüdükçe asıl ihtiyaç daha fazla kişi değil; daha net mimari, doğru routing ve merkezi görünürlüktür. Property eşleştirme, tek owner kuralı, ortak KPI sözlüğü ve filtrelenebilir dashboard yapısı birlikte çalıştığında karışıklık azalır ve yönetim netleşir.
Bir sonraki adımda ana mesaj yönetimi hizmeti yapısına dönüp ardından mesaj yönetimi hakkında sık sorulan sorular bölümünden operasyon detaylarını netleştirebilirsiniz.
Bir Sonraki Adım
Multi-property yapıda karışan talepleri azaltıp doğru otele doğru lead’i taşımak isteyen gruplar için.
Sık Sorulan Sorular
Zincir otellerde mesaj yönetimi nasıl kurgulanır?▾
Ortak inbox mı, her otel için ayrı inbox mı daha mantıklı?▾
Çok otelli yapılarda mesaj routing ve tag yapısı nasıl olmalı?▾
Grup ve otel bazlı mesaj KPI’ları nasıl raporlanır?▾
Yanlış otele yönlenen talepleri nasıl azaltırım?▾
İlgili İçerikler