1. Neden Veri Modeli Olmadan KPI’lar Yanıltır?
Veri modeli; “hangi alan ne demek, hangi kaynak doğru kabul edilecek, hangi ID üzerinden birleşeceğiz?” sorularının cevabıdır. Veri modeli yoksa KPI’lar üç şekilde yanıltır:
- Tanım çakışması: “rezervasyon tarihi” bir raporda booking date, diğerinde stay date olur.
- Kanal sözlüğü farkı: “direct” bir yerde phone, bir yerde web, bir yerde OTA olarak geçer.
- Çift sayım veya kayıp: aynı çağrı iki yerde sayılır ya da bazı çağrılar hiç eşleşmez.
Varsayım: Veri modeli oturmadan KPI’ları iyileştirmeye çalışmak çoğu zaman yanlış problemi çözmeye çalışmak anlamına gelir; önce temel veri iskeletinin sabitlenmesi gerekir.
Ne yapmalıyım?
- • KPI’lardan önce “tanım sözlüğü” çıkar (tarih, kanal, otel kodu, ID’ler)
- • Tek veri modelini 1 sayfalık şemayla görünür kıl
- • Kurumsal veri mimarisi için veri analiz ve raporlama omurgasını referans al
☑ Mini Check
- • “Tarih” tanımı tek mi (booking vs stay)?
- • Kanal sözlüğü tek mi?
- • Otel kodu her kaynakta aynı mı?
- • Çift sayım kontrolü yapılıyor mu?
2. Hangi Veri Kaynakları Kullanılmalı?
Çağrı merkezi KPI’sı için tek kaynak yeterli değildir. Otel bağlamında en pratik “çekirdek” kaynak seti şudur:
1) Telefon/ACD (Call Center System)
- •aranan numara, arayan numara (Varsayım: gizlilik politikasına göre)
- •kuyruk/skill, çağrı başlangıç-bitiş
- •bekleme süresi, konuşma süresi, wrap-up
- •terk (abandon) ve sonuç kodu
2) PMS ve OTA (Rezervasyon & gelir)
- •rezervasyon ID, otel kodu
- •ADR, doluluk, RevPAR (Varsayım: rapor setine göre)
- •gelir alanları, iptal/iade durumları
- •kanal/segment bilgisi (varsa)
3) CRM (Lead ve misafir kaydı)
- •lead ID, kampanya kaynağı (Varsayım)
- •misafir profili ve iletişim geçmişi
- •follow-up ve satış notları
4) WhatsApp / Web Chat / DM (mesaj logları)
- •konuşma ID, ilk yanıt, çözüm süresi
- •etiketler (talep türü), durum (açık/kapalı)
5) GA4 (web & click-to-call)
- •trafik kaynağı/medium, landing page
- •click-to-call event’leri (Varsayım: kuruluysa)
- •UTM verisi (kampanya eşleştirme)
Bu kaynakları birbirine bağlarken reklam kaynağı, UTM ve call tracking eşleşmesini pazarlama kanalları ile KPI entegrasyonu yaklaşımıyla kurmak; PMS/OTA tarafındaki eşleşmeyi ise rezervasyon yönetimi akışıyla doğrulamak gerekir.
| Data Source | Alan(lar) | KPI Kullanımı | Ortak ID | Timestamp | Not |
|---|---|---|---|---|---|
| Call Center System (ACD) | call_id, queue, wait_time, talk_time, status | SLA, bekleme, terk | call_id | call_start/end | ___ |
| PMS | reservation_id, stay_date, ADR, revenue | gelir, ADR/RevPAR (Varsayım) | reservation_id | booking/stay | ___ |
| OTA | reservation_id, channel, commission (Varsayım) | kanal kârlılığı | reservation_id | booking/stay | ___ |
| CRM | lead_id, source, guest_id | atribüsyon | lead_id | created_at | ___ |
| WhatsApp/Web Chat | conversation_id, first_response, resolution_time | mesaj KPI | conversation_id | msg_ts | ___ |
| GA4 | session_id, source/medium, click_to_call | web→call sinyali | session_id (Varsayım) | event_ts | ___ |
Ne yapmalıyım?
- • Kaynak envanteri çıkar: hangi kaynak hangi KPI’yı besliyor?
- • “Minimum viable data model” ile başla: ACD + PMS + kanal sözlüğü
- • PMS ve OTA eşleşme mantığını rezervasyon yönetimi bağlamında netleştir
☑ Mini Check
- • ACD alanları eksiksiz mi (queue/time/status)?
- • PMS/OTA rezervasyon ID erişilebilir mi?
- • CRM lead ID ile call log eşleşebilir mi?
- • GA4 click-to-call event’leri var mı (Varsayım)?
3. Çağrı merkezi veri modelini nasıl kurmalısınız?
4–6 adım:
- •1) Kaynak envanteri: ACD, PMS, OTA, CRM, WhatsApp, web chat, GA4 kaynaklarını listele.
- •2) Ortak tanımlar: tarih (booking/stay), kanal sözlüğü, otel kodu, talep türü tanımlarını sabitle.
- •3) Ortak ID’ler: call_id, reservation_id, lead_id, conversation_id gibi anahtarları belirle.
- •4) Zaman standardı: timezone, timestamp formatı ve “hangi an” (start/end) tanımını netleştir.
- •5) Konsolidasyon: tek “fact” tablo + boyut tabloları (otel, kanal, zaman, agent) mantığıyla birleştir.
- •6) Test: örneklemle doğrula (10 rezervasyon, 10 çağrı); sayılar tutuyor mu kontrol et.
Kısa cevap bloğu: Veri modelini kurmak; kaynakları envantere almak, tanım sözlüğünü sabitlemek, ortak ID ve zaman standardı belirlemek, veriyi tek modele konsolide etmek ve örneklem testlerle doğrulamaktır.
Ne yapmalıyım?
- • Tanım sözlüğünü “değişmez doküman” yap; raporlar buna uysun
- • İlk sprintte sadece 1–2 KPI’yı uçtan uca doğrula (SLA + rezervasyon atribüsyonu gibi)
- • Ticari çıktıyı görmek için satış ve dönüşüm raporları veri zinciriyle bağ kur
☑ Mini Check
- • Ortak tanımlar yazılı mı?
- • ID eşleştirme stratejisi net mi?
- • Timestamp standardı var mı?
- • Örneklem test yapılıyor mu?
4. Tek Veri Modeli ve Ortak Tanımlar
“Tek model” demek her şeyi tek tabloda saklamak değildir; aynı anlama gelen kavramları tek sözlükte birleştirmektir.
Bu sözlüğün güvenilir kalması için duplicate kayıt, eşleşme hatası ve tanım kayması gibi riskleri veri kalitesi ve data governance disipliniyle birlikte ele almak gerekir.
Ortak tanım sözlüğü (çekirdek alanlar)
- •datetime: timezone + format + olay tipi (call_start/call_end)
- •hotel_code: tek referans liste
- •channel: phone/WhatsApp/OTA/web/ads/seo (kendi sözlüğünüz)
- •call_id: ACD’den gelen birincil anahtar
- •reservation_id: PMS/OTA birincil anahtar
- •lead_id: CRM birincil anahtar (Varsayım)
- •demand_type: rezervasyon/bilgi/iptal/şikâyet
En sık uyumsuzluklar
- •“Kanal”ın bir kaynakta “direct”, diğerinde “phone” olması
- •“Gelir”in brüt/net karışması (Varsayım: komisyon düşülüyor mu?)
- •“Rezervasyon”un oluşturma tarihi ile konaklama tarihinin karışması
Ne yapmalıyım?
- • Sözlüğü versiyonla (v1.0, v1.1) ve değişiklikleri yaz
- • Kanal sözlüğünü pazarlama ve call center ile ortaklaştır
- • Yönetişim çerçevesini veri analiz ve raporlama standardı içinde tanımla
☑ Mini Check
- • Kanal sözlüğü tek mi?
- • Brüt/net gelir tanımı net mi?
- • Rezervasyon tarihi tanımı net mi?
- • Sözlük değişiklikleri kaydediliyor mu?
5. Veri Kalitesi, Temizlik ve Konsolidasyon
Veri modeli kurulduktan sonra KPI güvenilirliği için veri kalitesi şarttır.
Veri kalitesi kontrolleri (pratik)
- •Null/boş alan kontrolleri (otel kodu, timestamp, channel)
- •Duplikasyon kontrolleri (aynı call_id iki kez)
- •Aykırı değer kontrolleri (çok uzun konuşma, negatif bekleme)
- •Eşleşme oranı (kaç çağrı reservation_id ile bağlanabildi?) (Varsayım)
Konsolidasyon yaklaşımı
- •“Fact” tablolar: call_fact, reservation_fact, message_fact
- •“Dimension” tablolar: dim_hotel, dim_channel, dim_time, dim_agent
Bu yapı, dashboard ve self-service analitiği hızlandırır.
Temiz veri modeli görünür hale geldiğinde bunu dashboard ve Looker Studio tasarımı katmanına taşıyabilir, ticari sonucu da satış ve dönüşüm raporları ile aynı sözlükte okuyabilirsiniz.
Teknik not (kilit alanlar): tarih/saat, otel kodu, kanal, reservation_id ve call_id gibi alanlar standartlaşmadan konsolidasyon KPI’yı güvenilir yapmaz.
Ne yapmalıyım?
- • Her dashboard yayını öncesi “data quality checklist” çalıştır
- • Eşleşme oranı düşükse önce ID/timestamp sorununu çöz
- • PMS tarafı ile veri eşleşmesini rezervasyon yönetimi akışıyla birlikte test et
☑ Mini Check
- • Null/duplikasyon kontrolleri var mı?
- • Aykırı değer filtresi var mı?
- • Call→reservation eşleşme oranı ölçülüyor mu?
- • Model performansı (refresh) yeterli mi?
6. Raporlama, Dashboard ve Self-Service Analitik
Veri modeli “arkadaki motor”, dashboard ise “direksiyon”dur. Modeli iyi kurarsanız:
- •KPI’lar tutarlı çıkar
- •Farklı ekipler aynı sayıyı konuşur (marketing, rezervasyon, revenue)
- •Self-service analitik mümkün olur (her soru için BI ekibi beklenmez)
Yönetici paneli için önerilen 3 katman
- •Operasyon: SLA/bekleme/kuyruk
- •Ticari: dönüşüm, kanal bazlı rezervasyon (Varsayım)
- •Gelir: PMS gelir metrikleriyle bağ (Varsayım)
Bu noktada satış dönüşüm ve raporlama sayfaları, veri akışını anlam ağında tamamlar:
Ne yapmalıyım?
- • Dashboard’dan önce “tanım sözlüğü”nü finalize et
- • Self-service için 10 standart soru listesi çıkar (kim ne soruyor?)
- • Raporlama ritmini sabitle (günlük/haftalık/aylık)
☑ Mini Check
- • Tüm ekipler aynı KPI tanımını mı kullanıyor?
- • Dashboard sorulara cevap veriyor mu?
- • Self-service sorgular tanımlı mı?
- • Refresh/latency ihtiyacı net mi?
7. Fark yaratan mini bölüm: “KPI rakamlarım neden tutmuyor?” hızlı teşhis (Rakip boşluğu kapatma)
En sık 5 kök neden:
- Rezervasyon tarihi tanımı farklı (booking vs stay)
- Kanal sözlüğü karışık (direct/phone/OTA)
- Otel kodu eşleşmiyor (multi-property)
- Call ID / Reservation ID yok veya kayıp
- Timezone / timestamp standardı yok
Ne yapmalıyım?
- • Bu 5 maddeyi “ilk kontrol” listesi yap
- • Eşleşme oranını KPI olarak takip et (call→reservation)
- • İlk teşhis çerçevesini veri kalitesi ve data governance standardıyla sabitle
☑ Mini Check
- • Tarih tanımı tek mi?
- • Kanal sözlüğü tek mi?
- • Otel kodu standart mı?
- • ID ve timezone standardı var mı?
8. Çağrı Merkezi Veri Modeli & Alan Haritası Şablonunu İndir — Data Foundation
Çağrı Merkezi Veri Modeli & Alan Haritası Şablonunu İndir — Data Foundation (v1.0)
Bu asset, çağrı merkezi veri modelini kurmak için kaynak envanteri, ortak tanım sözlüğü, ID/timestamp standardı ve veri kalitesi testlerini tek dokümanda toplar. Amaç; ACD/telefon, PMS/OTA, CRM, WhatsApp/web chat ve GA4 verisini aynı veri modelinde birleştirerek KPI’ların tutarlı ve denetlenebilir olmasını sağlamaktır.
Kim Kullanır?
BI/raporlama, call center operasyon lideri, CRM/pazarlama analitiği, otel grubu IT/ops.
Nasıl Kullanılır?
- Kaynak–alan haritasını doldurup hangi KPI’nın hangi alandan beslendiğini işaretleyin.
- Ortak tanım sözlüğünü ve ID/timestamp standardını belirleyin.
- Örneklem test + veri kalitesi checklist’i ile dashboard öncesi doğrulayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kaynak Envanteri & Alan Haritası
- ▢ ✅ Ortak Tanım Sözlüğü (çekirdek)
- ▢ ✅ Zaman Standardı
- ▢ ✅ Veri Kalitesi Checklist
- ▢ ✅ Örneklem Test (10 kayıt)
- ▢ ✅ Deliverables + “Buraya:” notları
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: Veri modeli oturmadan KPI iyileştirmek, yanlış problemi çözmektir
Çağrı merkezi KPI’ları, ancak kaynaklar tek veri modelinde birleştiğinde güvenilir hale gelir. ACD/telefon sistemi, PMS/OTA gelir ve rezervasyon verisi, CRM lead’leri, WhatsApp/web chat logları ve GA4 web sinyalleri; ortak tanımlar, ortak ID’ler ve standart timestamp olmadan aynı şeyi ölçmez. Bu temel iskeleti sabitlediğinizde, dashboard’lar tutarlı konuşur, ekipler aynı dili kullanır ve KPI iyileştirme projeleri “gerçek probleme” odaklanır. Ana çerçeveyi görmek için performans analizi hizmeti sayfasına, detaylı soru-cevaplar için de performans analizi hakkında sık sorulan sorular sayfasına geçebilirsiniz.
Bir Sonraki Adım
Bu veri omurgasını genel çağrı merkezi hizmetleri çatısı içinde telefon, PMS, OTA, CRM ve GA4 kaynaklarını tek sözlükte birleştirerek kurmak isteyen oteller için.
Sık Sorulan Sorular
Çağrı merkezi veri modeli nedir, neden önemlidir?▾
Hangi sistemlerden veri çekmeliyim?▾
PMS, OTA ve telefon sistemi verisini nasıl birleştiririm?▾
Veri modelim bozuksa KPI’larım beni nasıl yanıltır?▾
Farklı sistemlerden gelen rakamlar neden tutmuyor?▾
Veri modeli kurarken en kritik alanlar hangileri?▾
İlgili İçerikler