Sesli yapay zeka için CRM'e yazma: pratik bir veri modeli

Pek çok sesli yapay zeka projesi sesli cevaba odaklanır, CRM'i bir entegrasyon ayrıntısı olarak görür. Canlıda çoğu zaman tersi doğrudur. Arkasında kullanılabilir bir kayıt bırakmayan akıcı bir görüşme, tek başına kalmış bir gösteridir. Talebi, kanıtı, sorumluyu ve sonraki aksiyonu kaydeden, biraz daha az parlak bir görüşme ise işi ileri taşıyabilir.

CRM'e yazmayı bir sonuç sözleşmesi olarak tasarlayın. Her iş akışı için sistemin neyi oluşturacağına, neyi güncelleyeceğine ve neye dokunmayacağına karar verin. Ardından kaydın müşteriye nasıl bağlanacağını, hangi alanların esas alınacağını, her değerin hangi kanıta dayandığını ve yazma başarısız olursa ne olacağını tanımlayın. DRING'in Connect katmanı, görüşmeleri yapılandırılmış operasyon kayıtlarına dönüştürmek üzerine kuruludur.

Transkriptle değil, nesneyle başlayın

Ekibin işi yürütmek için zaten hangi nesneyi kullandığını sorun: kişi, hesap, lead, fırsat, ticket, randevu, gönderi ya da vaka. Ekip hiç açmayacaksa her agent için yeni bir nesne oluşturmayın. Agent, bir sonraki aksiyonun zaten yaşadığı sisteme yazmalı.

Her sonuç için asgari alanları eşleyin. Nitelikli bir lead için hesap, ihtiyaç, zamanlama, bütçe sinyali, izin ve sorumlu gerekebilir. Bir destek vakası talep, ürün, sipariş numarası, durum, yapılan işlem ve öncelik isteyebilir. Bir geri arama görevi son saat, dil, neden ve kuyruk ister. Alan listesi tutarlı biçimde doldurulabilecek kadar kısa, yeni bir keşif aramasını gereksiz kılacak kadar zengin olmalı.

Bilgileri, yorumları ve verilen sözleri ayırın

Bir CRM kaydı çoğu zaman farklı kaynaklardan gelen değerleri karıştırır. Müşteri siparişin geciktiğini söyleyebilir. Kargo firmasının sistemi teslim edildiğini gösterebilir. Agent adresin incelenmesi gerektiği sonucuna varabilir. Bunları, işe yarıyorsa kaynağı ve zamanıyla birlikte, ayrı bilgiler olarak saklayın. Bir yorumu sistemde teyit edilmiş bir değermiş gibi yazmayın.

Müşterinin kendi ifadelerini bir özette ya da transkript referansında tutun, ama şirketin filtreleyeceği ya da yönlendireceği bilgiler için yapılandırılmış alanlar kullanın. Böylece yöneticiler her görüşmeyi yapısız bir nota çevirmeden tekrarlanan sorunları arayabilir. Kalite inceleyicileri de özeti asıl kanıtla karşılaştırabilir.

Idempotency ve vaka kimliği kullanın

Çağrılar yeniden denenebilir, agent'lar yeniden bağlanabilir, müşteri de sesli görüşmeden WhatsApp'a ya da SMS'e geçebilir. Sabit bir vaka kimliği olmadan entegrasyon mükerrer kişi, görev ya da fırsat kayıtları yaratabilir. Bir etkileşimin mevcut bir kayıtla nasıl eşleşeceğine ve ne zaman yeni bir vaka açılacağına karar verin. İzlenebilirlik için görüşme kimliğini ve kaynak kanalı saklayın.

Idempotency, başarılı bir yazma işlemini tekrarlamanın yeni bir iş olayı yaratmaması demektir. Ağ ilk istekten sonra zaman aşımına uğradı diye bir geri arama talebi üç görev üretmemeli. Bir randevu teyidi birden fazla saati bloke etmemeli. Entegrasyon “istek gönderildi”, “sonuç teyit edildi” ve “tekrar denemek güvenli” durumlarını birbirinden ayırmalı.

Araç yetkilerini açıkça tanımlayın

Yalnızca okuyan sorgular ile yazan işlemlerin riski farklıdır. Sesli bir agent'ın sipariş durumunu okumasına izin verilip teslimat adresini değiştirmesine izin verilmeyebilir. Bir takvim aralığı önerebilir ama randevuyu koymadan önce müşterinin teyidini beklemesi gerekebilir. Bir destek görevi açabilir ama bir şikayeti kapatamayabilir. DRING'in güvenlik modeli ve entegrasyon rehberi, bu sınırları tasarımın bir parçası haline getirmeye yardım eder.

Her işlemin bir ön koşulu, bir başarı cevabı ve bir hata cevabı olmalı. CRM yazmayı reddederse agent kaydın güncellendiğini söylememeli. Bilgileri korumalı, onaylı bir yedek yol açmalı ya da vakayı bir insana devretmeli. Doğru bir “çözülmedi” durumu, yanlış bir “tamamlandı” durumundan iyidir.

Özeti işi devralacak kişiye göre yazın

İşe yarar bir özet şu soruları cevaplar: müşteri bize neden ulaştı, şu ana kadar ne oldu, ne açık kaldı ve sıradaki adım kimde? En önemli cümleyi başa yazın. Takibi etkiliyorsa arayanın dilini ya da tercih ettiği iletişim kanalını ekleyin. Tonu olgulara dayalı tutun, dayanağı olmayan duygu durumu etiketlerinden kaçının.

Devirde, neden bir insana ihtiyaç olduğunu ve insanın cevaplaması gereken soruyu ekleyin. Satışta genel bir “sıcak lead” etiketi yerine nitelemenin dayandığı kanıtı ekleyin. Operasyonda planı değiştiren hareketi ya da istisnayı tam olarak yazın. DRING'in devir modeli ve aylık sektör analizi, kayıtların ilk görüşmenin ötesinde de nasıl işe yarar kalabileceğini gösterir.

Çağrı sonrası analitiği kayda bağlayın

Çağrı düzeyindeki analitik talebi, sonucu, dili, politika sinyalini ve bir sonraki en iyi aksiyonu belirleyebilir. Türetilen her sinyali ana CRM kaydına yazmayın. Operasyon kaydını temiz tutun, daha zengin analitiğe ya da yönetici paneline link verin. Yalnızca bir ekip arkadaşının karar vermek, yönlendirmek ya da takip etmek için kullanacağı alanları saklayın.

Agent, prompt, politika ve entegrasyon şeması için bir sürüm alanı kullanın. Bir sürüm özet biçimini değiştirirse ekip eski kayıtları yenilerinden ayırabilmeli. Bu sürümleme, DRING'in agent'ları kurduğu, test ettiği ve geliştirdiği sistem olan Agent Factory'nin aday bir sürümü canlıdaki davranışla karşılaştırmasına da yardım eder.

Sisteme yazma yolunu uçtan uca test edin

Eşleşen kayıt, bulunamayan kayıt, mükerrer müşteri, yavaş cevap, reddedilen yetki, çelişen sistem verisi ve fikrini değiştiren müşteri için senaryolar kurun. Yalnızca API cevabını değil, insan kullanıcının ne gördüğünü de kontrol edin. Görev doğru kuyrukta mı? Son saat doğru mu? Sorumlu, aksiyonu anlayabiliyor mu?

Kayıtları sahte kesinlik açısından inceleyin. “Çözüldü” işaretli bir alanın arkasında tamamlanma kanıtı olmalı. “Müşteri kabul etti” işaretli bir alan modelin varsayımını değil, açık bir teyidi yansıtmalı. DRING'in kalite testleri bu koşulları sürüm kapısının bir parçası olarak puanlayabilir.

CRM'e yazma için pratik kontrol listesi

• Bir sonraki insan aksiyonunun yaşadığı mevcut nesneyi seçin.
• Asgari alanları talebe ve sonuca göre tanımlayın.
• Arayanın verdiği bilgileri, sistemdeki bilgileri ve agent'ın yorumlarını ayırın.
• Kanallar arasında sabit bir vaka kimliği ve idempotent yazma işlemleri kullanın.
• Yetkileri, ön koşulları, başarı cevaplarını ve hata yollarını belirleyin.
• Agent'ı ve şemayı sürümleyin, sonra CRM'de görünen sonucu test edin.

CRM entegrasyonu, konuşma tasarımından sonra gelen son adım değildir. Bir çağrı ile bir iş kararı arasındaki köprüdür. Kayıt doğru, sade ve harekete geçirilebilir olduğunda agent operasyon modelindeki yerini hak eder.

Ek okumalar

• OpenAI: veri araçları, işlem araçları ve standart agent tanımları
• Twilio: ses, mesajlaşma ve AI agent'ları arasında ortak bağlam
• NIST: dokümantasyon, test ve sürekli yapay zeka risk yönetimi