Müşteri Güvenini Kaybetmeden 30 Günde Web Sitesi AI Asistanı Nasıl Yayına Alınır?

Bir web sitesine öğleden sonra içinde bir AI sohbet penceresi ekleyebilirsiniz. Ancak müşterilerin güveneceği bir asistanı yayına almak bambaşka bir projedir.

Aradaki farkı modelin çevresinde yürütülen çalışmalar belirler: görevin doğru seçilmesi, güvenilir bilgiyle beslenmesi, eylemlerinin sınırlandırılması, hata senaryolarının test edilmesi ve gerektiğinde bir insana ulaşmanın kolaylaştırılması. İlk sürümün kapsamı bilinçli biçimde dar tutulursa 30 günde yayına çıkmak gerçekçidir. “Yayına çıkmak”, tüm görüşmeleri bir anda otomatikleştirmek anlamına geliyorsa bu takvim ciddi risk taşır.

Bu rehber; ürün sorularını yanıtlayan, talepleri nitelendiren veya sınırlı sayıdaki destek talebini çözen, belirli bir amaca odaklanmış web sitesi asistanları içindir. Hedef, kapsamını genişletme hakkını performansıyla kazanan, gerçekten faydalı bir ilk sürüm oluşturmaktır.

Birinci günden önce: İlk görevi tanımlayın

Tek bir cümleyle başlayın:

Asistan, bu hedef kitlenin bu görevi tamamlamasına onaylanmış şu kaynakları kullanarak yardımcı olur ve şu koşullar oluştuğunda görüşmeyi bir insana devreder.

“İşletmemiz hakkında her şeyi yanıtlamak” bir görev değildir. “Potansiyel müşterilerin üç hizmet paketimizi karşılaştırmasına ve doğru danışmanlık görüşmesini planlamasına yardımcı olmak” ise bir görevdir. “Birleşik Krallık'taki müşterilerin teslimat ve iade sorularını yayımlanmış politikalarımıza göre yanıtlamak” da öyle. Sınırları belli bir görev, ekibinize test edilebilir bir hedef; asistana da ötesine geçip doğaçlama yapmaması gereken net bir çizgi verir.

İlk görevi dört ölçüte göre seçin:

• Sıklık: Ziyaretçiler bu konuda zaten sık sık soru soruyor mu?
• Değer: İyi bir yanıt dönüşümü, hizmet kalitesini veya müşteri çabasını iyileştiriyor mu?
• Dokümantasyon: Doğru yanıt onaylanmış bir kaynakta mevcut mu?
• Geri alınabilirlik: Bir hata ciddi bir finansal, hukuki veya kişisel zarara yol açmadan düzeltilebilir mi?

Bir iş birimi sorumlusu ve bir teknik sorumlu belirleyin. İş birimi sorumlusu, doğru müşteri deneyiminin nasıl olması gerektiğine karar verir. Teknik sorumlu ise veri erişimini, entegrasyonları, sürümleri ve olay müdahalesini yönetir. Asistanın sahibi herkes ise hatalarının sahibi hiç kimse olur.

Geliştirmeye başlamadan önce bir değerlendirme kartı üzerinde anlaşın: yanıt kalitesi, görev tamamlama, insana devir kalitesi, müşteri geri bildirimi ve ciddi hata sayısı. Tek hedefiniz “otomatikleştirilen görüşme sayısı” olmasın. Bir asistan insan temasından kaçınırken müşterileri hâlâ hayal kırıklığına uğratabilir.

1–7. günler: Güvenilir bir bilgi temeli oluşturun

Bir asistan, birbiriyle çelişen politikaları etkileyici cümlelerle düzeltemez. Fiyatlandırma sayfasında bir bilgi, satış dokümanında başka bir bilgi yer alıyor ve eski bir yardım makalesi hâlâ dizine ekleniyorsa asistandan şirket politikasını o anda kendisinin seçmesi istenmiş olur.

İnsanların gerçekten sorduğu sorularla başlayın. Site içi arama sorgularını, formları, sohbet kayıtlarını, destek taleplerini ve satış görüşmesi notlarını inceleyin. Bunları konularına göre gruplandırın, ardından hangilerinin ilk görevin kapsamına girdiğini belirleyin.

Asistanın kullanacağı her kaynak için şu bilgileri kaydedin:

• kaynaktan sorumlu kişi;
• son gözden geçirilme tarihi;
• geçerli olduğu hedef kitle, pazar, ürün ve dil;
• bağlayıcı bir kaynak mı, yoksa yalnızca destekleyici bağlam mı olduğu;
• varsa geçerlilik bitiş tarihi veya planlanan politika değişikliği.

Tekrarlanan içerikleri kaldırın, süresi dolan materyalleri arşivleyin ve çelişkileri çözün. Belirsiz sayfaları, ziyaretçinin sorusuna doğrudan yanıt verecek biçimde yeniden yazın. Önemli koşullar yalnızca ekran görüntülerinde veya videolarda değil, metin olarak da bulunmalıdır.

Ardından bir kaynak hiyerarşisi oluşturun. Güncel bir politika, iki yıl önce yayımlanmış bir blog yazısından daha öncelikli olmalıdır. Ürün dokümantasyonu, resmî olmayan bir satış notundan daha üst sırada yer almalıdır. Onaylanmış iki kaynak birbiriyle çelişiyorsa doğru davranış genellikle belirsizliği kabul edip görüşmeyi devretmektir; bunlardan birini sessizce seçmek değil.

Yedinci günün sonunda başlangıç test setinizi hazırlayın. Mümkünse gerçek ve anonimleştirilmiş soruları kullanın. Test setine şunları ekleyin:

• farklı şekillerde ifade edilmiş yaygın sorular;
• belirsiz, yazım hatalı ve birden fazla bölüm içeren sorular;
• onaylanmış kapsamın hemen dışında kalan sorular;
• her koşulda bir insana yönlendirilmesi gereken talepler;
• doğru yanıtın “Bilmiyorum” olduğu durumlar.

Her sorunun yanına beklenen yanıtı ve yapılması gereken eylemi yazın. Bu set, gelecekteki değişiklikler için regresyon test paketiniz olacaktır.

İlgili yazı: Bilgi Tabanınız Yapay Zekâya Hazır mı? 12 Maddelik İçerik Denetimi

8–14. günler: Davranışları, yetkileri ve insana devri tasarlayın

Şimdi asistanın yalnızca ne bilmesi gerektiğini değil, nasıl davranması gerektiğini de tanımlayın.

Ziyaretçilere bir AI asistanıyla konuştuklarını açıkça belirtin. “Paketleri karşılaştırmanıza veya bir görüşme planlamanıza yardımcı olabilirim” ifadesi, “Bana her şeyi sorabilirsiniz” mesajından daha doğru bir beklenti yaratır. Görüşmeler incelenebiliyor veya saklanabiliyorsa kolayca erişilebilen bir gizlilik bildirimine bağlantı verin ve işletmeniz için geçerli gerekliliklere uyun.

Çalışma kurallarını sade bir dille yazın. Üslubu, kullanılacak terimleri, desteklenen pazarları, yasaklanan iddiaları ve asistanın hangi noktada durması gerektiğini belirtin. Güçlü bir kural gözlemlenebilir ve test edilebilirdir: “Sipariş sistemi tarafından doğrulanmayan bir teslimat tarihi için asla söz verme” ölçülebilir; “Her zaman yardımcı ol” ise ölçülemez.

Eylem yetkilerini yanıt yetkilerinden daha dar tutun

Yalnızca onaylanmış bilgileri getiren bir asistanın risk alanı; sipariş değiştiren, kredi tanımlayan, randevu oluşturan veya CRM'e veri yazan bir asistandan daha küçüktür. Entegrasyonları katmanlar hâlinde ekleyin:

1. Onaylanmış herkese açık içerikleri okuyun.
2. Kimlik doğrulamasından sonra sınırlı, müşteriye özel bilgileri getirin.
3. Müşterinin veya çalışanın onaylayacağı bir eylem taslağı hazırlayın.
4. Tanımlı sınırlar içinde dar kapsamlı ve geri alınabilir bir eylemi gerçekleştirin.

En az ayrıcalık ilkesine uygun erişim bilgileri kullanın ve yalnızca ilk görev için gerekli alanları erişime açın. Test ve canlı ortam bilgilerini birbirinden ayırın, girdileri doğrulayın, eylem girişimlerini kaydedin, tekrarları önleyin ve bir hizmet kullanılamadığında ne olacağını tanımlayın. Etkisi yüksek eylemler kullanıcı onayı gerektirmeli veya bir insanın onayına bağlı kalmalıdır.

İnsana devri tasarlanmış bir yolculuğa dönüştürün

“Destek ekibiyle iletişime geçin” demek, görüşmeyi devretmek değildir. Devir koşullarını önceden belirleyin: doğrudan bir insanla görüşme talebi, art arda başarısız yanıtlar, hayal kırıklığı, düşük güven düzeyi, hesap anlaşmazlığı, hassas bir konu veya asistanın yetkisini aşan bir eylem.

Görüşmeyi devralan ekip; konuşma geçmişini, ilgili bağlamı, denenmiş eylemleri ve devir nedenini görmelidir. Ziyaretçiye bundan sonra ne olacağını söyleyin ve gerçekçi bir yanıt süresi verin. Bir insanla görüşmek isteyen müşteriyi tekrar tekrar AI mesajlarına mahkûm etmeyin.

14. günün sonunda ekibiniz, web sitesindeki ilk karşılama mesajından başarılı bir yanıta, onaylanmış bir eyleme veya insana devre kadar tüm yolculuğu; ortasında tanımsız bir kutu bırakmadan çizebilmelidir.

15–21. günler: Deneyimi ve hata biçimlerini test edin

Başlangıç sorularını çalıştırın ve yalnızca kulağa akıcı gelip gelmediğini değil, yanıtın tamamını değerlendirin. Şunları sorun:

• Yanıt bu kullanıcının pazarı, paketi ve bağlamı için doğru mu?
• Onaylanmış ve güncel bir kaynağa dayanıyor mu?
• Gereksiz iddialarda bulunmadan asıl soruyu yanıtlıyor mu?
• Yalnızca izin verilen eylemleri mi gerçekleştiriyor?
• Belirsizliği fark edip doğru zamanda devrediyor mu?

Hataları sınıflandırın: eksik bilgi, çelişkili içerik, bilgi getirme hatası, belirsiz talimat, entegrasyon hatası, zayıf devir veya güvenli olmayan davranış. Altta yatan kaynağı ya da kuralı düzeltin; daha uzun bir istem metni, kötü içeriği güvenilir biçimde telafi edemez.

Ardından karşıt senaryo testleri uygulayın. Asistanı geliştirmemiş çalışanlardan varsayımları zorlamalarını isteyin. Prompt injection girişimlerini, başka bir müşterinin verilerine erişim taleplerini, hakaret içeren dili, desteklenmeyen dilleri, yanlış öncülleri, acil durumları ve tek mesajda birden fazla talebi deneyin. Kullanılamayan API'leri, yavaş yanıtları ve eksik müşteri kayıtlarını da test edin.

Her eylem için hem sorunsuz akışı hem de kesinti senaryolarını sınayın. Bir randevu saati artık müsait değilse, API işlemi gerçekleştirdikten sonra zaman aşımına uğrarsa veya aynı talep iki kez gelirse ne olacak? Güvenli biçimde toparlanmak da ürünün bir parçasıdır.

Müşteriyle doğrudan çalışan ekipleri, asistanı gerçek bir ziyaretçi gibi kullanmaya davet edin. Sınır durumlarını, politika istisnalarını ve müşterilerin kullandığı ifadeleri onlar bilir; üstelik yayından sonra devredilen görüşmeleri de onlar yönetecektir.

Demo iyi göründüğü için bir sonraki aşamaya geçmeyin. Üzerinde anlaşılan test seti başarıyla tamamlandığında, yüksek riskli hatalar giderildiğinde ve çözülememiş her kısıtlama için bir sorumlu ile müşteriyi koruyan bir alternatif belirlendiğinde ilerleyin.

İlgili yazı: Gerçekten Önemli Olan Yapay Zekâ Asistanı Metrikleri (Saptırma Oranının Ötesinde)

22–30. günler: Küçük bir kitleye açın ve yakından izleyin

Tek bir kanal, tek bir kullanım senaryosu ve sınırlı bir kitleyle başlayın. Bu kitle çalışanlarınız, tek bir bölge veya uygun görüşmelerin küçük bir bölümü olabilir. Sistemi hızla kapatabileceğiniz bir anahtar ve aktif bir insana devir kanalı bulundurun.

İlk görüşmeleri her gün inceleyin; hem başarılı hem başarısız örneklerden seçkiler değerlendirin. Yanıltıcı yanıtları, gereksiz devirleri, yarıda bırakılan görüşmeleri, tekrar tekrar farklı biçimde sorulan soruları ve elle düzeltilmesi gereken eylemleri arayın.

Dengeli bir ölçüm seti izleyin:

• Yanıt kalitesi: İncelendiğinde doğru, ilgili ve kaynağa dayalı olduğu görülen yanıtlar.
• Görev tamamlama: Hedeflenen sonuca ulaşan ziyaretçiler.
• Devir kalitesi: Yararlı bağlamla doğru ekibe ulaşan görüşmeler.
• Müşteri çabası: Tekrarlanan sorular, terk edilen görüşmeler ve bir insanla görüşme talepleri.
• Müşteri sinyali: Görüşme incelemeleriyle birlikte yorumlanan geri bildirimler.
• Operasyonel güvenlik: Gizlilik olayları, yetkisiz veya tekrarlanan eylemler ve ciddi hatalar.
• İş sonucu: İlk görevle bağlantılı nitelikli talepler, rezervasyonlar veya çözülen istekler.

Trafiği artırmadan önce inceleme eşiklerini belirleyin. Kritik düzeyde tek bir veri sızıntısı bile yayını durdurmalıdır. Aynı politika etrafında kümelenen hatalı yanıtlar, ekibi bilgi kaynağına geri göndermelidir. Yüksek görev tamamlama oranı, güvenli olmayan eylemleri mazur göstermez.

30. günde üç seçenekten birini veriye göre seçin: kapsamı kademeli olarak genişletin, bilinen sorunları giderirken sınırlı pilotu sürdürün veya sistemi duraklatın. Açık kanıtlar, önceden belirlenmiş bir yayın tarihinden daha önemlidir.

İlgili yazı: Çok Dilli Yapay Zekâ Asistanları: Arapça, Türkçe ve İngilizce İçin Kapsamlı Rehber

30. gün yayın kontrolü

Asistanınız yalnızca aşağıdaki maddelerin tamamına “evet” diyebiliyorsanız kontrollü bir genel kullanıma hazırdır:

• İlk görev, hedef kitle, kapsam dışı konular, sorumlular ve başarı ölçütleri dokümante edildi.
• Onaylanmış bilgiler güncel, tekrarlarından arındırılmış ve sorumlulara atanmış durumda.
• Asistan kendisini açıkça tanıtıyor ve neler yapabileceğini doğru biçimde açıklıyor.
• Veri erişimi ve eylemler yalnızca gereken en düşük yetkiyi kullanıyor.
• Hassas veya önemli sonuçlar doğuran eylemler uygun doğrulama ya da onay gerektiriyor.
• Bir insandan yardım istemek kolay ve devirler yararlı bağlam içeriyor.
• Gerçek sorular, kötü niyetli senaryolar, entegrasyon hataları ve toparlanma yolları test edildi.
• Ekip görüşmeleri izleyebiliyor, eylemleri araştırabiliyor, değişiklikleri geri alabiliyor ve sistemi hızla devre dışı bırakabiliyor.
• Müşteriyle doğrudan çalışan ekipler asistanın nasıl çalıştığını ve olaylara kimin müdahale edeceğini biliyor.
• Kapsamın genişletilmesi proje planındaki bir tarihe değil, kalite ve güvenlik kanıtlarına bağlı.

30 gün ne zaman gerçekçidir, ne zaman değildir?

Kullanım senaryosu dar, gerekli bilgiler hazır, entegrasyonlar basit, karar vericiler erişilebilir ve ilk eylemler düşük riskliyse 30 gün ilk sürüm için yeterli olabilir. Aynı süre, içeriklerinizin veya süreçlerinizin henüz hazır olmadığını ortaya çıkarmak için de yeterlidir.

Yasal düzenlemelere tabi kararlar vermesi, yüksek tutarda para transfer etmesi, parçalı eski sistemlere erişmesi, oturmuş birden fazla iş akışının yerini alması ya da ilk günden birçok marka, ülke ve dilde çalışması beklenen bir asistan için 30 gün inandırıcı bir teslim tarihi değildir. Bu programlar daha kapsamlı güvenlik, gizlilik, hukuk, entegrasyon, yerelleştirme ve operasyon doğrulaması gerektirir. 30 günlük çalışma ritmini koruyun; ancak dönüşümün tamamlanmış gibi davranmak yerine bu sürede güvenli bir pilot veya hazırlık değerlendirmesi sunun.

En güvenilir asistan, en çok soruyu yanıtlayan değildir. Görevini bilen, güvenilir bilgi kullanan, açık sınırlar içinde hareket eden ve bir insana ihtiyaç duyulduğunda aradan çekilen asistandır.

Pratik bir başlangıç yapmak isterseniz Orbitra; ilk kullanım senaryosunu tanımlamanıza, bilgi altyapısını ve insana devir tasarımını hazırlamanıza, mevcut müşteri yolculuğunuza uygun kontrollü bir web sitesi asistanı geliştirmenize yardımcı olabilir. Hedef yalnızca çevrim içi görünen bir chatbot değil; ekibinizin açıklayabildiği, ölçebildiği ve sürekli iyileştirebildiği bir yayındır.