Veri Kalitesi, Data Governance ve KPI Güvenilirliği: Rakamlarınıza Ne Kadar Güveniyorsunuz?

Veri kalitesi; verinin doğru, eksiksiz, tutarlı ve zamanında olmasıdır. KPI’lar ise bu verinin “özetlenmiş karara dönük” halidir. Veri kalitesi bozuksa KPI iki şekilde zarar görür:

Bu güven zemini, genel çağrı merkezi hizmetleri yapısı içinde ele alındığında operasyon, raporlama ve yönetim dili aynı çatı altında birleşir.

• •Yanlış karar: KPI yanlış yön gösterir (SLA bozuldu sanırsınız, aslında timestamp kaymıştır).
• •Güven kaybı: “bu rakam doğru mu?” tartışması bitmez, aksiyon gecikir.

KPI güvenilirliğini belirleyen 4 ana kalite boyutu:

• •Doğruluk: değer doğru mu?
• •Tamlık: alanlar boş mu?
• •Tutarlılık: farklı raporda aynı tanım mı?
• •Zaman: timestamp ve timezone doğru mu?

Çağrı merkezi verisi çok kaynaklı olduğu için belirli “tipik” problemler tekrar eder.

Raporlarda rakamlar neden tutmuyor sorusunun en yaygın cevabı şudur: kaynak farklıysa sonuç da farklı olur. Bu yüzden önce çağrı merkezi veri modeli ve kaynak entegrasyonu mantığıyla ortak eşleşme anahtarlarını sabitlemek gerekir.

1) Yanlış tarih/saat (timestamp) ve timezone

• •olay sırası bozulur (call_start/call_end)
• •SLA ve bekleme yanlış hesaplanır
• •kampanya/yoğunluk analizi kayar

2) Eksik alanlar (missing fields)

• •otel kodu yok → multi-property kıyas bozulur
• •kanal yok → attribution bozulur
• •queue/skill yok → operasyon teşhisi zayıflar

3) Duplicate kayıtlar

• •aynı call_id iki kez düşer → hacim şişer
• •rezervasyon çift sayılır → gelir katkısı yanlış görünür

4) KPI tanım belirsizliği

• •“SLA” bir raporda 20 saniye, diğerinde 30 saniye hedeflenir (Varsayım)
• •“conversion” bir raporda arama→rezervasyon, diğerinde lead→rezervasyon olur

5) Kaynaklar arası eşleşme kaybı

• •call_id ile reservation_id bağlanamazsa “çağrı→rezervasyon” zinciri kopar (Varsayım)

4–6 adım:

Buradaki en kritik disiplin, data owner ve glossary mantığını yalnız dokümana değil günlük kullanıma taşımaktır; aksi halde KPI güvenilirliği kısa sürede yeniden bozulur.

• •1) KPI envanteri çıkar: hangi KPI var, hangi kaynaklardan besleniyor?
• •2) Data Dictionary yaz: KPI Definition + alan sözlüğü + örnek hesap mantığı.
• •3) Roller ata: Data Owner (iş sahibi) ve Data Steward (operasyonel sahip) belirle.
• •4) Otomatik kontroller: timestamp, duplicate, missing, kanal sözlüğü testlerini kur.
• •5) Uyarı & düzeltme: hata olunca kim ne yapacak? SLA’lı düzeltme akışı yaz.
• •6) Sürekli ritim: haftalık data quality review + aylık sözlük güncelleme.

Kısa cevap bloğu

KPI güvenilirliği için sözlük + sahiplik + otomatik kalite kontrolleri + uyarı/düzeltme ritmi gerekir; tek seferlik temizlik yetmez.

Governance, “kimin neye sahip olduğu”nun netleşmesidir. KPI güveni, sahiplik olmadan sürdürülemez.

Owner, steward ve glossary ilişkisi net değilse aynı metrik farklı ekiplerde farklı anlam taşır; bu da güven problemi yerine doğrudan karar problemi yaratır.

Data Owner (iş sahibi)

• •KPI’nın iş anlamından sorumludur
• •tanım sözlüğünü onaylar
• •hedeflerin ve kullanımın doğru olduğundan emin olur

Data Steward (operasyonel sahip)

• •veri akışını ve kalite kontrollerini işletir
• •hataları tespit eder ve düzeltme sürecini yürütür
• •raporların tutarlılığını denetler

Kurallar (minimum set)

• •Tanım sözlüğü onaysız değişmez
• •KPI formülü değişirse “versiyon notu” düşülür
• •Veri kalitesi alarmı olunca rapora “güven bayrağı” eklenir (Varsayım)
• •Kaynak değişimi (PMS/ACD) olduğunda yeniden doğrulama zorunlu

Teknik not: Governance uzun vadeli iştir. Tek seferlik “temizlik” değil, sürekli kontrol ve sahiplik gerekir.

Data Dictionary, “aynı KPI neden farklı çıkıyor?” problemini bitiren temel dokümandır.

Bir KPI sayfasında olması gerekenler

• •KPI adı ve iş amacı
• •tanım (1–2 cümle)
• •veri kaynakları (ACD/PMS/CRM…)
• •alanlar (timestamp, hotel_code, channel…)
• •hesap mantığı (kavramsal)
• •segment kırılımları (otel/dil/kanal)
• •kalite kontrolleri (duplicate/missing)
• •versiyon ve değişiklik notu

Örnek: SLA KPI tanımı (kısa)

• •SLA = belirlenen süre bandında cevaplanan çağrı oranı (Varsayım: kurum tanımı)
• •hangi süre bandı? (20/30 sn gibi)
• •hangi çağrılar dahil? (telefon, mesaj?)

Tanım net olmazsa raporlar ayrışır.

Bu ayrışma yalnız raporlama sorunu değildir; yanlış tanım doğrudan satış ve dönüşüm raporları içinde funnel, rezervasyon ve gelir kararlarını da saptırabilir.

Governance “kuruldu” diye bitmez; sürdürülebilir olmak zorundadır.

Yanlış veriyle güzel panel yapmak hâlâ yanlış karar üretir. Bu yüzden hem dashboard ve Looker Studio tasarımı mantığını hem de genel Looker Studio filtre ve kaynak tutarlılığını aynı sözlükle yönetmek gerekir.

Sürekli izleme ritmi (pratik)

• •Günlük: kritik alarmlar (timestamp bozuldu, duplicate patladı)
• •Haftalık: data quality review (top 5 sorun + aksiyon)
• •Aylık: dictionary güncelleme ve versiyon notları
• •Çeyrek: kaynak değişimi etkisi ve yeniden doğrulama (Varsayım)

“Rapor toplantısı”na düşmeden governance yönetmek

Governance toplantıları kısa olmalı: 15 dakikada

• •3 alarm
• •3 aksiyon
• •1 karar (dictionary değişecek mi?)

Varsayım: Governance süreçleri olan otellerde “bu rakam doğru mu?” tartışmalarının azaldığı ve odağın veriyi değil aksiyonu konuşmaya kaydığı ifade edilebilir. Etki, ritmin disiplinine bağlıdır.

En sık 6 neden:

1. KPI tanımı farklı (SLA bandı, dahil olan çağrılar)
2. Tarih tanımı farklı (booking vs stay)
3. Kanal sözlüğü farklı (direct/phone/OTA)
4. Duplicate kayıtlar
5. Missing alanlar (hotel_code, channel)
6. Timezone/timestamp uyumsuzluğu

KPI güvenilirliği, tek seferlik veri temizliğiyle değil; tanım sözlüğü, rol-sorumluluk, otomatik veri kalite kontrolleri ve düzenli izleme ritmiyle oluşur. Data Owner ve Data Steward sahipliği kurulduğunda, raporlar tutarlı konuşur; ekipler “rakam doğru mu?” yerine “ne yapacağız?”ı tartışır. Bu da çağrı merkezi performans analizini gerçek anlamda aksiyona dönüştürü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.