Kural tabanlı vs LLM sohbet botları: müşteri destek otomasyonu

Müşteri desteğinde hangi sorunu çözüyoruz?

Müşteri destek otomasyonunun pratik bir hedefi var: daha fazla müşteriye doğru şekilde, daha hızlı cevap verip ekibinizi yıpratmadan işinizi yürütmek. Bu, yazılımın hangi talepleri güvenle ele alabileceğine ve hangilerinin bir insana gitmesi gerektiğine karar vermeyi gerektirir.

Sohbet botları, müşterinin hedefi açıksa ve adımlar standartsa en iyi sonucu verir: sipariş durumu, çalışma saatleri, şifre sıfırlama, sevkiyat öncesi teslimat adresi güncelleme veya iade kurallarını açıklama gibi. Bunlar yüksek hacimli, tekrarlanabilir konuşmalar olup hızın benzersiz insan dokunuşundan daha önemli olduğu durumlardır.

Sorunlar, müşteri uç durumdaysa, politikaların istisnaları varsa veya durum yargı gerektiriyorsa başlar. Kendinden emin ama yanlış cevap veren bir bot size para (iade, chargeback), güven (kamusal şikâyetler) ve zaman (ajanların temizleme işi) kaybettirebilir. Bu yüzden kural tabanlı vs LLM tartışması önemlidir: aslında mesele gösterişli ifadeler değil, öngörülebilir sonuçlardır.

Tutarlılık, zekice cevaplardan daha önemlidir çünkü destek ürününüzün bir parçasıdır. Müşteriler kimi konuşurlarsa konuşsun aynı cevabı ister ve ajanlar botun kendi kurallarıyla uyumlu hareket etmesini bekler. Politikayı çiğneyen “yardımcı” bir cevap aslında yardımcı değildir.

Sorunu pratik şekilde çerçevelemek için botun her gün ne yapmasını istediğinize karar verin. Çoğu ekip için bu şunların bir karışımıdır: en sık tekrar eden istekleri uçtan uca çözmek, devretmeden önce doğru bilgileri toplamak, bekleme süresini azaltmak ama cevap kalitesinden ödün vermemek ve politika ile güncel ürün bilgisine bağlı kalmak.

Chatbotu tüm sürecin tamamı olarak değil, destek sürecinde bir adım olarak düşünün. İstediğiniz sonuç daha az ticket ve daha az hata, daha fazla konuşma değil.

Kural tabanlı ve LLM sohbet botları sade dille

Kural tabanlı vs LLM sohbet botları karşılaştırıldığında, insanlar ne söyleneceğine karar vermenin iki farklı yolunu tartışıyor.

Kural tabanlı bir chatbot bir senaryoyu takip eder. Niye(t)leri tanımlarsınız (müşterinin ne istediği, örn. “şifre sıfırla” veya “iade durumu”) ve her niyeti bir karar ağacına eşlersiniz. Bot bir soru sorar, cevabı kontrol eder ve bir sonraki adıma geçer. Sadece yazdıklarınızı söylediği için tahmin edilebilirdir.

LLM tabanlı bir chatbot daha esnek bir yazar gibidir. Müşterinin mesajını okur, konuşma bağlamını kullanır ve doğal dilde cevap üretir. Dağınık ifadelerle ve çok parçalı sorularla daha iyi uğraşır, ama ayrıca tahminde bulunabilir, fazla açıklama yapabilir veya sınırdan sapabilir; bunu engellemezseniz politika dışına kayabilir.

Hibrit kurulumlar yaygındır çünkü destek hem güvenlik hem de doğal dil gerektirir. Yararlı bir ayrım şöyle olabilir:

• Kurallar neyin izinli olduğunu belirler (uygunluk, iadeler, doğrulama adımları, gerekli ifade).
• LLM nasıl söyleneceğine yardımcı olur (ton, kısa açıklamalar, devretmeden önce vaka özeti).

Örneğin, kurallar bir siparişin iade penceresi içinde olduğunu doğrular, sonra LLM markanızın tonuna uygun dostane bir mesaj taslaklar.

Hızlı bir seçim yolu:

• Politika katı, hataların maliyeti yüksek ve sorular tekrarlıysa çoğunlukla kural tabanlı tercih edin.
• Sorular çeşitliyse, müşterilerin dili öngörülemezse ve eskalasyon netse çoğunlukla LLM tercih edin.
• Politikaya uygun cevaplar gerekli ama daha doğal bir konuşma da isteniyorsa ikisini birlikte kullanın.

Doğruluk: neler yanlış gider ve nasıl görünür

Destekte “doğruluk” sadece bir gerçeğin doğru olması demek değildir. Aynı anda üç şeyi ifade eder: cevap doğru olmalı, müşterinin gerçekten ihtiyacı olanı kapsamalı (yarım cevap değil) ve politika içinde kalmalıdır (iade kuralları, güvenlik sınırları, uyumluluk).

Kural tabanlı vs LLM sohbet botları genellikle farklı, öngörülebilir şekillerde başarısız olur.

Kural tabanlı botlar genellikle gerçeklikle karar ağacının uyuşmadığı yerlerde bozulur. Yeni bir soru dallanması yoktur, müşteri beklenmedik bir ifade kullanır veya bot yanlış niyeti seçer. Deneyim, alakasız kalıplaşmış yanıtlar, döngüsel menüler veya müşteri zaten sorunu açıklamış olsa bile "Lütfen bu seçeneklerden birini seçin" gibi çıktılar şeklinde olur.

LLM botlar güven konusunda hata yapma eğilimindedir. Politikayı tahmin edebilir, adımlar uydurabilir veya ürün detaylarını karıştırabilir. Deneyim daha kötü olur çünkü yardımsever gibi görünürken yanlış bilgi verir. Başka bir sorun da politika sürüklenmesidir: bot sohbetten sohbete farklı cevaplar verebilir, özellikle "nazik" olmaya çalışıp kuralları esnettiğinde (örneğin belirlenen pencerenin dışında iade teklif etmek).

Doğruluğu ölçmek için gerçek geçmiş ticketları kullanın ve sonuçları değerlendirin, hislere göre değil. Bir sohbet örneklemini etiketleyin ve takip edin:

• Doğru çözüm (müşterinin sorunu çözüldü mü?)
• Politika uyumu (bot izin verilmeyen bir şey vaat etti mi?)
• Eskalasyon oranı (gerekli olduğunda devretti mi?)
• 24–72 saat içinde yeniden iletişim oranı (müşteri tekrar döndü mü?)

Bazen en doğru cevap güvenli bir “Bilmiyorum”dur. Soru hesap erişimi, fatura istisnaları veya doğrulama gerektiren herhangi bir şeyi içeriyorsa, net bir devretme riskli bir tahminden iyidir. İyi bir bot sınırlarını bilir ve tam bağlamla müşteriyi doğru insana yönlendirir; bu güven kazandırır.

Bakım maliyeti: kurulum zamanı vs sürekli çaba

Kural tabanlı vs LLM sohbet botlarındaki en büyük maliyet farkı ilk kurulum değildir. Asıl fark ürününüz, fiyatlandırmanız ve politikalarınız değişmeye başladıktan sonra ortaya çıkar.

Kural tabanlı botlar daha fazla başlangıç maliyeti gerektirir çünkü akışları haritalamanız gerekir: niyetler, karar ağaçları, uç durumlar ve hangi tetikleyicilerin bir konuşmayı hangi yola göndereceğini belirlemek. Bu dikkatli bir iştir ama öngörülebilir davranış üretir.

LLM botlar genelde daha hızlı başlıyormuş gibi hissettirir; yardım merkezi veya dahili dokümanlara işaret edip talimatlar yazar, ardından gerçek sohbetlerden iyileştirirsiniz. Takas noktası ise sürekli kontrol ihtiyacıdır.

Zamanla iş yükü şu şekilde kayar:

• Kural tabanlı botlar bir şey değiştiğinde düzenleme ister (yeni bir sevkiyat düzeyi, yeniden adlandırılmış bir plan, iade politikasında yeni bir istisna).
• LLM botlar ise kaynakların (dokümanlar, hazır yanıtlar, ürün notları) ve kısıtların (talimatlar, siperler) bakımını, ayrıca cevapların hala politika ile uyumlu olup olmadığını düzenli olarak kontrol etmeyi gerektirir.

Bunu kim bakım yapıyor önemli. Kural sistemleri genellikle destek operasyonları ile ürün ekipleri arasında kesin kurallar sağlar; sonra biri değişiklikleri uygular ve test eder. LLM sistemleri, bilgi tabanı iyi sahiplenilmişse destek operasyonları tarafından daha fazla güncellenebilir, ama daha güvenli getirme, kayıt ve eskalasyon işlevleri için yine mühendislik gerekir.

Ekiplerin yayına almadan sonra gözden kaçırdığı maliyetler arasında politika değişikliklerinden sonra regresyon testleri, riskli cevapların izlenmesi, konuşmaların ton ve uyumluluk açısından incelenmesi ve yeni boşluklar ortaya çıktıkça kaynakların güncellenmesi bulunur.

Değişiklik sıklığı toplam maliyeti belirler. Politikalar haftalık değişiyorsa, katı bir karar ağacı hızla maliyetli olur. Politikalar nadiren değişiyor ama çok kesin olması gerekiyorsa (ör. garanti kuralları), kural tabanlı bir bot uzun vadede daha ucuz olabilir.

Cevapları politikaya uygun tutma

Bir destek botu ancak ajanlarınızın uyguladığı aynı kuralları takip ediyorsa "iyi" sayılır. Bot iade vaat ettiğinde, adresi değiştirdiğinde veya hesap bilgilerini politikanın izin vermediği şekilde paylaştığında güveni en hızlı kaybedersiniz.

Botun insan olmadan ne yapmaya izinli olduğunu yazmakla başlayın. Eylemlere odaklanın, konulara değil. "İadelerin nasıl çalıştığını açıklayabilir" ile "iadeyi gerçekleştirebilir" veya "aboneliği iptal edebilir" çok farklıdır. Botun değiştirebileceği şeyler (para, erişim, kişisel veri) ne kadar fazlaysa kurallar o kadar sıkı olmalı.

Politika metni ve hazır yanıtlar için tek bir doğruluk kaynağı kullanın. İade politikanız birden fazla doküman ve ajan notu arasında dağılıyorsa tutarsız cevaplar alırsınız. Onaylanmış metinleri bir yerde tutun ve her yerde yeniden kullanın (chat, e-posta, mesaj kanalları). Kural tabanlı ve LLM botlar burada ayrışır: kurallar kesin ifadeyi zorlar, LLM'lerin sapmaması için güçlü kısıtlamalar gerekir.

Politika dışına çıkmayı önleyen siperler

İyi siperler basit, görünür ve test edilebilir olmalıdır:

• Hassas konular için onaylanmış metin parçaları (iadeler, garantiler, chargeback, hesap erişimi)
• Yasaklanan iddialar (ör. "garantili teslimat tarihi" veya "anında iade")
• Zorunlu uyarılar (kimlik kontrolleri, işlem süreleri, uygunluk şartları)
• Herhangi bir işlemden önce botun toplaması gereken yapısal alanlar (sipariş ID, e-posta, son 4 hane)
• "Emin değilse eskale et" kuralı; erkenden tetiklenmeli

Sürümleme ve izlenebilirlik

Politikalar değişir. Onları yazılım gibi ele alın: sürümleyin ve hangi sürümün her cevap için kullanıldığını kaydedin. Müşteri geçen hafta botun ne dediğini itiraz ederse, botun hangi politika metnini takip ettiğini görmelisiniz.

Örnek: bir e-ticaret mağazası iade penceresini 30 günden 14 güne düşürür. Sürümleme ile bot tarihe göre cevap verebilir ve uç vakaları daha sonra denetleyebilirsiniz.

Müşterileri kızdırmayan eskalasyon akışları

Bir chatbotun değeri devrine bağlıdır. İnsanlar bir döngüde sıkıştıklarını hissettiğinde kanala güvenmeyi bırakırlar. Kural tabanlı mı yoksa LLM mi seçerseniz seçin, eskalasyonu deneyimin normal bir parçası olarak tasarlayın, başarısızlık gibi değil.

Sohbeti bir insana aktaracak net tetikleyicilerle başlayın, müşteriyi yalvarmaya zorlamadan. Yaygın tetikleyiciler: düşük güven, "iade", "chargeback", "hukuk" veya "iptal" gibi anahtar kelimeler, güçlü olumsuz duygu, ilerleme olmadan zaman sınırı veya aynı adımda birden fazla başarısız deneme.

Eskalasyon olduğunda müşterinin kendini tekrar anlatmasını istemeyin. Ajanlara sıkı bir bağlam paketi iletin:

• Sorunun kısa, sade bir özeti
• Bilinen müşteri bilgileri (isim, hesap, sipariş ID)
• Botun ne sorduğu ve kullanıcının ne cevapladığı
• Denenen adımlar ve sonuçları
• Paylaşılan dosyalar, ekran görüntüleri veya hata mesajları

Bir cümleyle beklenti koyun: sonraki adım ne ve yaklaşık ne kadar sürebilir. Örnek: "Bunu şimdi bir destek uzmanına gönderiyorum. Ortalama bekleme süresi yaklaşık 5 dakikadır. Buradan sohbet etmeye devam edebilirsiniz."

Devir işlemini tersine çevrilebilir yapın. Ajanlar genellikle rutin adımları (log toplama, temel sorun giderme, eksik bilgileri toplama) botun yapmasını isterken istisnalar üzerine yoğunlaşmak ister. Basit bir "müşteriye bot rehberliğinde kontrol listesi gönder" seçeneği zaman kazandırır ve hizmetin tutarlı kalmasını sağlar.

Son olarak, neden eskalasyon olduğunu takip edin. Her devretme sebebine etiket atın (düşük güven, politika talebi, kızgın müşteri, eksik veri) ve en önemli birkaçını haftalık gözden geçirin. Bu geri bildirim döngüsü botun riskli hale gelmeden iyileşmesini sağlar.

Adım adım: doğru chatbotu seçmek ve devreye almak

Kasıtlı olarak küçük başlayın. İlk önce birkaç tekrarlı soruyu otomatikleştirin, sonra gerçek transkriptlerle iyileştirin. Bu yaklaşım kural tabanlı mı yoksa LLM tabanlı mı seçerseniz seçin işe yarar; çünkü zor olan model değil, politika, devretme ve ölçüm kararlarıdır.

Pratik bir dağıtım planı

1. Düşük riskli, yüksek hacimli 3–5 ticket türü seçin. İyi başlangıçlar: sipariş durumu, şifre sıfırlama, mağaza saatleri ve iade politikası özetleri. Güven kazanana kadar para kaybına veya hesap değişikliğine yol açabilecek konulardan kaçının.

2. İnşa etmeden önce başarıyı tanımlayın. Haftalık izleyebileceğiniz 2–3 metrik seçin: insan yardımı olmadan çözüm oranı, sohbet sonrası CSAT ve her vardiya için ajan başına kurtarılan dakika gibi.

3. Politika kurallarını ve kısa bir "asla yapma" listesini yazın. Örnekler: doğrulanmamış adımı olmadan kimliği asla onaylama, göremediğiniz teslimat tarihlerini asla onaylama, tam kart numarası isteme.

4. Ana yolları ve gerçek bir geri dönüş (fallback) oluşturun. İdeal cevapları hazırlayın, sonra botın emin olmadığında kibar bir başarısızlık modu ekleyin: anladığını yeniden ifade etsin, bir netleştirici soru sorsun veya devretme teklif etsin. LLM kullanıyorsanız hassas konuları onaylanmış parçalara dayandırın.

5. Gerçek müşterilerle bir pilot çalıştırın, sonra genişletin. Kısıtlı tutun (bir kanal, bir ekip, bir hafta). Transkriptleri günlük inceleyin, hataları etiketleyin (yanlış niyet, eksik veri, politika riski), akışı güncelleyin ve yalnızca o zaman daha fazla konu ekleyin.

Yaygın hatalar ve kaçınılması gereken tuzaklar

Kural tabanlı vs LLM sohbet botlarını hayal kırıklığına uğratmanın en hızlı yolu onları aynı araç gibi değerlendirmektir. Farklı şekillerde başarısız olurlar, bu yüzden tuzaklar da farklıdır.

Yaygın bir hata, "botun ne yapması gerektiği" (politika) ile "nasıl söylemesi gerektiği" (ton) talimatlarını tek bir karışımda harmanlamaktır. Ton esnektir; politika değil. Politikayı net, test edilebilir kurallar (iade pencereleri, kimlik kontrolleri, asla vaat edilmemesi gerekenler) olarak tutun, sonra botun üzerine arkadaşça bir ses eklemesine izin verin.

Yüksek riskli bir başka tuzak, botun hesap-özgü sorulara sert bir kapı olmadan yanıt vermesine izin vermektir. Bir kullanıcı "Siparişim nerede?" diye soruyorsa bot tahmin etmemelidir. Doğru veri çekebilen güvenli bir sisteme doğrulama gerektirmeli veya devretmelidir.

Lansman öncesi şu kalıplara dikkat edin:

• Gerçek bir fallback yok, bot emin olmadığında tahmin yapmaya devam ediyor
• Yalnızca kibar, net sorular test edilmiş; sinirli veya belirsiz mesajlar atlanmış
• Bota istisnalar ve özel teklifler uydurma izni verilmiş
• İnsan incelemesi döngüsü yok, aynı hatalar tekrarlanıyor
• Tam transkripti ajana iletmiyor, müşteriyi tekrar anlatmaya zorluyor

Basit bir örnek: müşteri "Uygulamanız beni iki kez ücretlendirdi. Hemen düzeltin." yazarsa ve bot bu aciliyete hazırlıklı değilse genel bir fatura SSS'si ile yanıtlayabilir. Daha iyi olanı kısa bir özür, bir netleştirici soru (ödeme yöntemi ve zaman) ve net bir sonraki adım: doğru iş akışını başlatmak veya eskale etmektir.

Canlıya almadan önce hızlı kontrol listesi

Herkes için müşteri destek otomasyonunu açmadan önce, botu yeni bir destek temsilcisi gibi ele alın: eğitime, sınırlarına ve denetime ihtiyacı var. Bu, kural tabanlı mı yoksa LLM tabanlı mı seçerseniz seçin önlenebilir eskalasyonlar ve politika hatalarını engellemenin en hızlı yoludur.

• Yanıt kaynakları kilitli. Bot yalnızca onaylanmış politika içeriğinden (iade kuralları, gönderim süreleri, garanti şartları, güvenlik kuralları) yanıt verir. Eşleşme bulamazsa bunu söyler ve devretme önerir.
• Eskalasyon net ve her zaman mevcut. Tetikleyicileri tanımlayın (kızgın dil, hesap erişimi sorunları, ödeme uyuşmazlıkları, hukuki talepler, tekrar eden "bu yardımcı olmadı"). "Bir insanla konuş" seçeneğinin her noktada çalıştığından emin olun.
• Her konuşmayı denetleyebilirsiniz. Kullanıcı sorusunu, bot cevabını, kullanılan kaynakları (veya "yok") ve sonucu (çözüldü, eskalasyon, yarıda kaldı) saklayın.
• Haftalık inceleme alışkanlığınız var. İlk ay için en büyük başarısızlık kümelerini (yanlış politika, eksik cevap, anlaşılmaz dil, kötü yönlendirme) inceleyin ve test edilebilir düzeltmelere dönüştürün.
• Politika güncellemelerinin bir test planı var. Politika değiştiğinde kaynak içeriği güncelleyin ve küçük bir set must-pass sohbeti tekrar çalıştırın (iade talebi, adres değişikliği, teslimat gecikmesi, şifre sıfırlama, kızgın müşteri).

Gerçekçi bir örnek: bir e-ticaret destek sohbeti

Küçük bir e-ticaret markasını düşünün; en çok üç sohbet isteği var: "Siparişim nerede?", "Teslimat adresimi değiştirmem gerek" ve "İade istiyorum." Bu, kural tabanlı vs LLM sohbet botlarının çok pratik olduğu alanlardır.

Sipariş durumu için genellikle en güvenli ilk çözüm kural tabanlı bottur. Sipariş numarası ve e-posta ister, taşıyıcı durumunu kontrol eder, sonra tutarlı bir mesaj verir: mevcut konum, beklenen teslimat penceresi ve paket gecikirse ne yapılacağı. Tahmin yok.

Adres değişikliği de kuralların net olduğu için iyi bir kural tabanlı yoldur. Bot siparişin hala tamamlanmamış olup olmadığını kontrol eder, yeni adresi doğrular ve günceller. Sipariş zaten gönderildiyse durur ve doğru sonraki adımı sunar (taşıyıcıyla iletişim veya teslimattan sonra iade oluşturma).

LLM bot, müşterinin mesajı dağınık ya da duygusal olduğunda en çok yardımcı olur. Müşterinin ne istediğini yeniden ifade edebilir, eksik bilgileri toplayabilir ve ajana vaka özeti yapabilir. Ama amaç uzun konuşmalar değil; daha temiz bir devrettir.

İadeler, eskalasyon ve kontrollü ifade gerektiren alandır. Karar istisnalara veya kanıta bağlıysa bot eskale etmelidir: hasarlı ürünler (fotoğraf ister), "teslim edildi" taramasından sonra kaybolan paketler, politikanın dışındaki talepler, chargeback veya dolandırıcılık sinyalleri ve yüksek tutarlı siparişler.

Cevapların politika ile tutarlı kalması için son iade mesajını serbest metin olarak bırakmayın; kontrol edilen bir şablon olarak tutun. LLM yalnızca onaylanmış alanları (tarihler, sipariş ID, sonraki adımlar) doldursun, politika metni sabit kalsın.

Sonraki adımlar: uzun süre dayanan bir destek otomasyonu kurmak

Bir yüksek hacimli, düşük riskli destek alanı seçin (sipariş durumu, şifre sıfırlama, adres değişikliği) ve yalnızca onu otomatikleştirin. Hangi konuların gerçekten ticket azalttığına ve ajan zaman kazandırdığına göre genişletin.

Tercihinizi risk seviyesine göre yapın, tercihlerinize göre değil. Factual, politika ağırlıklı cevaplarda genellikle kurallar veya yapılandırılmış akışlar kazanır. "Sonraki ne yapmalıyım?" gibi dağınık sorularda LLM yardımcı olabilir, ama mutlaka siperlerle.

Birçok ekip hibrite karar verir: kesin olması gereken kısımlar için kurallar, metin oluşturma, özetleme ve yönlendirme için LLM.

Kanal boyunca tekrar kullanabileceğiniz basit bir kurulum planı:

• Sohbette net bir giriş (ne oldu, sipariş numarası, e-posta)
• Yönlendirme kuralları (faturalama, gönderim, teknik) ve insan devri seçeneği
• Hesap-özgü isteklere yönelik kimlik doğrulama kontrolleri
• Botun ne dediğini ve hangi veriyi kullandığını gösteren denetim kayıtları
• Hassas konular için onaylanmış şablonlar (iadeler, gizlilik, iptaller)

Eğer bu iş akışlarını her şeyi sıfırdan kurmadan uygulamak istiyorsanız, AppMaster (appmaster.io) veri modellemeye, görsel iş mantığı ile politika odaklı iş akışları kurmaya ve sohbet el devrini istekleri ve politika sürümlerini takip eden arka uç sistemlere bağlamaya yardımcı olabilir.