1. Hata Analizi Nedir, Neden Kritik?
Hata analizi, “kim hata yaptı?” sorusu değildir; “hangi sistem parçası hangi koşulda bozuluyor?” sorusudur. Otel çağrı merkezinde hatalar genellikle tekrar eder; çünkü kök neden çözülmeden “semptom” düzeltilir.
Hata analizinin kritik olmasının 3 nedeni
- Zaman baskısı: yoğunluk anında yanlış müdahale, SLA çöküşünü uzatabilir.
- Maliyet baskısı: hatayı büyütmeden çözmek, kaçan rezervasyon ve şikâyet maliyetini sınırlar.
- Öğrenme döngüsü: aynı hata tekrar etmesin diye süreç standardı gerekir.
Bağlam notu: KPI dalgalanması bazen dış faktörlerden kaynaklanabilir (kampanya, sistem arızası, hava koşulları, uçuş iptalleri). Bu yüzden “bağlam bilgisi” hata analizinin ilk adımıdır.
Ne yapmalıyım?
- • Hata analizini “kök neden” odağına çevir; kişisel suçlama dilinden kaçın
- • Dış faktörleri notlayacağın bir “olay günlüğü” tut (kampanya, arıza vb.)
- • Satış sonrası destek kaynaklı hata sinyalleri için bağ kur: /cagri-merkezi/satis-sonrasi-destek
Mini Check
- • Hata analizi kişi değil sistem odaklı mı?
- • Dış faktör günlüğü var mı?
- • Tekrarlayan hata listesi tutuluyor mu?
- • Her hata için “kök neden” yazılıyor mu?
2. KPI’lardan Hata Sinyallerini Okumak
KPI’lar size “nerede” diye fısıldar. Burada kritik olan, tek metrikle karar vermemek ve sinyali bir “set” halinde okumaktır.
Sinyal setleri (pratik)
- •SLA↓ + Bekleme↑ + Terk↑ → kapasite/planlama/triage sorunu
- •FCR↓ + Repeat Call↑ → bilgi, script, CRM notları veya eğitim sorunu
- •Complaint Rate↑ + Çözüm süresi↑ → süreç/policy netliği veya yetki sorunu
- •Dönüşüm↓ + Hacim sabit → konuşma akışı, teklif netliği veya yanlış trafik (kampanya) sorunu
Alarm sayılmaması gereken durumlar
- •sezon piki (yüksek sezon)
- •kampanya kaynaklı ani talep
- •sistem bakım/arıza anı
Bu yüzden sinyali “bağlam” ile doğrulamadan aksiyon vermek risklidir.
Ne yapmalıyım?
- • Sinyali önce doğrula: segment (kanal/dil/otel tipi) kırılımı ile bak
- • Tek metrik yerine 2–3 metrik seti kullan
- • Satış dönüşüm sapmasını görmek için: /raporlama/satis-donusum
Mini Check
- • Sinyali set halinde mi okuyorum?
- • Segment kırılımı yapılıyor mu?
- • Bağlam (kampanya/arıza) notlanıyor mu?
- • Alarm eşiği “band” mantığıyla mı yönetiliyor?
3. Çağrı merkezi KPI’larını hata analizi için nasıl kullanmalısınız?
“veri → analiz → aksiyon → takip” zinciri:
- 1) Sinyali yakala: SLA/bekleme/şikâyet/tekrar arama gibi KPI bozulmasını işaretle.
- 2) Segmentle: kanal, talep türü, dil, vardiya ve otel bazında kırılım yap.
- 3) Kök neden analizi: 5 Why veya Ishikawa ile insan–süreç–teknoloji–policy kaynaklarını tara.
- 4) Önceliklendir: etki × çaba matrisiyle en hızlı faydayı seç.
- 5) İyileştir: küçük müdahale (script/triage) veya proje (süreç/entegrasyon) uygula.
- 6) Before/after izle: 14–30 gün KPI kıyası + öğrenim notu.
Ne yapmalıyım?
- • Bu 6 adımı haftalık “error review” ritmine bağla
- • Her haftaya 1 ana hata teması seç (KPI overload’u önler)
- • Parent süreçlerde satış sonrası etkisi için: /cagri-merkezi/satis-sonrasi-destek
Mini Check
- • Sinyal segmentleniyor mu?
- • Kök neden metodu standart mı?
- • Önceliklendirme matrisi var mı?
- • Before/after takibi yapılıyor mu?
4. Root-Cause Analizi (Kök Neden)
Kök neden analizi “kanıtlı tahmin” üretir: tek bir nedene atlamaz, seçenekleri sistematik tarar.
5 Why (hızlı yöntem)
- Neden? → Bekleme arttı.
- Neden? → Pik saatte kapasite yetersiz.
- Neden? → Vardiya planı heatmap’e göre güncellenmedi.
- Neden? → Forecast/planlama süreci yok.
- Neden? → Rapor var ama yönetim ritmi/owner yok.
Örnek: “SLA düştü.”
Çıktı: “Vardiya planlama süreci” iyileştirme projesi.
Ishikawa (balık kılçığı) (derin yöntem)
- •İnsan (People): eğitim, dil seviyesi, deneyim
- •Süreç (Process): triage, eskalasyon, policy akışı
- •Teknoloji (Tech): ACD/CRM/PMS entegrasyonu, ekran hızı
- •İçerik (Script/Content): yanlış/eksik script, güncel olmayan bilgi
- •Kapasite (Staffing): vardiya, mola, sezon planı
- •Dış faktör (Context): kampanya, arıza, hava/ulaşım dalgası
Ne yapmalıyım?
- • SLA düşüşlerinde önce “kapasite + süreç + dış faktör” üçlüsünü kontrol et
- • Repeat Call artışında “script + CRM notları + eğitim” tarafına git
- • Kök neden çıktısını tek sayfada yaz; aksiyona dönüşmeyen analiz raporu üretme
Mini Check
- • 5 Why ile hızlı teşhis yaptın mı?
- • Ishikawa ile seçenekleri taradın mı?
- • Dış faktörleri ayıkladın mı?
- • Kök neden “aksiyonlanabilir” mi?
5. İyileştirme Fırsatlarını Önceliklendirmek
Her hata aynı anda çözülmez. Önceliklendirme, “en büyük etkiyi” en hızlı almayı hedefler.
Etki × Çaba matrisi (pratik)
- •Yüksek etki / düşük çaba: hemen yap (quick win)
- •Yüksek etki / yüksek çaba: proje (plan + kaynak)
- •Düşük etki / düşük çaba: fırsat varsa
- •Düşük etki / yüksek çaba: ertele
Örnek iyileştirme türleri
- •Script güncelleme (quick win)
- •Triage akışı düzeltme (quick win / orta)
- •CRM/PMS entegrasyonu (yüksek çaba)
- •Vardiya planı ve forecast sistemi (orta-yüksek)
| İyileştirme Fırsatı | Etki (1–5) | Çaba (1–5) | Öncelik | Sahip | Tarih |
|---|---|---|---|---|---|
| ___ | ___ | ___ | Quick win / Proje | ___ | ___ |
Ne yapmalıyım?
- • Haftada 1 “quick win” kuralı koy; ekip moralini artırır
- • Yüksek çaba projeyi “milestone”lara böl (2 haftalık sprint)
- • Satış dönüşüm ve şikâyet etkisini birlikte izle: /raporlama/satis-donusum
Mini Check
- • Quick win listesi var mı?
- • Proje backlog’u öncelikli mi?
- • Her proje KPI etkisiyle tanımlı mı?
- • Sprint/takip ritmi var mı?
6. İyileştirme Sonuçlarını KPI’larda İzlemek
İyileştirme “yapıldı” demekle bitmez; KPI’da karşılığını görmek gerekir.
Before/After kıyas kuralı
- •Aynı dönem bandı (YoY/MoM dikkat)
- •Aynı segment (kanal/dil/talep türü)
- •Aynı koşul notu (kampanya/arıza)
14–30 gün takip döngüsü
- •Gün 0: değişiklik yayına alındı
- •Gün 7: erken sinyal kontrolü
- •Gün 14–30: trend doğrulama + kalıcılık
Varsayım: Veri temelli hata analizi yapan otellerde tekrar eden sorun sayısının ve şikâyet yoğunluğunun zamanla azalabildiği ifade edilebilir; etki, takip disiplinine bağlıdır.
Ne yapmalıyım?
- • Her iyileştirmeye 1 “takip KPI seti” ata (2–3 KPI yeter)
- • Sonucu bir sayfalık “öğrenim notu”na yaz (tekrar etmesin)
- • Satış sonrası destek KPI etkisini de kontrol et: /cagri-merkezi/satis-sonrasi-destek
Mini Check
- • Before/after kıyası segment bazlı mı?
- • Takip periyodu tanımlı mı?
- • Öğrenim notu yazılıyor mu?
- • Aynı hata tekrar ediyor mu (trend)?
7. Fark yaratan mini bölüm: “Hangi KPI hareketleri alarm olmalı?” (Rakip boşluğu kapatma)
Alarm setini basit tut:
- •SLA↓ + bekleme↑ aynı anda → kapasite/süreç alarmı
- •Repeat Call↑ + FCR↓ → bilgi/kalite alarmı
- •Complaint Rate↑ → süreç/policy/empati alarmı
- •Dönüşüm↓ (hacim sabit) → teklif/süreç alarmı
Ne yapmalıyım?
- • Alarm setini haftalık review’da 1 kez gözden geçir
- • Alarm → kök neden → aksiyon zincirini yazılı hale getir
- • Satış dönüşüm etkisini birlikte izle: /raporlama/satis-donusum
Mini Check
- • Alarm seti az ve anlaşılır mı?
- • Her alarmın aksiyon karşılığı var mı?
- • Bağlam notu ekleniyor mu?
- • Alarm sonrası öğrenim yazılıyor mu?
8. Hata Türü & Önceliklendirme Şablonunu İndir — Çağrı Merkezi / Improvement
Hata Türü & Önceliklendirme Şablonunu İndir — Çağrı Merkezi / Improvement (v1.0)
Bu asset, KPI sinyallerini (SLA düşüşü, bekleme artışı, Repeat Call ve Complaint Rate) sistematik hata analizine çevirir. Kök neden (Ishikawa/5 Why) alanları, etki×çaba önceliklendirme tablosu ve before/after takip şablonlarıyla iyileştirme projelerini yönetilebilir hale getirir.
Kim Kullanır?
Call center lead, kalite/süreç geliştirme, operasyon, satış sonrası destek lideri.
Nasıl Kullanılır?
- KPI sinyalini ve bağlam notunu (kampanya/arıza/sezon) girin.
- Kök neden adaylarını Ishikawa ile tarayıp 5 Why ile daraltın.
- Etki×çaba ile önceliklendirin ve 14–30 gün KPI before/after takibi yapın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Hata Sinyali Kaydı (günlük/haftalık)
- ▢ ✅ Kök Neden (Ishikawa) Alanı
- ▢ ✅ Önceliklendirme Tablosu (etki×çaba)
- ▢ ✅ İlk 10 Aksiyon Listesi
- ▢ ✅ Before/After KPI Takibi
- ▢ ✅ Deliverables + “Buraya:” notları
- ▢ ✅ KPI trend grafiği (Diagram)
- ▢ ✅ Ishikawa diyagramı (Diagram)
- ▢ ✅ Etki×çaba matrisi (Card)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: KPI’ı “rapor”dan “sorun radarına” çevirdiğinizde iyileştirme hızlanır
Çağrı merkezi KPI’ları doğru okunduğunda, hataların nerede yoğunlaştığını ve hangi süreç adımının koptuğunu gösteren bir radara dönüşür. Sinyali set halinde okuyup segmentledikten sonra, root-cause analizi ile gerçek nedeni bulur; etki/çaba matrisiyle doğru işi önce yapar ve sonucu before/after KPI kıyasıyla doğrularsınız. Bu sistematik döngü, tekrar eden sorunların azalmasına ve ekip performansının daha sürdürülebilir hale gelmesine yardımcı olabilir.
Bir Sonraki Adım
SLA düşüşü, tekrar arama ve şikâyet artışı gibi KPI sinyallerini kök neden analizine ve iyileştirme projelerine çevirmek isteyen oteller için.
Sık Sorulan Sorular
Çağrı merkezi KPI’ları ile hata analizi nasıl yapılır?▾
Hangi KPI hareketleri alarm olmalı?▾
Kök neden analizi çağrı merkezinde nasıl uygulanır?▾
İyileştirme sonrasında KPI’larda neye bakmalıyım?▾
KPI dalgalanması her zaman hata mı demektir?▾
SLA düştü, nereden başlamalıyım?▾
İlgili İçerikler