Çağrı merkezinde darboğazları aşmak: işe alım sorunu geride mi kaldı?

Darboğaz neden bir operasyon sorunudur

50 ila 100 kişilik bir müşteri destek ya da satış ekibinde darboğaz nadiren yalnızca bir işe alım sorunudur. İşe alım görünen belirti olabilir, ama kuyruğu yavaşlatan şey belirsiz bir politika, eksik bir sistem sorgusu, bozuk bir aktarım yolu ya da temsilcilerin gerçekten duyduğu soruya cevap vermeyen bir bilgi bankası maddesi de olabilir. Belirsiz bir sürece kişi eklemek, sebebi ortadan kaldırmadan karışıklığı daha fazla vardiyaya yayabilir.

İşin gerçekte nasıl yürüdüğüne bakarak başlayın. İyi bir teşhis ekibe kimin ulaştığını, ne istediğini, talebin nerede beklediğini ve sonra ne olduğunu anlatır. Böylece destek, satış, iş gücü planlama, telefon altyapısı ve sistem sorumluları aynı operasyon tablosuna bakar. Ekip, otomasyonun bu akışa girip girmemesi gerektiğine de adil biçimde karar verebilir. Amaç her etkileşimi otomatikleştirmek değildir. Amaç, önlenebilir beklemeyi ve tekrar işi ortadan kaldırırken muhakemeyi, izni ve sorumluluğu doğru kişide bırakmaktır.

Ortak bir başlangıç tablosu çıkarın

Yakın tarihli ve işi iyi temsil eden bir dönem seçin, her temas ya da görüşme için bir satır toplayın. Rapor döneminin tam uzunluğu, teşhis boyunca aynı tanımları kullanmak kadar önemli değildir. Şunları kaydedin:

• Temasın başlangıç ve bitiş saati, müşteri ya da lead kimliği, kuyruk, kanal ve dil.
• Söylenen talep, son sonuç kodu, aktarım sebebi, geri arama talebi ve talebin tamamlanıp tamamlanmadığı.
• Bekleme süresi, görüşme süresi, beklemeye alma süresi, çağrı sonrası iş, terk ve bir sonraki aksiyona kadar geçen süre.
• Temsilci ya da otomasyon yolu, kimlik doğrulama durumu, dokunulan sistemler ve her türlü hata ya da yedek yola düşme olayı.

Gelen temasları cevaplanan temaslardan, tamamlanan bir etkileşimi de yalnızca otomasyonda kalmış bir temastan ayırın. Müşteri otomatik bir cevaptan sonra telefonu kapatıyorsa bu, sorunun çözüldüğünün kanıtı değildir. Temsilci bir ticket'ı kapatırken aynı konu için başka bir temas açık kalıyorsa, o kapanış temiz bir sonucun kanıtı değildir. Bu ayrımlarda ilk dashboard'dan ya da ilk kadro toplantısından önce anlaşın. Ardından DRING analizlerindeki bir huni, tüm yolculuğu tek bir ortalamaya sıkıştırmak yerine işin nereden girdiğini, nerede beklediğini, nereye aktarıldığını ve nereden çıktığını gösterebilir.

Talebe, kuyruğa, saate ve kanala göre teşhis edin

Genel ortalamalar darboğazın şeklini gizler. Dört görünüm çıkarın, sonra bunları çaprazlayın. Aynı kuyruk bir talep türü için sağlıklı, diğeri için aşırı yüklü olabilir. Aynı kanal mesai saatlerinde çalışıp son uzman çıktıktan sonra tıkanabilir.

Talebe göre

Temasları yalnızca kapanışta seçilen etikete göre değil, müşterinin halletmek istediği işe göre gruplayın: sipariş durumu, iptal, fatura açıklaması, ürün uygunluğu, randevu alma ya da teknik arıza gibi. Uzun beklemeye alma, sık aktarım, yüksek tekrar arama ya da yüksek oranda elle araştırma gerektiren talepleri arayın. Müşterilerin kullandığı kelimeleri görmek için transkriptlerden ya da kayıtlardan örnek okuyun, çünkü "diğer" gibi geniş bir etiket birkaç farklı iş akışını saklayabilir. Satışta bilgi taleplerini niteleme, randevu planlama ve demo sonrası takipten ayırın. Her birinin sahibi ve sonraki adımı farklıdır.

Kuyruğa göre

Giriş kuyruğundan uzmana, süpervizöre, arka ofise ya da satış sorumlusuna uzanan tüm yolu çıkarın. Gelen hacmi mevcut kapasiteyle karşılaştırın, ama işin çağrıdan sonra nerede beklediğine de bakın. Bir destek kuyruğu çağrıları eritirken fatura ya da onay kuyruğunda çözülmemiş görevler birikebilir. Temas başına aktarım sayısını hesaplayın ve işi bitirmek için gereken yetkisi ya da verisi olmadan iş alan kuyrukları belirleyin. Kısa bir ilk kuyruk, her istisnayı başka yere aktarıyorsa müşteri için yine uzun bir yolculuk yaratır.

Saate göre

Hacmi, gelişleri, beklemeyi, terki, kadroyu, doluluk oranını ve devirleri gün boyunca grafiğe dökün. Günlük ortalama, ekibi yeterli kadrolu gösterirken kötü deneyimin çoğu öngörülebilir bir sabah yığılmasından, öğle boşluğundan ya da kapanış öncesi dalgadan gelebilir. Haftanın günlerine göre örüntüleri, kampanya ya da lansman dönemlerini, yerel tatilleri ve müşterinin saat dilimini de ekleyin. Mesai dışı temaslarda müşterinin sonra ne yaptığını kaydedin: sesli mesaj mı bıraktı, geri arama mı istedi, self servis mi kullandı, vazgeçti mi, yoksa mesai saatinde mi tekrar aradı? Mesai dışı yolun talebi karşılayıp karşılamadığını ya da yalnızca ertelediğini bu davranış belirler.

Kanala göre

Sesli görüşmeyi, web sohbetini, e-postayı, mesajlaşmayı ve varsa giden satış yolunu karşılaştırılabilir sonuçlarla kıyaslayın. Sesli kanal yönlendirme ve ses sorunlarını, sohbet eş zamanlı yük ya da yavaş devir sorunlarını, e-posta ise sahipsiz birikmiş işi ortaya çıkarabilir. Bir kuyruğu yalnızca yanıt süresi daha kısa göründüğü için sohbete taşımayın. Kanalın kimlik doğrulamayı, ek dosyayı, izni, geri aramayı ve talebin gerektirdiği çözümü destekleyip desteklemediğine bakın. Kanal değişikliği ancak yolculuğun tamamını iyileştiriyorsa işe yarar.

Otomatikleştirmeden önce sorunun türünü belirleyin

Kırılımlar bir soruna işaret ettiğinde kısıtın türünü belirleyin. Birden fazla sorun aynı anda olabilir, ama birincil olanı adlandırmak ilk müdahaleyi küçük ve test edilebilir tutar.

Kadro sorunu

Talep türü, kuyruk ve saat hesaba katıldıktan sonra da gelen hacim ve iş yükü planlanan kapasiteyi aşıyorsa kısıt büyük ihtimalle kadrodur. Vardiya planına uyumu, yetkinlik kapsamını, kayıp zamanı (shrinkage), doluluk oranını ve birikmiş işin yaşını kontrol edin. Ekipte toplamda yeterli kişi olup gereken dil ya da yetkiye sahip yeterli kişi yoksa sorun kişi sayısı değil, yetkinlik dağılımıdır. Çözüm bir vardiya değişikliği, çapraz eğitim, uzman rotasyonu ya da bilerek sınırlandırılmış bir taşma yolu olabilir. Yeni bir işe alım turu otomatik olarak çözüm değildir.

Politika sorunu

Temsilciler müşterinin neye ihtiyacı olduğunu bilip bir istisna, onay ya da süpervizör olmadan harekete geçemiyorsa kısıt politikadır. İade, alacak, uygunluk, iptal, kimlik kontrolü ya da satış tavizleri hakkında tekrar eden sorulara bakın. Yetki sınırını gözden geçirin ve bir karar tablosu yazın: neyin tamamlanabileceği, hangi kanıtın gerektiği, istisnayı kimin onaylayacağı ve müşterinin ne beklemesi gerektiği. Net bir politika çoğu zaman kontrolü azaltmadan aktarımları ortadan kaldırır.

Entegrasyon sorunu

Doğru aksiyon bilindiği halde temsilci gereken veriyi güvenilir biçimde çekemiyor ya da yazamıyorsa kısıt entegrasyondur. Belirtileri: verinin elle yeniden girilmesi, güncel olmayan hesap durumu, mükerrer kayıtlar, zaman aşımları ve sistemler arasında kopyalanan notlar. Veri çekmeyi ve geri yazmayı ayrı ayrı izleyin. Bir sistem yavaşladığında ya da erişilemediğinde ne olacağını tanımlayın ve yedek yolu bir sonraki sorumlunun görebileceği hale getirin. Kimlikleri, zaman damgalarını ve sonuç kodlarını CRM, telefon altyapısı ve iş akışı araçları arasında tutarlı tutun. Agent'ı, araçları ve sonucu tek bir operasyon akışı olarak düşünmek için DRING platformu sayfası iyi bir kaynaktır.

Telefon altyapısı sorunu

Müşteriler planlanan yola giremiyor ya da o yolda kalamıyorsa kısıt telefon altyapısıdır. IVR metinlerini, menü derinliğini, arayan tanımayı, kuyruk anonslarını, çağrı kaydını, aktarım davranışını, tek yönlü sesi, düşen çağrıları ve geri arama yönlendirmesini kontrol edin. Yanlış yönlendirilmiş bir çağrı raporda temsilci performansı zayıfmış gibi görünebilir. Yolu dışarıdan bir numarayla baştan sona deneyin ve aktarımları sorunun bildirildiği saatlerde test edin. Her numaranın yolunu, yedek hedefini ve sahibini telefon altyapısı kontrolleriyle kayda geçirin.

Bilgi sorunu

Temsilciler ya da otomatik asistanlar doğru kuyruğa ulaşıp tutarsız cevaplar veriyorsa kısıt bilgidir. Aynı talebi farklı değerlendiricilerle karşılaştırın; eksik tanımları, çelişen maddeleri, eskimiş ekran görüntülerini ya da belirsiz eskalasyon kurallarını bulun. Her maddeye bir sahip, bir gözden geçirme tarihi, bir doğruluk kaynağı ve ne zaman kullanılmaması gerektiğini gösteren bir işaret verin. Cevap müşteriye özel veriye bağlıysa bilgi tek başına yetmez. Maddeyi güvenilir bir sorgu ve net bir devirle eşleştirin.

Sınırı belli bir ilk iş akışı seçin

Tekrarlanabilir, düşük riskli ve doğrulaması kolay tek bir iş akışı seçin. İyi bir ilk aday dar bir talep türüne, bilinen bir doğruluk kaynağına, sınırlı sayıda sonuca ve istisnalar için net bir insan sorumluya sahiptir. Arkadaki veri ve yetki kuralları güvenilirse sipariş ya da randevu durumu, temel niteleme, geri arama talebi alma ve rutin hesap soruları uygun olabilir. "Desteği halletsin" gibi geniş bir talimat bir iş akışı değildir. Riskleri farklı iş akışlarının bir toplamıdır.

Sınırı uygulamaya geçmeden önce yazın: giriş koşulu, toplanacak bilgi, izin verilen aksiyonlar, en fazla deneme sayısı, durma koşulları, son sonuç kodları ve insana devrin nereye gideceği. Hassas, mevzuata tabi, yüksek tutarlı ya da duygusal olarak gerilmiş vakalar için istisnaları ekleyin. Başarılı sonucu agent'ın söyleyeceği cümlelerle değil, CRM'de ne göründüğüyle tanımlayın. Müşteri destek agent'ı modeli, insan ekibin istisna yönetimini devralmadan onun çevresinde çalışabilecek türden sınırlı bir rutini gösterir.

Taşmayı, mesai dışını ve devri tasarlayın

Taşma tek bir düğme değil, bir kapsama politikasıdır. Onu hangi sinyalin açacağına karar verin: kuyruk derinliği, bekleme eşiği, bulunmayan bir yetkinlik, bir sistem arızası ya da mesai saati sınırı. Hedefi ve taşma yolunun en fazla ne kadar iş alabileceğini belirleyin. Ana ekip doluysa taşma yolu tamamlayamayacağı bir aksiyonun sözünü vermemelidir. Yapılandırılmış bilgi toplayabilir, onaylı bilgiyi verebilir, geri arama planlayabilir ya da acil vakaları yönlendirebilir, ama her seçeneğin bir sahibi ve zaman damgası olmalıdır.

Mesai dışı tasarım bir sonraki aksiyonla başlar. Bilgi isteyen müşteri onaylı self servis bilgisini ve devam etme yolunu alabilir. Hesabına özel işlem gereken müşteri için kimlik ve iletişim tercihleriyle birlikte bir geri arama talebi gerekebilir. Bir satış lead'i için niteleme kaydı ve üzerinde anlaşılmış bir takip aralığı gerekebilir. Yerel saat dilimini ve hizmet sözünü kaydedin ki sabah kuyruğu müşteriyi başa döndürmeden işleri önceliklendirebilsin. Sınırı açılış ve kapanış cümlelerinde açıkça söyleyin, iş akışı güvenle devam edemiyorsa bir insana ulaşma yolu sunun.

İşe yarar bir devir paketi şunları içerir: müşterinin söylediği talep, doğrulanmış kimlik ya da eksik doğrulama, ilgili cevaplar, transkript ya da kısa özet, bakılan sistemler, çözülmemiş soru, aciliyet, tercih edilen geri arama kanalı ve sonraki sorumlu. O anda müsait bir uzman varsa sıcak devri tercih edin. Yoksa izlenebilir bir görev açın ve müşteriye sırada ne olacağını söyleyin. Aktarım başarısız olursa toplanan veriyi koruyun ve teması aynı bozuk yoldan tekrar geçirmek yerine tanımlanmış yedek yolu kullanın.

Sonuçları CRM'e bağlayın

Bir görüşme, sonucu bir sonraki sistem ve kişi için okunabilir olduğunda operasyonel olarak işe yarar. Az sayıda sabit sonuç kodu kullanın: çözüldü, takip gerekiyor, aktarıldı, doğrulanamadı, terk edildi, yanlış yönlendirme ve sistem hatası gibi. Talebi sonuç kodundan ayrı saklayın, çünkü aynı talep çözülebilir, devredilebilir ya da takılabilir. İlgili olduğu yerde sorumluyu, son zamanı, müşteri ya da lead kimliğini, izin durumunu ve kaynak kanalı ekleyin.

Destekte CRM neyin cevaplandığını, neyin açık kaldığını ve müşterinin ekibe tekrar ulaşması gerekip gerekmediğini göstermelidir. Satışta nitelenmiş bir lead'i, planlanmış bir toplantıyı, elenen bir lead'i, daha fazla bilgi talebini ve ulaşılamayan bir kişiyi birbirinden ayırmalıdır. Serbest metin notları tek kayıt olarak bırakmayın. Özet bir kişinin hızlı çalışmasına yardım eder, ama raporlamayı, yönlendirmeyi ve denetimi mümkün kılan yapılandırılmış alanlardır. Mükerrer kişi kayıtlarını birleştirin ve geri yazma başarısız olursa ne olacağını tanımlayın. Entegrasyon onaylamadıysa kayıt asla başarı ima etmemelidir.

Pilotu geri dönüş yoluyla birlikte kurun

İlk iş akışını adı belli bir sorumluyla, sabit bir kapsamla ve yayından önce ölçülmüş bir başlangıç tablosuyla çalıştırın. İç ya da kontrollü trafikle başlayın, sonra seçilen kuyruğun sınırlı bir bölümünü belirli saatlerde açın. Mevcut yolu açık tutun. Süpervizörlerden ilk sonuçları doğru talep, yetki, sonuç kodu, devir bütünlüğü ve müşteriyle konuşma tonu açısından incelemelerini isteyin. Yedek yola düşülen her durumun sebebini kaydedin, çünkü her biri sınır ya da arkadaki süreç hakkında bir kanıttır.

Mümkünse her seferinde anlamlı tek bir değişkeni değiştirin: yönlendirme, bilgi, politika, prompt, entegrasyon eşlemesi ya da kapsama saatleri. Pilotu önceki başlangıç tablosuyla aynı talep, kuyruk, saat ve kanal kırılımlarını kullanarak karşılaştırın. Geri dönüş tetikleyicilerini önceden belirleyin: ciddi bir SLA ihlali, tekrar aramada artış, bir kalite hatası, yanlış CRM durumu, güvensiz yetki davranışı ya da bir telefon altyapısı arızası gibi. Yolu kimin kapatabileceğini, çağrıların sonra nereye gideceğini, açık görevlerin nasıl kurtarılacağını ve ekibin etkilenen müşterilere nasıl haber vereceğini yazın. Geri dönüş, eski yolun hâlâ çalıştığı umudu değil, test edilmiş bir operasyon adımı olmalıdır.

Önemli olan metrikleri tanımlayın

Çözüm

Çözümü, müşterinin halletmek istediği işin tamamlanması ya da sonraki sorumlunun net tanımlanmış bir aksiyonu üstlenmesi olarak tanımlayın. İlk temasta çözümü otomasyonda kalma oranından ayrı izleyin. Bir temas çözülmeden otomasyonda kalabilir, bir aktarım da devralan kişi işi tamamladığında yine iyi bir deneyim olabilir. Oranı talebe, kuyruğa, saate ve kanala göre, hariç tutulanları da yazarak raporlayın.

Tekrar arama

İş akışına uyan bir tekrar arama penceresi seçin ve temasları müşteri, vaka ya da lead kimliğiyle birbirine bağlayın. Tekrarın sebebini sayın: eksik cevap, başarısız devir, çözülmemiş sistem sorunu, yeni bir soru ya da müşterinin tercihi. Tekrar arama ancak kimlik ve talep eşleştirmesi güvenilirse işe yarar bir kalite sinyalidir. Hem oranı hem arkasındaki temaları inceleyin.

Kalite

Bilgi doğruluğunu, zorunlu bilgilendirmeleri, kimlik doğrulamayı, politikaya uyumu, tonu, dinlemeyi, doğru sonuç kodunu ve devir bütünlüğünü kontrol eden bir değerlendirme ölçeği kullanın. Karşılaştırmanın adil olduğu yerlerde otomatik ve insan yollarını aynı sonuç kurallarıyla puanlayın. Kritik hataları üslup tercihlerinden ayrı tutun ki hoş geçen bir çağrı güvensiz ya da yanlış bir aksiyonu gizlemesin.

SLA ve kapasite

SLA'yı kanala ve verilen söze göre tanımlayın: cevaplama ya da ilk yanıt, çözüm, geri arama ya da takibin tamamlanması. Ortalamaların yanında yüzdelik dilim bekleme sürelerini ve birikmiş işin yaşını da izleyin, çünkü az sayıda uzun bekleme ortalamanın içinde kaybolabilir. Hizmet ölçülerini vardiya planına uyum, doluluk oranı, fazla mesai ve uzman müsaitliği gibi kadro sinyalleriyle birlikte okuyun. Satış için kabul edilen devri, ulaşılabilirliği ve sonraki adımın tamamlanmasını ekleyin. Metrikler bir ödünleşimi göstermeli, işi gözden uzaklaştıran ekibi ödüllendirmemelidir.

Kontrollü iyileştirme için Agent Factory'de incelenen çağrıları kullanın

Agent Factory'de incelenen çağrıları bir anekdot kaynağı olarak değil, kontrollü bir iyileştirme seti olarak kullanın. Agent Factory, DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği süreçtir. İncelenen her çağrıyı talebe, kuyruğa, saate, kanala, sonuca ve hata türüne göre etiketleyin. Başarılı çözüm, doğru devir, toparlanabilen karışıklık ve kritik hata örneklerini saklayın. Bu karışım ekibin yalnızca her şeyin yolunda gittiği senaryoyu değil, sınırı da test etmesini sağlar.

Bir örüntü ortaya çıktığında küçük bir değişiklik hipotezi yazın. Örneğin bir yönlendirme kuralı tek bir talep türünde aktarımları azaltmalı ya da bir bilgi güncellemesi görüşmeyi uzatmadan cevap doğruluğunu artırmalıdır. Değişikliği incelenen sete ve yeni bir örnekleme uygulayın, sonra çözümü, tekrar aramayı, kaliteyi, SLA'yı ve CRM'e geri yazmayı birlikte kontrol edin. Değişikliği ancak hedeflenen ölçü kritik bir gerileme olmadan iyileşiyorsa yayına alın. Önceki sürümü, karar kaydını ve geri dönüş talimatını saklayın. Düzenli inceleme, çağrıları operasyon, kalite ve yazılım ekiplerinin ortak kullanabileceği izlenebilir bir öğrenme döngüsüne çevirir.

Teşhis kontrol listesi

• Çözümü, tekrar aramayı, kaliteyi ve SLA'yı tüm ekibin kullandığı terimlerle tanımladık mı?
• Talebi, kuyruğu, saati ve kanalı tek bir karma ortalamaya dayanmadan raporlayabiliyor muyuz?
• Temas nerede bekliyor: cevaplanmadan önce mi, aktarımda mı, arka ofis görevinde mi, yoksa başarısız bir geri yazmadan sonra mı?
• Birincil kısıt kadro mu, yetkinlik kapsamı mı, politika mı, entegrasyon mu, telefon altyapısı mı, bilgi mi?
• Önerilen ilk iş akışının tek bir sahibi, sınırlı aksiyonları ve açık istisnaları var mı?
• Taşmada, mesai dışında, sistem arızasında ve başarısız bir insana aktarımda ne oluyor?
• Devir doğrulanmış kimliği, müşterinin talebini, bağlamı, sonraki adımı ve son zamanı taşıyor mu?
• CRM, sonraki sorumlunun üzerinde çalışabileceği sabit bir sonuç kaydediyor mu?
• Pilot trafiğin hangi kısmı sınırlı, kim inceliyor, geri dönüşü kim yapabilir?
• İncelenen çağrılar etiketlendi ve bir sonraki değişiklik için regresyon seti olarak saklandı mı?

İyi bir operasyon neye benzer

Sağlıklı bir operasyon her zor teması otomasyonun arkasına saklamaz. Rutin işi öngörülebilir kılar, uzmanlara istisnaları bitirecek bağlamı ve yetkiyi verir, hataları düzeltmeye vakit kalacak kadar erken görünür yapar. 50 ila 100 kişilik bir ekip için bu netlik, çoğu zaman kapsamlı bir dönüşümden daha değerlidir: talebin şeklini teşhis edin, sınırı belli tek bir iş akışı seçin, devri koruyun, sonucu CRM'e bağlayın ve incelenen çağrılarla geliştirin. İşe alım ve kadro hâlâ önemlidir, ama ekibin gözlemleyebildiği ve bilerek değiştirebildiği bir sistemin girdilerinden birine dönüşür.