Fintech ödeme desteğinde sesli yapay zeka: güvenli bir operasyon modeli

50 ila 100 çalışanlı bir fintech ya da ödeme şirketinde destek hacmi operasyon ekibinden hızlı büyüyebilir. Daha güvenli bir sesli yapay zeka pilotu agent'a dar bir iş verir: arayanı onaylı bir akışla tanımak, güvenilir durum bilgisini açıklamak, bağlamı toplamak ve vakayı bir sonraki kontrollü adıma taşımak. Etkisi yüksek kararlar insanların gözü önünde kalır.

Gerçek çağrılarla, politikalarla ve sistem yetkileriyle başlayın. İyi bir finans ve ödeme çağrı haritası, tekrarlanabilir açıklamaları yetki gerektiren aksiyonlardan ayırır. Bu sınırı senaryoyu yazmadan önce yazın.

Tasarımın birimi arayanın cümlesi değil, ödemenin durumudur. Arayan "olmadı" dediğinde kayıtta bir ret, hâlâ süren bir provizyon, ardından iade gelmiş tamamlanmış bir ödeme ya da incelemedeki bir işlem görünebilir. Agent bu belirsizliği güvenilir bir kayıt sistemine bakarak çözmeli, sonra durumu sade bir dille anlatmalıdır. Sistemler birbiriyle çelişiyorsa doğru sonuç kendinden emin bir özet değil, görünür bir istisnadır.

Ödeme taleplerini ayrı ayrı ele alın

Tek ve geniş bir "ödeme sorunu" yolu kurmayın. Her talep türünün kendi hedefi, bilgi kaynağı, araç yetkisi ve tamamlanma koşulu olmalıdır.

Başarısız ödemeler

Önce reddi iptalden ayırın. Ret, denenen ödemenin tamamlanmadığı anlamına gelir. İptal ise daha önce görünen bir provizyonun ya da borçlandırmanın geri alındığı veya iade edildiği anlamına gelir. Ödeme kaydındaki onaylı durumu, durumun saatini ve izin verilen sonraki adımı açıklayın. Bankanın ödemeyi neden reddettiğini tahmin etmeyin, tekrar denemenin başarılı olacağına söz vermeyin, tekrar deneme kurallarını değiştirmeyin. Tekrar denemeye izin varsa, üst üste denemeye teşvik etmeden mevcut yolu açıklayın. Müşteri duruma itiraz ettiğinde, bakiye etkilendiğinde ya da hesap veya ödeme bilgisi değişikliği gerektiğinde insan incelemesi sunun.

Bekleyen işlemler

Güncel durumu ve zaman damgasını okuyun, yalnızca o durum için tanımlı politikayı açıklayın. "İşleniyor" durumu, "tamamlandı" ya da "başarısız" ile aynı şey değildir. Bekleyen bir kart provizyonu da üye işyerinin tutarı tahsil ettiğinin kanıtı değildir. Cevap ödeme referansını belirtmeli, provizyonun ne zaman kalkacağına dair sistemde olmayan bir saat vermemeli ve durumu hangi olayın değiştireceğini söylemelidir. Süresi geçmiş vakaları, çelişen kayıtları, tutarın serbest bırakılması taleplerini ve müşteriyi acil etkileyen durumları üst seviyeye aktarın. İnsan kuyruğu son durum kontrolünü görebilmeli ki arayandan aynı süreci tekrar anlatması istenmesin.

İadeler

İadeyi hem ödeme iptalinden hem ters ibrazdan ayrı tutun. İade talep edilip edilmediğini, o alan varsa tam mı kısmi mi olduğunu, kayıtlı durumunu, ilgili ödeme referansını ve teyit kanalını doğrulayın. Tutarı müşterinin anlatımına dayandırmak yerine onaylı referans sorgusunu kullanın. Vakanın başlatılmayı mı beklediğini, işlemde mi olduğunu yoksa gönderildi olarak mı kaydedildiğini söyleyin, ama bir ödeme kuruluşu ya da muhasebe kaydı olayını garantili bir hesaba geçiş tarihine çevirmeyin. İade başlatmak, tutarı değiştirmek, istisna tanımak ve iadenin gideceği hesabı değiştirmek açık yetki ve gerektiğinde insan onayı ister.

Ters ibraz ve itirazlar

Sebep, işlem referansı, ilgili tarihler ve destekleyici bağlam için ayrı bir kayıt yolu kullanın. Müşterinin olayları anlatışını sistemin bulgusundan ayrı tutun ve inceleme için önemli olduğu yerde orijinal ifadeyi vakada saklayın. Agent süreçteki sonraki adımı, gereken kanalı ve kayıtlı vaka durumunu açıklayabilir. Ama açık yetki ve test olmadan uygunluğa karar vermemeli, itirazın nasıl yazılacağını yönlendirmemeli, ters ibraza itiraz kararı vermemeli ve itirazı kapatmamalıdır. Üye işyerinden iade talebini kart hamilinin itirazıyla birleştirmeyin: her birinin sahibi, kaydı ve devri farklıdır.

Şüpheli işlem

Tanınmayan bir ödemede yalnızca onu bulmak için gerekeni toplayın ve onaylı inceleme ya da hesap koruma yolunu izleyin. Tanınmayan bir işlem müşterinin bildirimidir. Tek başına ödemenin dolandırıcılık olduğu anlamına gelmez. Bir işlemi asla dolandırıcılık diye etiketlemeyin, inceleme ayrıntısı paylaşmayın, tek kullanımlık şifre, PIN, kart numarasının tamamı ya da başka bir gizli bilgi istemeyin. Onaylı akış bir koruma aksiyonu gerektiriyorsa bunu yetkili araca ya da insan kuyruğuna yönlendirin ve müşteriye yalnızca onu ilgilendiren sonraki adımı söyleyin. Eskalasyon sebebini gereksiz hassas ayrıntıları kopyalamadan kaydedin.

Kimlik ve aksiyon sınırlarını belirleyin

Kimlik doğrulama bir kontrol sınırıdır. Ürün ve risk düzeyi için onaylanmış kimlik doğrulama yöntemini kullanın. Arayan numarası ya da ses sinyalleri bu akışı destekleyebilir, ama daha güçlü bir doğrulamanın yerini sessizce almamalıdır. Doğrulama başarısız olursa ya da bilgiler uyuşmazsa hesaba özel ayrıntı vermeden nasıl devam edileceğini açıklayın.

Agent'ın neyi açıklayabileceğini, neyin bir insan ya da yetkili bir araç gerektirdiğini yazın. Durum, yayımlanmış süreç, vaka numarası ve sonraki adım tipik açıklamalardır. Kimlik bilgilerini, ödeme bilgilerini ya da ödemenin gideceği hesabı değiştirmek, bir blokeyi kaldırmak, istisna onaylamak, itiraza karar vermek ve çelişen kayıtları çözmek varsayılan olarak insan incelemesine gitmelidir. Salt okumayla başlayın, yazma işlemlerini her biri için bir sorumlu, onay kuralı ve geri dönüş yoluyla tek tek ekleyin.

Doğrulama durumunu kimlik verisinden daha dar tutun. Başarılı bir kontrol, politikaya göre yöntemi, saati ve geçerlilik süresi kaydedilmiş "bu sorgu için doğrulandı" gibi kapsamı belli bir sonuç üretmelidir. Sonraki her aksiyonu açmamalıdır. Doğrulama sorularının cevaplarını, kimlik doğrulama faktörlerini ya da tam kimlik numaralarını serbest metin özete koymayın. Arayan bunları kendiliğinden söylerse kibarca araya girin, tekrar etmeyin ve onaylı maskeleme ya da olay yönetimi yolunu izleyin.

Ödeme verisini ve ses kayıtlarını koruyun

Görüşmenin dokunduğu her alanı çıkarın: ses, transkript, arayan numarası, kimlik bilgileri, referanslar, kimlik doğrulama sonucu ve CRM notları. Gereken en az veriyi toplayın. Ödeme bilgilerini maskeleyin ya da tokenize edin, gizli bilgileri transkriptten engelleyin ve hassas veri yüksek sesle söylenirse agent'a bir reddetme yolu verin. Ses kaydı, yazıya dökme, saklama ve erişim ayarları gizlilik, güvenlik ve ödeme ekiplerinizin onayladığı kontrollerle uyuşmalıdır. En az yetki, denetlenebilirlik ve insana devir için güvenlik kontrollerine genel bakışa göz atın.

Arayanlara yapay zekayla konuştuklarını, neyin kaydedildiğini ya da işlendiğini ve bir kişiye nasıl ulaşabileceklerini söyleyin. Kayıt ve bilgilendirme kuralları pazara göre değişir. Yaklaşımı yetkin hukuk ve uyum danışmanlarıyla teyit edin. EDPB'nin sanal sesli asistanlar rehberi bu incelemeye ışık tutabilir.

Operasyon kayıtlarını amaca göre ayırın. Transkript kalite incelemesine, ödeme referansı sorguya, vaka özeti de kuyruk işine yarar. Hiçbiri aynı erişim kitlesini ya da saklama süresini otomatik olarak devralmamalıdır. Transkript daha geniş bir analiz akışına girmeden önce maskeleyin, ses kayıtlarına erişimi denetlenebilir yapın. Agent'ın hassas bir bilgiyi almayı reddetmesi, kısmi maskeleme ya da kayıt hatası görünmez bir uç durum değil, kalite ekibinin örnekleyebileceği açık bir olay olmalıdır.

Eskalasyonu ve CRM'e geri yazmayı akışın parçası yapın

Aktarımları şu durumlar için tanımlayın: bir kişiyle görüşme isteği, başarısız doğrulama, tekrarlanan yanlış anlama, yüksek riskli talep, hassas durumdaki ya da sıkıntılı arayan, politika istisnası, araç kesintisi ya da müşterinin finansal durumunu değiştirebilecek belirsizlik. Talebi, doğrulama durumunu, referansı ve eskalasyon sebebini sıcak devirle birlikte aktarın. Bilgiyi teyit eden ve sonraki adıma karar veren insandır.

İnsana yalnızca bir ses kaydı ulaşıyorsa aktarım eksiktir. Kısa ve makinenin okuyabileceği bir bağlam paketi iletin: talep, doğrulama durumu, ödeme referansı, en son kaynak ve zaman damgası, müşterinin bildirdiği sebep, söz verilen sonraki adım ve agent'ın neden durduğu. İnsanın bu bağlamı düzeltmesine, arayanın da önemli bilgileri teyit etmesine izin verin. Müsait temsilci yoksa canlı bir devir olmuş gibi davranmak yerine dürüst bir yanıt süresi politikasıyla kuyrukta bir kayıt açın.

Çözülen ya da aktarılan her çağrı için yapılandırılmış bir vaka geri yazın: talep, doğrulama sonucu, durumun kaynağı ve saati, müşterinin sebebi, aksiyon, sonraki adım, sorumlu, eskalasyon sebebi ve kayıt ya da maskeleme işaretleri. Özeti transkriptten ayrı tutun, alan erişimini sınırlayın ve başarısız yazma işlemlerini yeniden deneme için görünür kılın. Sonradan gelen bir ödeme sistemi olayının hassas değerleri serbest metne koymadan çağrıyla eşleşebilmesi için bir ilişkilendirme ID'si ekleyin. Kanallar arasında tutarlı geri yazma, çağrıları operasyonun üzerinde çalışabileceği bir kuyruğa çevirir.

Pilotla ve kalite kapısıyla yayına alın

Tek bir hat, sınırlı saatler ve bekleyen işlem durumu açıklaması ya da iade sorgusu gibi bir iki düşük riskli talep türüyle başlayın. İnsan kuyruğunu açık tutun. Gölge aşamada agent'ın önerdiği cevaplar, agent müşteriyle konuşmaya başlamadan önce mevcut süreçle karşılaştırılabilir. Ardından sınırlı bir pilot, durdurma kontrolüyle seçilmiş trafiği kullanabilir. Canlı trafikten önce normal çağrıları, sessizliği, söz kesmeyi, yanlış numaraları, kimlik doğrulama hatasını, çelişen araç verisini, prompt manipülasyonunu ve her eskalasyon tetikleyicisini test edin. Cevapları, araçları, ses kaydını ve aktarım davranışını operasyon, güvenlik, ödeme ve uyum sorumluları onaylamalıdır.

Çözüldü olarak işaretlenenler dahil, her talep ve sonuçtaki çağrıları inceleyin. Doğruluğu, kimlik yönetimini, yasaklı veri toplanmasını, bilgilendirmeyi, tonu, vaka alanlarını, aktarım bağlamını ve tekrarlanan soruları kontrol edin. Regresyon vakaları ve devir kontrolleri için sesli yapay zeka test yaklaşımını kullanın. Örneklemi yalnızca hacme göre değil, talebe ve riske göre alın ki nadir bir şüpheli işlem çağrısı rutin durum çağrılarının arasında kaybolmasın. Yeni bir hata türü ortaya çıktığında kapsamı daraltın.

Yalnızca otomasyonda kalma oranını değil, operasyon kalitesini ölçün

Bir başlangıç değeri belirleyin ve talebe göre raporlayın. Doğrulanmış çözümü, müşterinin talebinin gereken doğrulama ve vaka kaydıyla tamamlanması ya da doğru cevaplanması olarak tanımlayın. Bu, çağrının bitmesiyle aynı şey değildir. Otomasyonda kalmayı aktarımsız biten bir çağrı olarak tanımlayın, sonra bu çağrının daha sonra yeniden açılıp açılmadığını ya da tekrar edip etmediğini raporlayın. Doğru yönlendirmeyi, güvenli aktarımın kabul edilmesini, seçilen bir süre içinde tekrar temasları, vakanın geri yazılmasına kadar geçen süreyi, çözülmemiş ödeme sorunlarını, şikayet sinyallerini ve insanın yeniden yaptığı işi izleyin. Başarısız ödemeler ve şüpheli işlemler için yanlış açıklamaları, kaçırılan ya da gereksiz eskalasyonları da ekleyin. Sonuç dağılımlarını ve transkriptleri inceleyin. Otomasyon oranı tek başına kontrol kalitesini gösteremez. Analiz ekranını kullanmadan önce olayları ve etiketleri tanımlayın.

İncelenen çağrıları kontrollü öğrenmeye çevirin

İncelenen çağrılar canlı sistemi güncellemeden önce test setini güncellemelidir. Hatayı etiketleyin, bir regresyon senaryosuna çevirin, onaylı kaynağı ya da kuralı güncelleyin, etkilenen talebi yeniden test edin ve değişikliği kaydedin. Sürümleri adı belli bir onaylayan ve bir durdurma mekanizmasıyla aşamalı olarak yayına alın.

Agent Factory'de öğrenmenin işe yarar anlamı budur: incelenen kanıt yapılandırılmış geri bildirime, yeni testlere ve önerilen bir sürüme dönüşür. Agent Factory, DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği süreçtir. Bu, müşteri çağrılarının genel bir modeli eğitmek için sessizce kullanıldığı anlamına gelmez. Veri kullanımı, saklama ve onay sınırlarını açıkça belirleyin.

Tedarikçi ve pilot için pratik kontrol listesi

Tedarikçiye sorun

• Talep kapsamını, izin verilen cevapları, araç yetkilerini ve reddetme davranışını gösterin.
• Ödeme verisi, gizli bilgiler, ses kayıtları ve transkriptler için maskeleme, saklama ve erişimi açıklayın.
• Yapay zeka bilgilendirmesini, insana aktarımı, araç kesintisini ve başarısız CRM yazma davranışını gösterin.
• Sonuçların, inceleme kanıtlarının ve regresyon sonuçlarının talebe göre dışa aktarılabildiğini teyit edin.

Pilotu tanımlayın

• Her talebin sorumlusunu, eskalasyon kuyruğunu ve durma koşulunu belirleyin.
• Başarısız, bekleyen, iade, ters ibraz ve şüpheli işlem çağrıları için test vakalarını onaylayın.
• Başlangıç değerlerini, inceleme örneklemini, yayın sıklığını ve pazara özel veri kararlarını seçin.

Ödeme hizmetleri ve yapay zeka şeffaflığı yükümlülükleri pazara göre değişir. Canlıya çıkmadan önce güçlü müşteri kimlik doğrulaması ve AB Yapay Zeka Yasası (AI Act) dahil geçerli şartları yetkin bir hukuk danışmanıyla gözden geçirin. Pilot, 50 ila 100 kişilik bir ekibe yüksek riskli işi incelenmemiş bir iş akışına bırakmadan kanıt sağlar.