Bu rehberi okuduğunuzda, destek operasyonunun omurgasını oluşturan üç soruyu ekibinizin gerçek yapısına göre yanıtlayabileceksiniz: işi kim alır, ne kadar sürede yanıtlar, gecikirse ne olur. Bu üç karar birbirine bağlıdır ve yanlış sırayla verildiğinde birbirini bozar. SLA'sız atama, yükü dağıtır ama gecikmeyi göstermez. Atamasız SLA, gecikmeyi ölçer ama sorumlusunu bulamaz. Eskalasyonsuz ikisi ise sorunu görür, kimseye haber vermez.
Atama Bir Adalet Meselesi Değildir
Atama kuralı kurulurken en sık kurulan cümle şudur: "yük eşit dağılsın". Bu cümle iyi niyetlidir ama yanlış hedeftir. Destek operasyonunda hedef eşit dağılım değil, en kısa çözüm süresidir. Yanlış kişiye eşit dağıtılan iş, iki kez ele alınır ve toplam süre uzar.
Doğru soru şudur: bu talebi ilk seferde çözebilecek kişi kim? Yanıt üç değişkene bağlıdır: yetkinlik, müsaitlik ve müşteriyle önceki temas.
Üç Atama Modeli ve Hangisinin Ne Zaman Doğru Olduğu
Zoho Desk'te atama üç temel biçimde kurulur. Sürüm eşikleri farklıdır ve bu, karar verirken bilinmesi gereken bir kısıttır.
| Model | Nasıl çalışır | Ne zaman doğru | Riski |
|---|---|---|---|
| Doğrudan atama | Koşula göre belirli kişiye veya ekibe düşer | Kural net ve az sayıda olduğunda, uzmanlık ayrımı belirginken | Kişi izinli veya yoğunsa talep bekler |
| Round robin | Sırayla, dönüşümlü olarak dağıtır | Ekip üyeleri benzer yetkinlikte, talepler benzer ağırlıkta | Ağır ve hafif talepleri aynı kabul eder, gerçek yükü dengelemez |
| Yetenek bazlı | Talebin gerektirdiği yetkinliğe sahip kişilere yönlendirir | Uzmanlık farkı belirgin, yanlış atama pahalıya mal oluyorsa | Yetkinlik etiketleri güncel tutulmazsa yanlış yönlendirir |
Doğrudan atama, round robin ve yetenek bazlı atama farklı sürüm basamaklarında açılır; en gelişmişi olan yetenek bazlı atama en üsttedir. Yetenek bazlı yönlendirmeye ihtiyacınız olduğunu düşünüyorsanız bunu sürüm kararına dahil edin; alt sürümde bu ihtiyaç, çok sayıda doğrudan atama kuralıyla taklit edilmeye çalışılır ve yönetilemez hale gelir.
Sahada en sık işe yarayan yapı karmadır: kanal ve kategoriye göre doğrudan atama, geri kalanı için round robin, kritik hatlar için yetenek bazlı yönlendirme. Kural sayısını az tutmak, hangi kuralın çalıştığını izleyebilmek açısından önemlidir; on beş atama kuralı olan bir kurulumda bir talebin neden o kişiye düştüğünü kimse açıklayamaz.
Atama Kurulurken Atlanmayacak Dört Nokta
İzin ve müsaitlik durumu
İzindeki kişiye atanan talep, tam bir gün sessizce bekler.
Round robin ve doğrudan atama, kişinin müsait olup olmadığını kendiliğinden bilmez. Temsilcinin çevrimdışı veya izinli olduğu durumlarda dağıtım dışında kalmasını sağlayan bir düzenleme kurulmalıdır. Bu ayarlanmadıysa, izin takvimi ile atama kurallarının elle senkronize edilmesi gerekir ve bu unutulur.
Mesai dışında gelen talep
Gece 02.00'de atanan talep, sabah 09.00'da sahipli görünür ama kimse bakmamıştır.
Mesai dışı gelen talepler ya havuzda bekletilir ya da mesai başında atanır. İkincisi tercih edilirse, sabahın ilk yarım saatinde yapılan toplu atamanın kimseyi ezmediğinden emin olun.
Önceki temsilciye bağlılık
Aynı konuda daha önce konuşan kişi, ikinci kez en hızlı çözendir.
Bir müşteri yeniden yazdığında, mümkünse önceki temsilciye yönlendirmek çözüm süresini belirgin biçimde kısaltır. Bu kural, dönüşümlü dağıtımın önüne alınmalıdır.
Hiçbir kurala uymayan talep
Kural dışı kalan talep, kimsenin sorumlu olmadığı taleptir.
Her atama yapılandırmasının bir varsayılan çıkışı olmalıdır: hiçbir koşul eşleşmezse talep nereye düşer. Bu tanımlanmadığında ortaya sahipsiz kuyruk çıkar ve o kuyruğa kimse bakmaz.
SLA: Ölçmeden Söz Vermeyin
SLA, hizmet seviyesi taahhüdüdür. Sözleşmede yazan bir yükümlülüğünüz varsa bu taahhüt zaten bellidir ve sisteme birebir yansıtılır. Sözleşmesel bir yükümlülük yoksa, SLA'yı kurmadan önce mevcut performansınızı ölçmeniz gerekir.
Sahada gördüğümüz yaygın hata, ilk kurulumda iddialı hedefler yazmaktır: "yüksek öncelikli talepler 1 saatte yanıtlanır". Ekip bunu karşılayamaz, ihlal raporu ilk aydan kırmızıya döner, kimse rapora bakmaz ve SLA yapısı fiilen ölür.
Doğru sıra şudur: bir ay gerçek ilk yanıt sürenizi ölçün, dağılıma bakın ve taahhüdü mevcut performansınızın biraz üzerine, ulaşılabilir bir yere koyun. İyileşme, hedefi kademeli sıkıştırarak sağlanır.
SLA Neyi Ölçer: İki Ayrı Süre
SLA kurulumunda karıştırılan iki kavram vardır ve karıştırıldığında ekip yanlış davranmaya itilir.
İlk yanıt süresi
Talep açıldıktan sonra müşterinin ilk insan yanıtını alması. Otomatik onay e-postası bu süreyi durdurmaz. Müşteri memnuniyetini en çok etkileyen süre budur.
Çözüm süresi
Talebin fiilen çözülmesi. İşin karmaşıklığına bağlıdır ve her zaman ekibin kontrolünde değildir. Tek başına kullanıldığında yanıltıcıdır.
İkisi arasında öncelik sorulursa yanıt nettir: ilk yanıt süresi. Müşteri, sorununun ne kadar sürede çözüleceğini bilmemeye tahammül eder; kimsenin ilgilenmediğini düşünmeye etmez. Çözüm süresi hedefi ise talep tipine göre ayrışmalıdır; her tipe tek bir süre koymak, karmaşık işleri sistematik olarak ihlalde gösterir.
Süre hesabının çalışma saatlerine göre yapıldığını unutmayın. Cuma akşamı gelen bir talebin dört saatlik sayacı, mesai içi tanımlıysa pazartesi işlemeye devam eder. Takvim yanlışsa SLA de yanlıştır; bu yüzden çalışma saatleri ve tatil takvimi SLA'dan önce kurulur.
Eskalasyon: Haber Vermek, Suçlamak Değil
Eskalasyon, SLA'nın ihlal edildiği veya edileceği anda devreye giren bildirim zinciridir. SLA ve çok kademeli eskalasyon üst sürümlerin özelliğidir; hangi sürümde açıldığını fiyat sayfamızdan teyit edin. Asıl mesele kaç kademe kurulacağı değil, kademelerin kime ne söylediğidir.
İşe yaramayan eskalasyon şöyle kurulur: süre dolar, yöneticiye e-posta gider, yönetici gün içinde otuz böyle e-posta alır ve hepsini filtreler. Sonuç, hiç kurulmamışla aynıdır.
Birinci kademe: temsilciye, ihlalden önce
Sorunu çözebilecek tek kişi ona sahip olandır; onu ihlalden sonra uyarmak geç kalmaktır.
Süre dolmadan önce, örneğin taahhüdün yüzde yetmişinde uyarı gider. Bu, gecikmeyi engelleyen tek kademedir; diğerleri yalnızca raporlar.
İkinci kademe: takım sorumlusuna, ihlal anında
Devreye girmesi gereken kişi, kaynağı yeniden dağıtabilecek olandır.
Amaç suçlamak değil, işi devralacak veya destek verecek birini haberdar etmektir. Bildirim metni "gecikti" değil, "şu talep şu sebeple bekliyor" demelidir.
Üçüncü kademe: yönetime, yalnızca kritik hatlarda
Her ihlali yönetime taşımak, kademeyi anlamsızlaştırır.
Üçüncü kademe yalnızca sözleşmesel yükümlülüğü olan hatlar ve yüksek öncelikli talepler için kurulur. Ayda beşten fazla tetikleniyorsa, ya eşik yanlıştır ya da kapasite sorunu vardır.
Eskalasyon bildirimlerinin sayısını izleyin. Bildirim hacmi haftada birkaç kalemi aşıyorsa, bildirim değil kapasite sorununuz vardır. Eskalasyonu sıkılaştırmak bu durumda yalnızca gürültüyü artırır.
Beklemede Durumu ve Sayaç Yönetimi
SLA sayacının ne zaman duracağı, ölçümün dürüstlüğünü belirleyen ayardır. Müşteriden bilgi beklerken geçen süre ekibin gecikmesi değildir ve sayaç durmalıdır. Ancak bu mekanizma kolayca kötüye kullanılır.
- Sayaç yalnızca dış bağımlılıkta durur. Müşteri, tedarikçi veya üçüncü taraf bekleniyorsa durur. İç ekip bekleniyorsa durmaz; iç bekleme sizin sorununuzdur.
- Beklemeye alınan talep de yaşlanır. Beklemede kalan taleplerin ayrı bir yaş takibi olmalıdır; aksi halde SLA görünürde temiz kalırken müşteri haftalarca bekler.
- Bekleme sebebi yazılmalıdır. Sebep alanı olmayan bir beklemede durumu, "neden bekliyoruz" sorusunu yanıtlanamaz kılar.
- Müşteriye hatırlatma otomatikleşmelidir. Bilgi beklenen müşteriye belirli aralıklarla hatırlatma gitmiyorsa, bekleme süresiz uzar.
Sıralamayı Kurarken
Bu üç yapıyı kurma sırası, kurulumun ilk ayında şu şekilde olmalıdır.
Atama
Önce sahiplik. Sahipsiz talep varken hiçbir süre ölçümü anlamlı değildir.
Ölçüm
Bir ay gerçek süreler ölçülür. Taahhüt bu veriye göre yazılır.
SLA
Ulaşılabilir hedeflerle kurulur. İlk yanıt önceliklidir.
Eskalasyon
En sonda. Uyarı, ihlalden önce ve talebin sahibine gider.
Bu sıra bozulduğunda ortaya çıkan tablo hep aynıdır: kırmızı bir SLA panosu, kimsenin okumadığı eskalasyon e-postaları ve hâlâ sahipsiz bekleyen talepler. Omurga kurulduktan sonra sıradaki konu, bu talebin taşıdığı verinin nerede duracağıdır: Veri Modeli ve Özelleştirme.
