giriiş
Yirmi yıl boyunca iletişim merkezi sektörü bir süreç üzerinde anlaştı: Bir süpervizör kayıtlı çağrıların küçük bir yüzdesini (genelde temsilci başına haftada 2 ila 5) rastgele örnekleyecek ve bunları 30 satırlık bir değerlendirme tablosuna göre puanlayacak ve puanları bir koçluk raporuna aktaracaktı. Bütün endüstri bu uygulama etrafında inşa edildi. Satıcılar puan kartları sattı. Denetçiler değerlendirme listelerini doğruladı. Konferansların bunun için izleri vardı.
Matematik hiç işe yaramadı. Haftada 200.000 çağrıyı yöneten 1.000 temsilcilik bir iletişim merkezi, temsilci başına %2 örnekleme yaparak size 40.000 puanlı çağrı verir; örneğin %99'u zararsız olan çağrılar arasında eşit şekilde rastgele olduğunu fark edene kadar bu çok gibi görünebilir.
Temsilcinin uyumluluk ihlalleri yaptığı 60 çağrıyı bulmak için 40.000 rastgele konuşmayı örneklemek samanlıktaki iğnenin tanımıdır. Saman yığını ayıklandığında temsilci yoluna devam etmiş, müşteri dağılmış ve ihlal daha da ağırlaşmıştır.
QA'nın amacı asla ortalama çağrıyı puanlamak değildi. Önemli olan çağrıları bulmaktı: başarısızlıklar, kurtarmalar, son durumlar, temsilcinin olağanüstü veya endişe verici bir şey yaptığı konuşmalar. Rastgele örnekleme, bunlardan herhangi birini bulma konusunda yapısal olarak kötüdür.
Son 18 ayda neler değişti
Eski modeli açıkça bozacak kadar iki şey değişti. Birincisi, transkripsiyon kalitesi bir kullanışlılık eşiğini aştı; çoğu ana dilde, transkripsiyonlar artık yalnızca insan kulağıyla değil, yazılımla da puanlanacak kadar güvenilir.
İkincisi, büyük dil modelleri, denetimli sınıflandırmada, özel olarak eğitilmiş bir modelin, bir kuruştan daha az bir maliyetle 4 saniyede 30 boyutta çağrı puanlayabilmesini sağlayacak kadar iyi hale geldi.
Bunların hepsi birlikte, iletişim merkezi tarihinde ilk kez, her bir çağrının değerlendirme listesine göre puanlanabileceği anlamına geliyordu; %2 değil, %5 değil, %100. Her çağrı puanlandıktan sonra "hangi çağrıları örnekleyeceğiz?" sorusu ortadan kalkar. ve "hangi aramalar bir insan süpervizörün ilgisini hak ediyor?"
Çözülmeye değer soru budur ve bu bir örnekleme problemi değil, bir sıralama problemidir.
Risk puanına neler dahildir?
Her çağrıyı üç bağımsız boyutta puanlıyoruz ve ardından bunları yöneticinin konsolunda gördüğü tek bir sıralamada birleştiriyoruz.
- Uyumluluk riski — Çağrı, mevzuata maruz kalmayı tetikleyen bir dil içeriyor mu? Mini Miranda, TCPA onayı, borç tahsilatı FDCPA sınırları, korumalı sağlık açıklamaları. Bu boyut ikili bir yapıya sahiptir; çağrıların çoğu sıfıra yakın puan alır, küçük kuyruk ise yüksek puan alır.
- Sonuç riski — Bu müşterinin bu çağrı sonucunda vazgeçmesi, şikayette bulunması veya durumu üst seviyeye taşıması muhtemel mi? Duygu gidişatını, çözülmemiş sorun sinyallerini, açık şikayet dilini ve müşterinin hesap katmanı değerini birleştirir.
- Koçluk değeri — Bu çağrıyı izleyen bir süpervizör öğretebileceği bir şey öğrenebilir mi? Üst düzey koçluk çağrıları, olağandışı kurtarmalar, temiz geçişler ve kontrollü gerilim azaltmalardır. Bunlar başarısızlık değil; onlar örnektir.
Üç boyut eşit ağırlıkta değildir ve ağırlıklar müşteriler arasında aynı değildir. Bir borç tahsilat operatörü, uyum riskini en ağır şekilde değerlendiriyor. Yüksek düzeyde temas halinde olan bir kurumsal SaaS destek ekibi, sonuç riskine ağırlık verir. Eğitim ağırlıklı bir işe alım ekibi, koçluk değerine ağırlık verir. Ağırlıklar yönetici ayarlarında gösterilir ve sektöre göre makul varsayılanlar belirleriz.
Denetleyici konsolu: sıralanmış bir kuyruk
Konsol, eski "rastgele örnek kuyruğu" kullanıcı arayüzünden kasıtlı olarak farklı görünüyor. Son çağrıların sayfalandırılmış bir listesi yerine, birleşik risk puanına göre sıralanan ve her iki dakikada bir yenilenen tek sıralı bir sıradır. Sıranın en üstünde, bugün ilgilenilmesi gereken 20 kadar çağrı yer alıyor. Aşağıdaki her şey uzun bir kuyruktur.
Her çağrı kartı üç alt puanı, çağrının neyle ilgili olduğuna dair 90 saniyelik bir özeti ve modelin işaretlediği belirli parçacıkları taşır. Bir süpervizör çağrının tamamını dinlemeden parçayı dinleyebilir. Parçacık hikayenin tamamını oluşturuyorsa (ki çoğu zaman öyledir), süpervizör 30 saniye içinde bayrağı onaylar veya reddeder ve yoluna devam eder.
Rastgele örnek QA, çağrı başına ortalama 8 dakika sürüyordu. Sıralanmış sıra ortalama 2 dakika 40 saniye sürer. Arama başına QA maliyeti düştü. Kapsama yüzde 2'den yüzde 100'e çıktı. Süpervizör zamanını ölçümü gerçekten değiştiren çağrılara harcıyor.
Duyduğumuz itirazlar
Sıralanmış kuyruğu tasarım ortağı müşterilerindeki QA liderlerine gösterdiğimizde sürekli olarak üç itirazla karşılaştık.
İtiraz 1: "Model, bir insanın yakalayabileceği şeyleri kaçıracaktır."
Soyut olarak doğru; pratikte çoğunlukla yanlıştır. Model, insana özgü şeyleri özlüyor uzman yakalayabilir — aynı çağrıyı inceleyen bir uyumluluk denetçisi, modelin işaretlemediği incelikleri bulabilir. Ancak karşılaştırma bir uzmana karşı değildir. Bu, çağrıların %2'sini rastgele örnekleyen bir süpervizöre karşıdır. Model %100'ü inceliyor ve bariz %5'i işaretliyor. Uzman %5'i inceler.
Net kapsama alanı eski sisteme göre çok daha iyi.
İtiraz 2: "Ajanlar skoru oynayacak."
Muhtemelen doğrudur. Dikkat çeken herhangi bir ölçüm oynanır. Savunma iki yönlüdür: Skor çok boyutludur, dolayısıyla bir eksende oynamak sizi diğer eksene doğru iter; ve puan, temsilcinin performans incelemesi değildir. Skor, süpervizör için bir triyaj sinyalidir. Performans incelemesi, süpervizörün asıl çağrıyı dinledikten sonra vardığı sonuçtur.
Skoru skorbord olarak değil sıra olarak satıyoruz.
İtiraz 3: "Amirin işini değiştirir."
Aynı zamanda doğru ve bu konuda dürüst olmalıyız. Sıralı kuyruklu bir iletişim merkezinin süpervizörü, 30 satırlık bir değerlendirme tablosuna göre çağrıları puanlamaya daha az, yönlendirmeye, üst kademeye yükseltmeye ve müdahale etmeye daha fazla zaman harcıyor. Eski işi -bunun metodik, puan kartına dayalı kısmını- beğenen amirler yeni işten pek de heyecan duymuyorlar.
Lansmandan önce bu konuyu tasarım ortağı operasyon liderleriyle açıkça konuştuk. Bu yalnızca bir takım değişikliği değil, bir iş akışı değişikliğidir.
Yeni sistemin ilk 90 günde buldukları
Sıralama kuyruğunu yalnızca 90 gün boyunca yürüten dört tasarım ortağı arasında, süpervizör ekipleri, rastgele örneklemeye göre haftada 4,7 kat daha fazla elde tutma veya uyumluluk çağrısını artırdı. Artış "daha fazla inceleme" etkisi değildi; neredeyse tamamen rastgele örneklemenin yapısal olarak gözden kaçırdığı çağrılardı.
Bir müşteri, borç tahsilatı senaryosunda bir sapma yakaladı - tek bir temsilci, aramalarının yaklaşık %9'unda FDCPA sınırını aşan bir dil kullanmaya başlamıştı - rastgele örnekleme 11 hafta boyunca ortaya çıkmamıştı. Sıralanmış kuyruk, sürüklenmenin başlamasından sonraki 48 saat içinde ortaya çıktı, çünkü bu belirli çağrılardaki uyumluluk-risk puanı, temsilcinin referans çizgisinin iki standart sapma üzerine sıçradı.
Başka bir müşteri, rastgele örnekleme sisteminin en düşük performans gösterenler olarak işaretlediği temsilcilerin aslında en düşük performans gösterenler olmadığını, yalnızca en gürültülü olanlar olduğunu keşfetti. Sonuç riskine göre derecelendirilen sıralı kuyruk, çağrıları herkesle aynı oranda örneklenen ve "ortalama" yığına giren iki sessiz ancak sürekli olarak düşük performans gösteren temsilciyi belirledi.
Skorla kasten yapmayacağımız şey
Üç şey bilerek.
Aracıları kuyruğun çıktısına göre otomatik olarak puanlamayacağız. Skor bir triyaj sinyalidir. Temsilci performans derecelendirmeleri hâlâ bir denetçiden geçiyor. Model bunu yapamadığı için değil, kalıptan tamamen kaçınmak isteyecek kadar otomatik puanlamalı sistemin güveni aşındırdığını izlediğimiz için insanı bilinçli olarak döngünün içinde tutuyoruz.
Görüşme sırasında temsilcinin gerçek zamanlı puanını temsilciye göstermeyeceğiz. Temsilcilerin kendi koçluk puanlarını gerçek zamanlı olarak görmesi gerektiğini söyleyen bir düşünce ekolü var. Böyle yapmanın çağrıyı olumsuz etkilediğini söyleyen daha güçlü bir düşünce ekolü var. Biz ikinci okulun yanındayız.
Puanı varsayılan olarak performans yönetimi sistemlerine aktarmayacağız. Puanı ayrı bir İK aracına bağlamak isteyen müşteriler bunu açık yapılandırmayla yapabilirler ancak biz varsayılanı daha güvenli bir seçim haline getiriyoruz. Bir e-tabloda bir sayı istiyorsanız, bunu bilerek istemeniz gerekir.