1. Shared Service Center nedir, zincir oteller için avantajları neler?
SSC, zincirin ortak birimlerini tek merkezde toplama yaklaşımıdır. Çağrı merkezinde SSC; dil bilen agent’ları, eğitim/QA süreçlerini, script/KB yönetimini ve raporlamayı merkezîleştirir. Zincir otellerde temel avantaj; “her otel ayrı ayrı ekip kurmasın”, kalite tek standartta yürüsün ve kapasite sezon dalgasına göre daha iyi kullanılsın.
Bu yapıyı daha geniş çağrı merkezi hizmetleri çatısının zincir otel mimarisi olarak okumak, SSC kararını yalnız ekip paylaşımı değil hizmet kapsamı ve operasyon sorumluluğu açısından netleştirir.
SSC’nin zincir otellerde 4 ana avantajı
- •Dil kalitesi: TR–EN–DE–RU standartlaşır ve sürdürülebilir olur
- •Know-how: script/KB ve operasyon bilgisi merkezde birikir
- •Kapasite verimi: pik–düşük saatlerde oteller arası dengeleme olur (yönlü)
- •Raporlama: tek dashboard ile zincir genel performans görünür
Mini Check
- • Her otel ayrı ayrı “DE/RU” agent bulmaya mı çalışıyor?
- • Aynı soruya farklı otellerde farklı cevaplar mı veriliyor?
- • Zincir KPI’ları tek panelde görülebiliyor mu?
Ne yapmalıyım?
- • SSC’yi “operasyon + içerik + raporlama” üçlüsü olarak tasarlayın.
- • Zincir genelinde satış etkisini satış ve dönüşüm raporları ile aynı KPI sözlüğünde takip edin.
2. Zincir oteller için 4 dilli shared service center modeli nasıl tasarlanmalı?
Kısa cevap: Mimari → queue tasarımı → routing (skill-based) → PMS mimarisi → merkezi raporlama → cross-property süreçler. Zincirde SSC’nin başarısı, “kim hangi otelin konuşmasını görüyor?” sorusuna net cevap vermekten geçer. Marka/bölge/segment bazlı kuyruklar, sahipliği korurken merkezî standardı sağlar.
Merkezi yapı kalıcı olacaksa sahiplik, toplantı ritmi, SLA ve escalation kuralları baştan yazılmalıdır; bu nedenle SSC tasarımını yönetim modeli ve SLA sözleşmesi disipliniyle birlikte kurgulamak gerekir.
Merkezi ekibin içeride mi, partnerle mi yoksa hybrid mi kurulacağı ayrı bir sourcing kararıdır; outsourcing vs inhouse karar rehberi bu mimari kararın sahiplik tarafını netleştirir.
Checklist
- Mimari: SSC çekirdek ekip + otel bazlı escalation owner’ları
- Queue tasarımı: marka/bölge/segment kuyrukları
- Routing: dil + skill + otel/marka yetkinliği (skill-based routing)
- PMS modeli: tek PMS veya çok PMS senaryosu net
- Raporlama: tek dashboard, otel bazlı KPI + benchmark
- Cross-property süreç: sister hotel önerileri, grup/cluster yönetimi
- Governance: RACI, toplantı ritmi, değişiklik yönetimi (KB/script)
“Farklı şehir ve markalardaki otelleri tek 4 dilli çağrı merkezine nasıl bağlarım?” Net cevap: SSC çekirdek ekibini kurup marka/bölge kuyrukları tanımlayın; dil ve skill bazlı routing ile doğru otel bilgisine doğru agent erişsin.
Mini Check
- • “Marka/otel sahipliği” ve escalation owner’ları yazılı mı?
- • Routing kuralı dil + skill + otel bağlamını içeriyor mu?
Ne yapmalıyım?
- • Önce “kuyruk haritasını” çıkarın, sonra teknoloji seçin.
- • Property routing, rezervasyon sistemi ve kayıt standardını PMS & OTA Yönetimi çerçevesiyle birlikte tasarlayın.
3. Marka, bölge ve segment bazlı queue & routing (tasarım prensipleri)
SSC’de en kritik tasarım; kuyrukların “çok” olması değil, “doğru amaçla” olmasıdır. Üç temel yaklaşım vardır: marka bazlı, bölge bazlı, segment bazlı. Çoğu zincirde hibrit bir yapı çalışır: ana kuyruk + alt kuyruklar (tiering).
3 kuyruk yaklaşımı
- •Marka bazlı: farklı marka tonları ve ürün farkları varsa
- •Bölge bazlı: Antalya–Bodrum–İstanbul gibi operasyon farkı varsa
- •Segment bazlı: resort/city/butik farkı süreçleri değiştiriyorsa
Skill-based routing (4 dil + ürün bilgisi)
- •Dil (TR/EN/DE/RU)
- •Ürün bilgisi (marka/otel/segment)
- •Senaryo (rezervasyon, şikâyet, grup, upsell)
Mini Check
- • Agent “her oteli” mi biliyor, yoksa “skill group” ile mi ayrılıyor?
- • Krizde doğru otele doğru kanal nasıl gidiyor?
| Queue tipi | Ne zaman tercih edilir | Routing sinyali | Otel örneği |
|---|---|---|---|
| Marka bazlı | Marka tonu/ürün farklı | marka + dil + senaryo | A marka resort vs B marka city |
| Bölge bazlı | Operasyon farkı yüksek | bölge + dil + kanal | Antalya / Bodrum / İstanbul |
| Segment bazlı | Süreçler farklı | segment + dil + senaryo | Resort / City / Butik |
| Ana kuyruk + specialist | Karmaşayı azaltmak için | dil + öncelik | Tüm zincir + kritik senaryolar |
Ne yapmalıyım?
- • “Ana kuyruk + specialist kuyruk” tasarımını kullanın (karmaşa azalır).
- • Bölge, marka ve segment bazlı talep yapısını otel dijital pazarlama planıyla birlikte okuyun.
4. Tek PMS veya çok PMS ortamında çalışmak (mimari karar)
Zincirlerde iki gerçek senaryo vardır: tek PMS (merkezi) veya çok PMS (otellerde farklı). Tek PMS daha kolay görünürlük sağlar; çok PMS’de ise mapping, erişim ve kayıt standardı kritik hale gelir. Bu noktada BT ile birlikte entegrasyon tasarımını planlamak gerekir; teknik detaylara girmeden konsept düzeyde hedef nettir: tek misafir görünümü ve tek rezervasyon kartı mantığı (mümkün olan ölçüde).
Tek PMS ya da çok PMS fark etmeksizin, property bazlı routing ve rezervasyon kaydı aynı operasyon sözlüğüne bağlanmalıdır; bu nedenle mimari kararı PMS & OTA Yönetimi ile birlikte ele almak gerekir.
Tek PMS senaryosu
- •Merkezi görünürlük ve standart rapor
- •Otel bazlı alanlar (otel kodu, kanal, dil) zorunlu
Çok PMS senaryosu
- •Erişim ve mapping disiplinine ihtiyaç
- •Kayıt standardı yoksa “yanlış otele yanlış kayıt” riski
Mini Check
- • Otel kodu/marka etiketi rezervasyon kartında zorunlu mu?
- • Çok PMS’de “hangi ekibin hangi PMS’e erişimi var?” net mi?
Ne yapmalıyım?
- • Tek/çok PMS fark etmeksizin “otel kodu + dil + kanal” alanlarını standartlaştırın.
- • BT ile “erişim yetkisi” ve “log” planını birlikte kurgulayın.
5. Cross-property upsell ve grup/cluster yönetimi (zincire özgü gelir fırsatı)
SSC’nin zincirde fark yarattığı alanlardan biri cross-property yönetimdir: bir otelde doluluk varsa “sister hotel” önerisi, farklı lokasyonlarda alternatif sunma, grup rezervasyonlarını cluster bazında yönetme. Bu yaklaşım, hem misafiri kaybetmeyi azaltır hem de zincir içinde geliri tutar (yönlü).
Seat paylaşımı, ortak kapasite ve property’ler arası verim finansal kararı da etkiler; fiyatlandırma ve ROI rehberi SSC modelinin ölçek ekonomisi tarafını okumak için iyi bir tamamlayıcıdır.
Sister hotel öneri senaryosu (mini örnek)
- •Antalya resort dolu → aynı zincirde Side alternatifi
- •City otelde tarih dolu → aynı şehirde farklı marka alternatifi
Grup/cluster yönetimi
- •Grup taleplerinde “tek iletişim noktası”
- •Fiyat/koşul standardı + otel bazlı müsaitlik görünürlüğü
Mini Check
- • Alternatif otel önerisi için onaylı script var mı?
- • Gelir paylaşımı/sahiplik net mi? (Governance konusu)
Ne yapmalıyım?
- • Cross-property akışını “satış baskısı” değil “çözüm” olarak konumlayın.
- • Cross-property upsell ve alternatif otel önerilerini satış ve dönüşüm raporları içinde ayrı etiketlerle takip edin.
6. Zincir içinde raporlama, KPI ve benchmark (tek panel)
SSC’nin yönetim değeri, raporlamada ortaya çıkar. Zincir dashboard’ı; otel bazlı performans, dil bazlı kalite, queue bazlı SLA ve oteller arası benchmark göstermelidir. Böylece “en iyi uygulama” paylaşımı yapılır ve zayıf otellere destek planı çıkar.
Tek dashboard’ta minimum kartlar
- •Otel bazlı: yanıt süresi, cevaplanma, dönüşüm (yönlü)
- •Dil bazlı: QA skoru ve şikâyet trendi
- •Queue bazlı: yoğunluk ve kaçan talep
- •Benchmark: zincir ortalaması vs otel
Sektörel içgörü: Shared service doğru kurgulandığında dil kalitesi, raporlama ve kapasite kullanımı iyileşebilir; yanlış kurguda marka/otel sahiplenmesi ve sorumluluk belirsizliği yaşanabilir (yönlü).
Mini Check
- • Zincir genelinde “tek KPI sözlüğü” var mı?
- • Oteller arası benchmark raporu düzenli çıkıyor mu?
Ne yapmalıyım?
- • KPI tanımlarını tek sözlükte standardize edin.
- • Raporlama ve satış dönüşümü bağını satış ve dönüşüm raporları ile güçlendirin.
7. 3 örnek shared service senaryosu
Bu bölüm, kullanıcıya “hangi tasarım bende çalışır?” cevabını verir.
Senaryo 1 — Marka bazlı SSC
- •Farklı markalar, farklı ton/konsept → marka kuyrukları + marka specialist’leri
Mini Check
- • Brand tone ve KB ayrı mı?
Senaryo 2 — Bölge bazlı SSC (Antalya–Bodrum–İstanbul)
- •Operasyon farkı yüksek → bölge kuyrukları + bölge escalation owner’ı
Mini Check
- • Bölge kampanya/doluluk bilgisi akıyor mu?
Senaryo 3 — Segment bazlı SSC (resort/city/butik)
- •Süreç farkı yüksek → segment kuyrukları + senaryo routing
Mini Check
- • Segment prosedürleri KB’de net mi?
Ne yapmalıyım?
- • Tek senaryo seçmek zorunda değilsiniz; “ana kuyruk + alt kuyruklar” ile hibrit tasarlayın.
9. Sonuç: Tek merkez mümkün; ama doğru SSC mimarisiyle
Zincir otellerde 4 dilli çağrı merkezi operasyonunu tek merkezden yürütmek mümkündür; ancak başarı, “tek ekip” yaklaşımından çok “doğru mimari” yaklaşımına bağlıdır. Shared Service Center modeli; marka/bölge/segment kuyrukları, skill-based routing, tek/çok PMS farkını baştan netleştiren çalışma modeli ve merkezi KPI dashboard ile birlikte tasarlandığında zincire ölçeklenebilir bir yapı sunar.
Yanlış kurgu; sahiplenme belirsizliği, sorumluluk karışıklığı ve otel bağlamının kaybolmasına yol açabilir. Doğru kurgu ise dil kalitesini merkezîleştirir, know-how birikimini artırır, raporlamayı görünür kılar ve cross-property upsell gibi zincire özgü fırsatları yönetilebilir hâle getirir.
Ana kapsamı görmek için 4 dilli çağrı merkezi hizmeti sayfasına geçebilir, zincir operasyon ve hizmet modeliyle ilgili detay sorular için 4 dilli çağrı merkezi hakkında sık sorulan sorular bölümünü inceleyebilirsiniz.
Bir Sonraki Adım
Çok lokasyonlu zincirde SSC mimarisi, queue & routing ve KPI dashboard’ı birlikte tasarlamak isteyen ekipler için.
Sık Sorulan Sorular
Zincir oteller için shared service call center modeli nedir?▾
Farklı şehir ve markalardaki otelleri tek 4 dilli çağrı merkezine nasıl bağlarım?▾
Queue & routing yapısını marka/bölge bazlı nasıl oluşturmalıyım?▾
Zincir genelinde KPI ve raporlamayı tek panelde nasıl toplarım?▾
Çok PMS’li zincirde SSC kurulabilir mi?▾
Cross-property upsell nasıl çalışır?▾
İlgili İçerikler