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:
- 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ı:
- Ö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.
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.
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
İç linkler:
- •Benchmark analizi: https://dgtlface.com/tr/raporlama/benchmark-analizi
- •Looker Studio: https://dgtlface.com/tr/raporlama/looker-studio
- •Çağrı merkezi hizmetleri: https://dgtlface.com/tr/cagri-merkezi-hizmetleri
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
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
İlgili Yazılar