1. KPI Deviation (Sapma) Nedir, Nasıl Tanımlanır?
KPI sapması, KPI’nın hedefin (veya normal bandın) dışına çıkmasıdır. Buradaki kritik nokta: hedefi tek sayı yerine band olarak tanımlamaktır. Çünkü:
Bu operasyon çerçevesi, genel çağrı merkezi hizmetleri yapısı içinde ele alındığında yalnız “alarm gördük” değil, “hangi hat için hangi aksiyon standardımız var?” sorusuna da cevap verir.
- •sezonsallık ve otel tipi (resort/city) KPI davranışını değiştirir
- •pik saatlerde normal band farklıdır
- •kampanya ve dış faktörler kısa süreli dalgalanma yaratabilir
Sapma tanımında 3 katman (pratik)
- •Yeşil (normal band): izleme
- •Sarı (sapma başlıyor): önleyici aksiyon
- •Kırmızı (kriz): zorunlu aksiyon + escalation
Teknik not: Eşik belirlerken sezonsallık ve otel tipi farklarını dikkate almak gerekir; aksi halde ekip “adaletsiz hedef” algısına girer. Sapmanın ne anlama geldiğini kök neden tarafında derinleştirmek için hata analizi ve süreç iyileştirme mantığıyla aynı dili kullanmak gerekir.
Ne yapmalıyım?
- • Her KPI için “band” ve “renk” mantığını yaz (yeşil/sarı/kırmızı)
- • Sapma tanımına “segment” ekle: kanal/dil/talep türü
- • Parent KPI çerçevesi: /cagri-merkezi/performans-analizi
Mini Check
- •KPI hedefi band olarak tanımlı mı?
- •Sarı/kırmızı eşikler net mi?
- •Pik saat bandı ayrı mı?
- •Segment (kanal/dil) sapması görülebiliyor mu?
2. Hangi KPI İçin Hangi Eşikler Kullanılmalı?
Eşikler “rastgele rakam” değildir; tarihsel baseline + sezon bandı + işletme hedefi üçlüsünden türetilir.
Bu eşikler aşıldığında playbook’un ilk tetikleyicisi çoğu zaman gerçek zamanlı izleme ve wallboard ekranıdır; alarmı neyin yaktığını görmek için runbook ile canlı ekran aynı tanımları kullanmalıdır.
Çekirdek KPI seti (runbook için)
- •SLA
- •Bekleme/ASA
- •Queue (bekleyen çağrı/mesaj)
- •Complaint Rate (şikâyet)
- •Conversion Rate (rezervasyon dönüşümü)
- •Repeat Call / FCR (Varsayım: ölçülüyorsa)
Eşik belirleme yaklaşımı (baseline)
- •Sezon başlangıcı 2–4 hafta baseline (Varsayım)
- •YoY ile aynı dönem kıyası (özellikle sezonda)
- •Pik saat için ayrı band
Ne yapmalıyım?
- • Eşikleri önce “tarihsel band”tan çıkar, 2 hafta sahada kalibre et
- • Eşik tablosunu vardiya lideri eğitiminde zorunlu yap
- • Satış sonrası destek kaynaklı şikâyet ve çözüm süresi sapmalarını ayrı alarm ailesi olarak tanımla
Mini Check
- •Baseline çıkarıldı mı?
- •Sezon/pik saat bandı ayrı mı?
- •Eşikler kalibre edildi mi?
- •Her eşik için aksiyon karşılığı var mı?
3. KPI bazlı runbook ve aksiyon planlarını nasıl hazırlamalısınız?
AEO için 4–6 adım:
Hibrit vardiya kurgusunda amaç yalnız kimin evden çalışacağını belirlemek değildir; hangi saat diliminde hangi kanal ve talep türü için ne kadar erişilebilir kapasite gerektiğini de netleştirmektir. Bu nedenle remote slot planını çağrı hacmi tahmini ve kapasite planlama mantığıyla birlikte okumak gerekir.
- •1) KPI seçimi: SLA, bekleme, kuyruk, şikâyet, dönüşüm gibi çekirdek KPI setini belirle.
- •2) Eşik/band tanımı: sezon, otel tipi ve pik saat bandıyla sarı/kırmızı eşikleri yaz.
- •3) Sahiplik: her runbook’a rol ata (vardiya lideri, supervisor, IT/ops, eğitim).
- •4) Aksiyon akışı: triage → hızlı müdahale → eskalasyon → stabilizasyon adımlarını yaz.
- •5) Kanıt & kontrol: kontrol listesi (hangi ekranlara bakılacak?) ve log alanı ekle.
- •6) Takip: 14–30 gün KPI before/after + öğrenim notu ile kapat.
Kısa cevap bloğu
Runbook hazırlamak; KPI’yı seçmek, band eşikleri tanımlamak, rol/sahiplik atamak, adım adım aksiyon akışı yazmak ve sonucu takip KPI’larıyla doğrulamaktır.
Burada asıl soru şudur: sapma olunca kim ne yapacak? Bunu rol, süre ve kapanış notuyla yazmadığınız sürece deviation playbook yalnız teori olarak kalır.
Ne yapmalıyım?
- • Runbook’ları merkezi depoda tut (tek link, herkes bilir)
- • “Sarı” aşamasında önleyici aksiyon, “kırmızı”da zorunlu aksiyon kuralını uygula
- • Satış ve dönüşüm raporları ile aksiyonların rezervasyon ve gelir etkisini aynı takip setine bağla
Mini Check
- •Sahiplik ve escalation net mi?
- •Kontrol listesi var mı?
- •Aksiyonlar yazılı mı (kişiye bağlı değil)?
- •Takip ölçümü planlı mı?
4. KPI Sapmalarına Karşı Runbook Yapısı
Runbook tek sayfalık, kriz anında okunabilir olmalıdır. Önerilen şablon:
Runbook sayfası (tek sayfa)
- •KPI adı + sapma tanımı (sarı/kırmızı band)
- •Ne zaman tetiklenir? (ör. 10 dk üst üste) (Varsayım)
- •Hızlı kontrol listesi (3–5 kontrol)
- •Aksiyon adımları (1–2–3)
- •Eskalasyon (kim aranır / hangi ekip)
- •Log alanı (tarih, aksiyon, sonuç)
- •Takip KPI seti (14–30 gün)
Ne yapmalıyım?
- • Runbook sayfasını “tek ekran” yap; uzun doküman kriz anında okunmaz
- • Her runbook’ta “log alanı” zorunlu olsun (öğrenme döngüsü)
- • Owner ataması olmadan playbook yayınlama; her satırda sorumlu rol ve kapanış süresi olsun
Mini Check
- •Tek sayfa mı?
- •3–5 kontrol listesi var mı?
- •Aksiyonlar sıralı mı?
- •Log alanı var mı?
5. Örnek KPI Deviation Senaryoları
Bu bölüm, ekiplerin kriz anında “ne yapacağım” sorusunu cevaplar.
Senaryo 1: SLA Düşüşü
Tetik: SLA kırmızı banda düşer (sezon/pik saat bandına göre).
Bu tetik çoğu zaman alarm katmanında görünür; aynı sinyali runbook’a bağlamak için gerçek zamanlı izleme ve wallboard kurulumundaki eşiklerle burada kullanılan eşiklerin birebir örtüşmesi gerekir.
Hızlı kontroller:
- •Kuyruk büyüyor mu?
- •Available agent düştü mü?
- •Belirli kanal/dil patladı mı?
Aksiyon (sıra):
- Triage: rezervasyon önceliği + talep türü ayrımı
- Kapasite hamlesi: mola erteleme/ek agent/supervisor desteği (Varsayım)
- Kanal yönlendirme: bilgi taleplerini mesaj kanalına kaydırma (Varsayım)
- Stabilizasyon: backlog ve geri dönüş planı
Takip: SLA toparlanma süresi + terk + repeat call trendi.
Senaryo 2: Şikâyet Oranı (Complaint Rate) Artışı
Tetik: şikâyet band üstü artış.
Hızlı kontroller:
- •Hangi talep türü? (iptal/iade, satış sonrası)
- •Hangi otel/segment?
- •Script/policy değişti mi?
Aksiyon:
- 10 örnek kayıt incele (QA) (Varsayım)
- Policy metni ve script netliği düzelt
- Eskalasyon yetkisi/akışı güncelle
Takip: Complaint Rate + çözüm süresi + FCR.
Şikâyet artışı, çoğu zaman doğrudan satış sonrası destek tarafında service recovery gecikmesi ya da beklenti yönetimi sorunu olarak görünür; bu yüzden runbook çıktısı ilgili servis hattına da taşınmalıdır.
Senaryo 3: Dönüşüm (Conversion Rate) Kaybı
Tetik: dönüşüm düşer (hacim sabitken).
Hızlı kontroller:
- •Kampanya trafiği değişti mi?
- •Fiyat/müsaitlik sorunu var mı?
- •AHT/kalite bozuldu mu?
Aksiyon:
- Segment analiz: kanal/dil/talep türü
- Konuşma akışı ve teklif çerçevesi gözden geçirme
- Pazarlama + rezervasyon senkronu (kampanya/landing) (Varsayım)
Takip: conversion + çağrı başına gelir (Varsayım) + QA bulgusu.
Satış odaklı bu sapmalar, çoğu zaman rezervasyon desteği hattında teklif, teyit ve follow-up disiplinine bağlanır; bu yüzden playbook’un rezervasyon ekibiyle ortak kullanılması gerekir.
Ne yapmalıyım?
- • Bu 3 senaryoyu runbook depo “kırmızı sekmesi” yap
- • Satış ve dönüşüm raporları ile dönüşüm kaybını gelir riski olarak aynı dashboard’da göster
- • Şikâyet ve rezervasyon hattı aksiyonlarını servis bazlı ayrı alt runbook’lara böl
Mini Check
- •SLA sapması için triage sırası yazılı mı?
- •Şikâyet artışında QA örnekleme var mı?
- •Dönüşüm düşüşünde kampanya/segment kontrolü var mı?
- •Takip KPI seti tanımlı mı?
6. Runbook’ları Eğitim ve Yönetim Ritmine Entegre Etmek
Runbook’lar kullanılmazsa ölür. Bu yüzden ritme bağlamak şarttır:
- •Yeni başlayan eğitiminde runbook walkthrough
- •Haftalık review’da 1 sapma vakası post-mortem
- •Aylık ritimde eşik/band kalibrasyonu (sezon değişimi)
Varsayım: Runbook olmayan yapılarda reaksiyonlar kişiye bağlı ve tutarsız olabilir; runbook kullanan yapılarda daha öngörülebilir ve hızlı aksiyon alınabildiği ifade edilebilir.
Bu disiplinin kalıcı olması için aksiyonların hangi toplantıda kapanacağını önceden tanımlamak gerekir; bu ayrımı raporlama frekansı ve yönetim ritmi yapısı netleştirir.
Ne yapmalıyım?
- • Runbook’ı “intranet/tek link” olarak yayınla; arama devri bitti
- • Her sapma sonrası log’u doldurmayı zorunlu yap
- • Günlük huddle, haftalık post-mortem ve aylık eşik kalibrasyonunu ayrı sahiplere bağla
Mini Check
- •Eğitimde runbook öğretiliyor mu?
- •Haftalık post-mortem var mı?
- •Eşikler sezona göre kalibre ediliyor mu?
- •Runbook log’u tutuluyor mu?
7. Fark yaratan mini bölüm: “KPI–Eşik–Aksiyon” tek tablo (Rakip boşluğu kapatma)
Bu tek tablo, kriz anında bakılacak en pratik araçtır:
| KPI | Sarı Band | Kırmızı Band | İlk Kontrol | İlk Aksiyon | Eskalasyon | Takip KPI |
|---|---|---|---|---|---|---|
| SLA | — | — | Queue/availability | kapasite + triage | supervisor/ops | toparlanma süresi |
| Bekleme | — | — | pik saat mi? | mola/overflow | ops | terk |
| Complaint Rate | — | — | talep türü | QA örnekleme | kalite/HR | FCR |
| Conversion Rate | — | — | kampanya/segment | script/teklif | satış/marketing | gelir (Varsayım) |
8. KPI–Eşik–Aksiyon Tablosu & Runbook Şablonunu İndir — Deviation Playbook
KPI–Eşik–Aksiyon Tablosu & Runbook Şablonunu İndir — Deviation Playbook (v1.0)
Bu asset, otel çağrı merkezinde KPI sapmalarını band eşikleriyle tanımlayıp tek sayfalık runbook’lara dönüştürmenizi sağlar. SLA, bekleme/kuyruk, Complaint Rate ve Conversion Rate sapmalarında hızlı kontrol listesi, aksiyon adımları, escalation ve takip KPI seti sunar.
Kim Kullanır?
Vardiya lideri/supervisor, call center lead, kalite/operasyon, satış dönüşüm sorumlusu.
Nasıl Kullanılır?
- KPI’ları seçip sezona/otel tipine göre sarı-kırmızı band eşiklerini yazın.
- Her KPI için runbook sayfasını doldurun (kontrol→aksiyon→escalation).
- 14 günlük sprintle pilot uygulayın; log ve takip KPI’larıyla kalibre edin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) KPI–Eşik–Aksiyon Tablosu (şablon)
- ▢ ✅ B) Runbook Sayfası (tek sayfa şablon)
- ▢ ✅ C) 14 Günlük Sprint Planı
- ▢ ✅ D) Kontrol listesi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: KPI sapmasını kişiye değil runbook’a bağlarsanız performans stabil olur
KPI sapmalarında en büyük risk, tutarsız ve gecikmiş reaksiyondur. Runbook; sapmayı band eşikleriyle tanımlar, rol/sahiplik atar, triage ve aksiyon adımlarını netleştirir, log ve takip KPI’larıyla öğrenme döngüsü kurar. Sezonsallık ve otel tipi farklarını hesaba katan band yaklaşımıyla runbook’lar adil ve uygulanabilir hale gelir; ekip panik yerine prosedürle hareket eder. 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 runbook yapısını genel çağrı merkezi hizmetleri çatısı içinde SLA, şikâyet ve dönüşüm sapmalarında standartlaştırmak isteyen oteller için.
Sık Sorulan Sorular
KPI sapması nedir, nasıl anlaşılır?▾
SLA veya bekleme süresi bozulduğunda ne yapmalıyım?▾
Şikâyet oranı arttığında hangi adımları izlemeliyim?▾
Runbook ve playbook dokümanları nasıl hazırlanır?▾
KPI eşikleri nasıl belirlenmeli?▾
Runbook yoksa ne olur?▾
İlgili İçerikler