1. Grup ve zincir otellerde kanal yönetimi modeli nasıl kurulmalı?

AEO gereksinimine uygun 4–6 maddelik net çerçeve:
6 adımda multi-property model kurma
- Global vs Local ayrımı yap: CorporateRate (global) ve LocalRate (yerel) sınırlarını yaz.
- Rol/izin modelini tasarla: RolePermissions ile “kim neyi değiştirir” netleşsin.
- Kanal rol seti oluştur: Primary/secondary/tactical kanal rolleri grup standardı olsun.
- Multi-property grid standardı belirle: Değişikliklerin nasıl yapılacağı, log/test/rollback adımları yazılsın.
- Tesis esneklik alanlarını tanımla: Pazar/segment/seasonality kaynaklı farklılaştırma izinleri belirle.
- Rapor & kontrol ritmi kur: Haftalık anomali kontrolü + 30/90 günlük strateji review.
Ne yapmalıyım?
- • “Global–Local karar listesi” oluşturun (tek sayfa).
- • Yetkisiz değişiklik riskini RolePermissions ile kapatın.
- • Multi-property değişiklikleri kademeli devreye alın (çekirdek kanallar → tüm kanallar).
2. Tek otelden çok otelli mimariye geçiş (nerede kırılır?)
Çok otelli yapıya geçişte kırılma genellikle “aynı standardı herkese uygula” veya “her tesisi serbest bırak” uçlarında yaşanır. Zincirlerde sürdürülebilir model, iki hedefi aynı anda tutar:
- •Tutarlılık: marka fiyat disiplini, parity, kanal rol stratejisi
- •Esneklik: her tesisin pazarı, sezonu ve rekabetine uygun ayar alanı

Geçişte 4 tip “gizli maliyet”
- •İnsan maliyeti: kim karar veriyor belli değil → çatışma ve gecikme
- •Veri maliyeti: rate plan/mapping farklı → raporlama karşılaştırılamaz
- •Risk maliyeti: yanlış fiyat/kural tüm tesise yayılabilir
- •Fırsat maliyeti: tesis pazarına göre hızlı reaksiyon veremez
Antalya resort + İstanbul city aynı markada neyi değiştirir?
- •Antalya resort: sezon, min-night, paket ve stop-sale daha kritik
- •İstanbul city: etkinlik, kurumsal talep, hafta içi–hafta sonu dinamiği daha kritik
Bu yüzden “global kural” seti, tesise özel ayar alanlarını tanımlamadan çalışmaz.
Ne yapmalıyım?
- • Tesisleri segmentleyin: resort / city / butik / karma.
- • Global–local kural setini bu segmentlere göre netleştirin.
- • Geçişi “pilot oteller” ile başlatın (1 resort + 1 city).
3. 3 tip multi-property model (tam merkezi, hibrit, tam dağıtık)
Bu bölüm, yöneticilere karar matrisi sunmak için “3 model”i netleştirir.

Model 1 — Tam merkezi (Corporate-first)
Ne olur? Fiyat, kampanya, kanal aç/kapat kararları merkezde. Artı: Marka tutarlılığı yüksek, raporlama kolay. Eksi: Tesis reaksiyonu yavaş, yerel fırsat kaçabilir. Kimlere uygun? Ürünleri benzer, pazarları homojen zincirler.
Model 2 — Hibrit (en iyi pratik)
Ne olur? Merkez global kuralları ve CorporateRate çerçevesini koyar; tesis LocalRate ve yerel kampanya/envanter ayarı yapar. Artı: Tutarlılık + esneklik dengesi; sürdürülebilir. Eksi: Rol/izin tasarımı iyi yapılmazsa çatışma çıkar. Kimlere uygun? Antalya/Bodrum resort + İstanbul city gibi karma ürün portföyü olan zincirler.
Model 3 — Tam dağıtık (Property-first)
Ne olur? Tesisler kendi kanal ve fiyatını yönetir; merkez sadece raporlar. Artı: Yerel hız ve çeviklik. Eksi: Tutarsızlık, parity sapması, marka karmaşası; merkez raporu zor. Kimlere uygun? Çok bağımsız çalışan, markası gevşek gruplar (genelde önerilmez).
Karar matrisi (kısa tablo)
| Kriter | Tam Merkezi | Hibrit | Tam Dağıtık |
|---|---|---|---|
| Marka tutarlılığı | Yüksek | Yüksek | Düşük |
| Tesis hızı | Düşük | Orta-Yüksek | Yüksek |
| Operasyon riski | Orta | Düşük-Orta | Yüksek |
| Raporlama | Kolay | Kolay | Zor |
| Karma portföy uyumu | Orta | Yüksek | Orta |
Ne yapmalıyım?
- • Varsayılan olarak hibrit modeli seçip rol/izin tasarımını netleştirin.
- • Tam merkezi modeli sadece ürün/pazar benzerliği çok yüksekse düşünün.
- • Tam dağıtık modeli, marka riskini kabul edebiliyorsanız kullanın.
4. Merkez ofis ve tesis bazlı rol dağılımı (RolePermissions)
Multi-property başarısı “kimin neyi değiştireceği” sorusunu yazılı hale getirdiğinizde gelir. Aksi halde aynı anda iki farklı ekip, aynı kanalı/fiyatı değiştirir; tutarsızlık oluşur.
Örnek rol tablosu (RACI mantığı)
| İş | Merkez Ofis | Tesis | Not |
|---|---|---|---|
| CorporateRate çerçevesi | Sahip | Görür | Marka standardı |
| LocalRate ayarı | Onaylar/limit | Sahip | Pazar esnekliği |
| Kampanya şablonu | Sahip | Uygular | Blok bazlı |
| Envanter payı | Çerçeve | Sahip | Operasyon yakın |
| Kanal aç/kapat | Kural koyar | Uygular | Eşiklerle |
| Mapping standardı | Sahip | Uygular | Test zorunlu |
| Raporlama | Sahip | Katkı | KPI ortak |
“Global Rules” ve “Local Adjustments” örnekleri
- •Global Rules: rate plan isim standardı, parity sınırı, kampanya blok formatı, stop-sale eşikleri
- •Local Adjustments: pazar bazlı kampanya, yerel event dönemleri, envanter payı değişimi, minimum gece
Ne yapmalıyım?
- • RACI tablosunu 1 sayfada yayınlayın ve herkesin erişimine açın.
- • Yetkisiz değişiklikleri RolePermissions ile teknik olarak engelleyin.
- • “Acil durum” prosedürü belirleyin (kim override eder?).
5. Multi-property grid yönetimi (kontrol, test, geri alma)
Multi-property grid, “tek ekranda çok tesis” demektir; bu da hem hız hem risk taşır. En büyük risk, bir kuralın yanlışlıkla tüm tesislere uygulanmasıdır. Bu yüzden multi-property’de “kademeli devreye alma” ve “test/rollback SOP” kritik hale gelir.

Güvenli değişiklik akışı (önerilen)
- Pilot tesis seç: 1 resort (Antalya/Bodrum) + 1 city (İstanbul)
- Çekirdek kanalda uygula: 1–2 primary OTA’da doğrula
- Tesis bazında yay: Aynı değişikliği tüm tesislere değil, segment segment yay
- Kontrol turu: parity, fiyat doğruluğu, kampanya görünürlüğü kontrol
- Rollback planı: hata olursa hızlı geri dönüş SOP
Teknik not (sheet): Bu içerik; /pms-ota/pms-kurulum, /pms-ota/ota-entegrasyonu ve /pms-ota/online-satis sayfalarıyla güçlü iç link almalı ve multi-property kurgunun altyapısını desteklemeli.
Ne yapmalıyım?
- • Multi-property değişiklikleri için “change window” belirleyin (riskli tarih yok).
- • Segment bazlı rollout takvimi oluşturun (resort/city).
- • Rollback yetkisini sınırlayın ve loglayın.
6. Antalya & İstanbul örneğinde uygulama (GEO + ürün farkı)
Antalya/Bodrum resort’lerinde sezon ve min-night/paket stratejileri daha ağır basar; İstanbul city otellerinde event ve kurumsal talep dinamikleri öne çıkar. Hibrit modelde merkez; marka kural setini ve kampanya şablonunu tanımlar, tesis ise pazarına uygun yerel ayarı uygular. Böylece “tek marka altında farklı ürünler” tutarlı ama esnek yönetilir.

Key Statistics / Data Point (sheet, soft): Doğru multi-property modeline geçen zincirlerde merkez ofis raporlamasının kolaylaştığı ve kanal ayarları arasındaki tutarsızlıkların azaldığı örneklerle anlatılabilir.
Ne yapmalıyım?
- • Antalya/Bodrum ve İstanbul için ayrı “local adjustment” listesini yazın.
- • Merkez raporlama dashboard’unda tesis kıyasını standart KPI setiyle yapın.
- • İlk 90 günde 2 rollout dalgası planlayın (pilot → geniş).
7. Multi-Property Kanal Yönetimi Mimari Şablonunu İndir — PMS & OTA Yönetimi (v1.0)
Multi-Property Kanal Yönetimi Mimari Şablonunu İndir — PMS & OTA Yönetimi (v1.0)
Bu şablon, zincir/grup oteller için multi-property channel management mimarisini “global kurallar + yerel ayar alanları” yaklaşımıyla tek dokümana indirger. Rol/izin modeli (RolePermissions), corporate vs local rate sınırları ve rollout (pilot → yayılım) planını birlikte kurgulamanızı sağlar.
Kim Kullanır?
Grup yönetimi, corporate revenue, tesis revenue/ön büro liderleri ve IT/entegrasyon ekipleri.
Nasıl Kullanılır?
- Portföyü segmentleyin (resort/city/butik) ve model seçin (tam merkezi/hibrit/dağıtık).
- Global rules ve local adjustments listesini doldurun; RolePermissions’ı yazın.
- Pilot + rollout takvimi oluşturup KPI’larla 90 gün izleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Global rules ve local adjustments listesi tamam
- ▢ ✅ RolePermissions yazılı ve teknik olarak uygulanabilir
- ▢ ✅ Pilot tesisler ve rollout dalgaları net
- ▢ ✅ Log/audit ve rollback SOP hazır
- ▢ ✅ 30/90 gün review takvime bağlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu

8. Sonuç: Multi-property başarı = tutarlılık + esneklik + rol disiplini
Çok otelli yapılarda kanal yönetimi, tek otel mantığının ölçeklenmiş hali değildir; ayrı bir “yönetim modeli” gerektirir. HotelGroup global kuralları koyar, property yerel ayar yapar; RolePermissions ve grid SOP ile risk kontrol edilir. Hibrit model, karma portföyü olan zincirlerde genellikle en sürdürülebilir çözümdür. Bu içerik, ileride case study’lere referans noktası olarak “multi-property kanal mimarisi” ana otorite içeriği görevini üstlenecek.

Bir Sonraki Adım
Zinciriniz için doğru multi-property modeli seçip merkez–tesis dengesini kurmak isteyen ekipler için.
