Sesli yapay zekada otomasyonda kalma ve çözüm oranı: neyi ölçmelisiniz?

Bir operasyon ya da müşteri deneyimi yöneticisi için sesli yapay zeka raporları üç kararı kolaylaştırmalı: neyi otomatikleştireceğinizi, neyi yönlendireceğinizi ve sırada neyi düzelteceğinizi. Bunun için tek bir otomasyon yüzdesi yetmez. Bir çağrı aktarılmadan bitip yine de yarım iş bırakabilir. Doğru kişi doğru bağlamla devraldığında ise aktarılan bir çağrı da iyi bir müşteri deneyimi olabilir.

Dört ayrı soruyla başlayın

Otomasyonda kalma bir çıkış durumudur

Otomasyonda kalma (containment) genellikle çağrının canlı bir temsilciye aktarılmadan otomatik akışın içinde bittiği anlamına gelir. Görüşmenin nerede bittiğini anlatır, arayanın ihtiyacını karşılayıp karşılamadığını değil. Arayan kafa karıştıran bir cevaptan sonra kapatmış, yavaş bir kimlik doğrulama adımında vazgeçmiş ya da kimsenin sahiplenmediği bir geri arama sözünü kabul etmiş olabilir. Sonuç modeli sonrasında ne olduğunu kaydetmiyorsa, bunların her biri otomasyonda kalmış gibi görünür.

Çözüm tamamlanmış bir sonuçtur

Çözüm, arama nedeninin tamamlanıp tamamlanmadığını ve arayanın bunu kabul edip etmediğini sorar. Sipariş durumu çağrısında bu, güncel durumun alınması, doğru aktarılması ve anlaşılması demek olabilir. İptal talebinde ise politikanın anlatılması yetmez, sistemde teyit edilmiş bir güncelleme gerekebilir. Kanıtı canlıya çıkmadan önce tanımlayın. İş akışına göre doğrulanmış bir kayıt güncellemesi, arayanın açık teyidi ya da sorumlusu belli, sonraki sistemde tamamlanmış bir aksiyon çözüm sayılabilir. Nazik bir kapanış, uzun bir görüşme ya da kendinden emin bir ton tek başına çözümü kanıtlamaz.

Aktarım kalitesi ve tekrar temas aradaki boşluğu gösterir

Aktarım oranı, bir çağrının ne sıklıkla bir insana geçtiğini söyler. Aktarım kalitesi ise bu geçişin işe yarayıp yaramadığını: arayan doğru kuyruğa ulaştı mı, aktarım başarılı oldu mu, ilgili bilgiler karşı tarafa geçti mi, devralan kişi görüşmeye baştan başlamak zorunda kaldı mı? Bağlamsız bir aktarım teknik olarak tamamlanmıştır ama operasyona pahalıya patlar. Aktarımdan sonra ne olduğunu da ölçün: devralan kuyruğun kabulü, ilk insan aksiyonuna kadar geçen süre, düzeltme işi ve söz verilen sonraki adımın tamamlanıp tamamlanmadığı.

Tekrar temas, aynı müşterinin, hanenin, vakanın ya da işlemin tanımlı bir süre içinde aynı nedenle geri dönüp dönmediğini ölçer. Mümkünse vaka bazlı bir payda kullanın ve iş akışına uyan bir süre seçin. Bir teslimat sorunu kısa sürede tekrar edebilir; bir fatura itirazı için daha uzun bir süre gerekebilir. Tekrar temas ilk çağrının başarısız olduğunun kanıtı değildir. Ama ilk görüşmenin transkripti, sistemdeki sonuç ve sonraki temasın nedeniyle birlikte okunduğunda güçlü bir inceleme sinyalidir.

Paneli kurmadan önce metrik sözlüğünü yazın

Tanımları operasyon, destek, kalite ve entegrasyonun sahibi olan kişi ya da ekibin birlikte onaylayabileceği ortak bir dokümana koyun. Bir oran ancak kapsadığı çağrılar, payı, paydası, kanıtı ve hariç tutulanlar görünür olduğunda anlam taşır. Aşağıdaki tabloyu başlangıç noktası olarak kullanın, kanıt kuralını kendi iş akışınıza göre uyarlayın.

Önemli metriklerin en az iki görünümünü tutun: tanımlı uygun çağrılar için bir başlık oranı ve cevaplanan çağrılar ya da geçerli işlem talepleri gibi daha dar bir aşama için bir teşhis oranı. Paydayı söylemeden bu oranları asla karşılaştırmayın. DRING'in analitik görünümü burada işe yarayabilir: sonuç, güven düzeyi, neden ve sonraki aksiyon tek bir puana indirgenmeden birlikte incelenebilir.

Yanıltıcı otomasyonda kalmayı sonuç zincirinde yakalayın

Yanıltıcı otomasyonda kalma, otomatik ve tamamlanmış görünen ama müşteri ya da iş açısından tatmin edici bir sonuç üretmeyen çağrıdır. Sık görülen örnekler şunlar: arayan kafa karıştıran bir açıklamanın ortasında kapatır, cevap doğrudur ama asıl arama nedenine değmez, entegrasyon eski bir kayıt döndürür, istenen değişiklik söylenir ama sisteme yazılmaz ya da geri arama sözü adı belli bir sorumlu ve saat olmadan verilir. Soru sormayı bırakan bir arayan, yardım almış bir arayan demek değildir.

Bunu yakalamak için görüşmeyi tek bir bitiş olayı olarak değil, bir zincir olarak modelleyin. Zincirin halkaları şunlardır: arama nedeni belirlendi, kimlik ya da uygunluk kontrol edildi, bilgi alındı, karar verildi ya da aksiyon alındı, sonuç teyit edildi, kayıt güncellendi ve sonraki aksiyonun sorumlusu belli. Her aşama için bir durum kaydedin. Son kanıttan önce yaşanan bir hata, nedenine göre sınıflandırılmalı: vazgeçme, yanlış anlama, politika sınırı, araç hatası, veri uyuşmazlığı, aktarım hatası ya da eksik takip gibi. Böylece süpervizörün önünde düzeltilecek somut bir şey olur ve yüksek bir otomasyonda kalma oranı operasyondaki işi gizleyemez.

Otomatik etiketleri bir inceleme örneklemiyle eşleştirin. İnceleyenler arayanın söylediği ihtiyacı, agent'ın cevabını, sonraki sistemdeki kaydı ve varsa sonraki temasları karşılaştırabilmeli. Agent “çözüldü” diyor ama sistemdeki kayıt değişmemişse, iş akışını anlaşılan kurala göre çözülmedi ya da bilinmiyor olarak sayın ve bir veri ya da süreç kaydı açın. Panel düzgün görünsün diye olayın üzerine yazmayın.

Başlangıç ölçümü alın ve kırılımlara ayırın

Prompt'ları, araçları ya da yönlendirmeyi değiştirmeden önce mevcut süreci kayda alın. Önce başlangıç grubunu tanımlayın: dahil edilen talepler, kapsanan kanallar ve saatler, eşleştirmede kullanılan kimlik ya da vaka anahtarı, başlangıç ve bitiş tarihleri ve hariç tutulanlar. Denenen çağrıları, bağlanan çağrıları ve otomatik akışa giren çağrıları ayırın. Test çağrıları, spam, mükerrer kayıtlar ve bilinen ölçüm kontrolleri yazılı olarak hariç tutulabilir. Kesintiler ve kuyruk kapanışları ise ayrı bir erişilebilirlik görünümünde raporlansa bile operasyonel koşul olarak görünür kalmalı.

İş günleri, yoğun dönemler, tatiller, diller ve eskalasyonları devralan kişi ya da sistemler arasındaki olağan farkları kapsayacak kadar uzun bir geçmişe bakın. Mevcut sonuç kodunu, tamamlanma süresini, aktarım hedefini, elle yapılan işi, tekrar temasları, düzeltme eforunu ve sonraki sistemlere yazılan kayıtları not edin. Mevcut ekibin güvenilir çözüm verisi yoksa bu sınırlamayı yazın ve verinin ne kadarının eksik olduğunu tahmin edin. Zayıf bir başlangıç ölçümü bile kesin görünen bir tahminden daha işe yarar. Ama pilot, iş sonucunda bir iyileşme iddia etmeden önce ölçümü iyileştirmeli.

Başlangıç ölçümünü ve her pilot raporunu talep, karmaşıklık, dil, günün saati, müşteri tipi, kimlik doğrulama yolu, entegrasyon yolu, kuyruk ve devir nedenine göre kırılımlara ayırın. Arayanın bir insan istediği çağrılar ve onaylı kapsamın dışında kalan çağrılar için de ayrı bir kırılım ekleyin. Karma bir otomasyonda kalma oranı yükselirken önemli bir talep kötüleşebilir. Örneğin bir destek akışı basit bir politika sorusunu doğru cevaplarken sipariş sorgusu gerektiren bir istisnada zorlanabilir. Bunlar tek bir ortalama değil, ayrı operasyon kararları olmalı.

Başlangıç ölçümüyle pilotu karşılaştırırken grup tanımını sabit tutun ya da değişikliği açıklayın. Yüzdelerin yanında adetleri gösterin; bir kırılımda anlamlı bir karşılaştırma için yeterli hacim yoksa kesin yorumdan kaçının. Tekrar temas ve görev tamamlama gecikmeli ölçülür: en son çağrılar ikinci bir temas doğuracak ya da son tarihine ulaşacak kadar zaman geçirmemiş olabilir. Bu grupları sıfır saymayın, henüz olgunlaşmamış olarak etiketleyin.

Alkış için değil, karar için panel kurun

Yönetim paneli dört soruyu sırasıyla cevaplamalı: kapsamda ne kadar trafik var, arayan hangi sonucu aldı, operasyona hangi iş kaldı ve risk nerede artıyor? Hacmi, uygun çağrıları ve veri kapsamını en üste koyun. Otomasyonda kalmayı çözümün, yanıltıcı otomasyonda kalma inceleme bulgularının ve bilinmeyen sonuçların yanında gösterin. Ardından aktarım kalitesini, tekrar teması, ilk insan aksiyonuna kadar geçen süreyi, düzeltme eforunu ve görev tamamlamayı gösterin. Tek bir karma puan yerel bir karar için işe yarayabilir, ama bu bileşen ölçümlerin yerini asla almamalı.

Yöneticilere bir eğilim ve bir detay görünümü verin. Eğilim, aynı tanımları gruplara göre karşılaştırmalı ve pilotun ya da sürümün başladığı noktayı göstermeli. Detay görünümü talep ve kırılımdan neden koduna, çağrıya, sistem olayına ve sorumluya inebilmeli. Her oranın arkasındaki adedi, kalite metrikleri için incelenen örneklem büyüklüğünü ve hâlâ sonraki sistemden sonuç bekleyen kayıt sayısını gösterin. Paneli bir aksiyon seçmek için kullanın: bir kaynağı güncellemek, bir araç korumasını değiştirmek, bir kuyruğu yeniden eğitmek, kapsamı daraltmak, test eklemek ya da trafiği durdurmak.

Küçük bir istisna görünümünü sürekli açık tutun: çözülmeyen çağrılar, yanıltıcı otomasyonda kalma, başarısız sisteme yazmalar, sahipsiz geri aramalar, yanlış hedefler, tekrarlanan kimlik doğrulama, aranmak istemeyenler ve kritik politika ya da veri bütünlüğü hataları. Bunlar yalnızca olumsuz notlar değildir. Ölçümü operasyondaki iyileşmeye bağlayan iş kuyruğudur.

İnsana devri ürünün bir parçası yapın

Agent trafik almadan önce devir sözleşmesine karar verin. Agent ne zaman aktaracağını, vakanın hangi kuyruğa ait olduğunu, hangi bilgilerin toplanması gerektiğini, arayanın kimliğini doğrulayıp doğrulamadığını ve arayanın sonra ne beklemesi gerektiğini bilmeli. Nedeni, ilgili kimlik bilgilerini, alınmış aksiyonları, belirsizlikleri ve söz verilen takibi içeren kısa bir özet gönderin. Arayana ne olduğunu söyleyin, operasyon izin veriyorsa sıradaki yerini koruyun ve uygun bir kişi yoksa bir geri arama yolu sunun.

Devir kalitesini bir taşıma olayı olarak değil, bir sonuç olarak ölçün. Devralan çalışan, aktarımın yerinde olup olmadığını, özetin doğru olup olmadığını, arayanın her şeyi baştan anlatmak zorunda kalıp kalmadığını ve sonraki aksiyonun net olup olmadığını anlayabilmeli. Başarısız aktarımları, yanlış kuyrukları, kaybolan bağlamı, tekrarlanan kimlik doğrulamayı, ilk insan aksiyonuna kadar geçen süreyi ve sonraki adımın tamamlanmasını izleyin. Doğru payda soruya göre değişir: bağlam kalitesi için aktarımları, yönlendirme kapsamı için eskalasyon gerektiren çağrıları, geri arama tamamlama için süresi dolan görevleri kullanın. Hangisini seçtiğinizi yazın.

Hata durumlarını da sorunsuz akış kadar dikkatle test edin: hedef kuyruk kapalı, aktarım başarısız, bir entegrasyon erişilemez, arayan kimlik doğrulamayı reddediyor, arayan hemen bir insan istiyor ya da agent emin değil. Güvenli bir yedek yol sorumlusu belli bir geri arama görevi, sonraki adımı olan sınırlı bir cevap ya da doğrudan eskalasyon olabilir. Platform iş akışı bu durumları işin sahibi olan ekibe görünür kılmalı.

Açık pilot kapılarıyla aşamalı ilerleyin

1. Ölçülebilir tek bir iş akışını kapsama alın

Doğru bilginin kaynağı belli, insan sınırı net, dar ve tekrarlanan bir arama nedeni seçin. Çözüm kanıtını, hariç tutulanları, arayanın seçimini, devir hedefini ve yedek yolu sade bir dille yazın. Operasyon sorumlusunu, kalite inceleyicisini, veri sahibini ve akışı durdurabilecek kişiyi adıyla belirleyin.

2. İyileştirmeden önce gözlemleyin

Başlangıç incelemesini yapın, temsil gücü olan çağrıları dinleyin ve hata nedenlerini etiketleyin. Yeni bir başlık rakamına bakmadan önce sözlükte ve inceleme ölçütlerinde anlaşın. Görüşme sonuçlarını sistemdeki kayıtla karşılaştırın ki ekip hangi sinyallerin güvenilir olduğunu bilsin.

3. Sınırlı kapsamla canlıya çıkın

Ekibin destekleyebileceği taleplerle, dillerle ve saatlerle başlayın. Bilinmeyen ve çözülmeyen sonuçları görünür tutun; süpervizörlere tek tek çağrıları ve sonraki sistem olaylarını inceleyebilecekleri bir yol verin. Pilotun sınırını kolayca geri alınabilir kurun ve devralan kuyruklara kötü bir devri nasıl bildireceklerini anlatın.

4. Devam, genişletme ve durdurma kapılarını belirleyin

Kapıları canlı trafikten önce, sonuca göre sonradan uydurmadan, kendi eşiklerinizle belirleyin. Devam etmek için kritik politika, kimlik, izin, veri bütünlüğü ve devir kontrollerinin geçmesi ve istisna kuyruğunun bir sorumlusu olması gerekir. Genişletmek için çözüm, aktarım kalitesi, görev tamamlama ve tekrar temas sinyalleri her önemli kırılımda, olgunlaşmış bir gözlem süresi boyunca kabul edilebilir düzeyde olmalı. Kritik bir hata çıktığında, sisteme yazılanlar mutabakata varılamadığında, devralan kuyruk erişilemez olduğunda, çözülmemiş iş sahipsiz kaldığında ya da anlaşılan bir koruma kötüleştiğinde durdurun veya geri alın. Kararı ve kanıtı bir sürüm kaydında saklayın.

5. Bir iyileştirme döngüsü işletin

Her inceleme bir kararla bitmeli: prompt'u değiştirmek, bir araç koruması eklemek, politikayı güncellemek, yönlendirmeyi ayarlamak, devir özetini iyileştirmek, ölçümü düzeltmek ya da davranışı olduğu gibi bırakmak. DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği Agent Factory iyileştirme döngüsü, incelenen çağrıları regresyon testlerine, kontrollü değişikliklere ve sürüm sonrası izlemeye bağlar. Sürümden işe yarar geri bildirim almak için ilk çağrıyı, hata etiketini, beklenen sonucu, etkilenen kırılımı, değişen katmanı, test sonucunu ve sürüm sonrası gözlemi bir arada tutun. Beklenmedik bir tekrar temas ya da düzeltme, tekrarlanabilir bir hatayı temsil ediyorsa yeni bir senaryoya ya da regresyon vakasına dönüşmeli.

Sürüm geri bildirimi ödünleşimleri de kontrol etmeli. Aktarımları azaltan bir değişiklik tekrar teması artırabilir. Daha sıkı bir kimlik adımı veri bütünlüğünü iyileştirirken vazgeçmeyi artırabilir. Yeni bir yedek yol bilinmeyen sonuçları azaltırken kuyruktaki işi artırabilir. Hedeflenen metriği, ters yönde hareket edebilecek kalite ve iş yükü ölçümleriyle karşılaştırın. Kalite testleri, değişiklik daha fazla arayana ulaşmadan önce onu bilinen uç durumlarla sınamalı. Sürüm sorumlusu da canlı sonucun hipotezi doğrulayıp doğrulamadığını, sınırlayıp sınırlamadığını ya da çürütüp çürütmediğini kaydetmeli.

Her metriğin bir sahibi olsun

Her metriğin adı belli bir sorumlusu ve adı belli bir veri kaynağı olsun. İş akışı tanımı ve karar operasyonun, inceleme ölçütleri ve örneklenen kanıt kalitenin, olay eksiksizliği ve sisteme yazma mutabakatı entegrasyon ya da sistem sahibinin, devir ve geri arama tamamlama kuyruk sorumlusunun işidir. Bir sponsor kapsama karar verebilir, ama bir paydayı açıklayabilen tek kişi o olmamalı.

İş akışı, olay şeması, kimlik kuralı ya da kanıt standardı değiştiğinde sözlüğe yeni bir sürüm numarası verin. Sürüm tarihini, kapsamı, incelenen kırılımları, istisnaları, kapı sonucunu ve takip sorumlusunu içeren kısa bir karar günlüğü tutun. Başlık metriklerini operasyonun olağan ritminde, tanımları ise insanlar bir etiketi farklı yorumlamaya başladığında gözden geçirin. Bir yönetici bir oranın neden değiştiğini sorduğunda ekip cevabı çağrılara, sistem sonuçlarına ve kayda geçmiş bir değişikliğe kadar izleyebiliyorsa, yönetim işliyor demektir.

Yönetim incelemesi kontrol listesi

• Her metrik bir sorumlu, pay, payda, kanıt kuralı ve sürüm numarasıyla tanımlı mı?
• Sistem otomasyonda kalmayı, doğrulanmış çözümü, yanıltıcı otomasyonda kalmayı, aktarım kalitesini, tekrar teması, görev tamamlamayı ve bilinmeyen sonucu birbirinden ayırabiliyor mu?
• Sabit bir grup, açık hariç tutmalar, adetler ve veri kalitesi sınırlarıyla bir başlangıç ölçümü aldınız mı?
• Önemli sonuçlar talebe, karmaşıklığa, dile, saate, müşteri tipine, entegrasyona ve devir nedenine göre kırılımlara ayrılıyor mu?
• Her eskalasyonun bir hedefi, bağlam paketi, yedek yolu, son saati ve sorumlu bir insanı var mı?
• Çözülmeyen, yarıda bırakılan, kimlik, politika, entegrasyon hatası ve sisteme yazma yolları test setinde var mı?
• Devam, genişletme ve durdurma kapıları pilottan önce, geri alınabilir bir akışla kararlaştırıldı mı?
• Her sürüm, incelenen çağrı kanıtını test edilmiş bir değişikliğe, bir sürüm kaydına ve sürüm sonrası geri bildirime dönüştürüyor mu?