Yapay Zeka Chatbot Kurulumu ve Yönetimi Rehberi

Yapay zeka chatbot kurmak, “bir widget ekleyip modele birkaç doküman yüklemekten” ibaret değil. İyi kurgulanmış bir kurulum; niyet ayrımından kanal stratejisine, bilgi tabanından canlı temsilciye devre, KVKK’dan kalite güvenliğine kadar uçtan uca bir operasyon tasarımıdır. Yanlış tasarlanırsa maliyeti yükseltir, müşteri deneyimini bozar, ekibi daha çok yorar. Doğru tasarlanırsa destek yükünü azaltır, satış öncesi soruları hızlandırır ve 7/24 tutarlı yanıt üretir.

Bu rehber; e-ticaret yöneticileri, destek ekip liderleri, KOBİ sahipleri, ürün yöneticileri ve ajanslar için yazıldı. Amaç, “hangi botu seçeyim?” sorusunun ötesine geçip kurulum kapsamını, riskleri, ölçüm sistemini ve sürekli iyileştirme rutinini netleştirmek. Her bölüm, ileride ayrı bir destekleyici makaleye dönüşebilecek şekilde tasarlandı.

Table of Contents

• Niyet Ayrımı Kararı
• Chatbot Türü Seçimi
• Kullanım Senaryosu Tasarımı
• Kanal Entegrasyon Planı
• Bilgi Tabanı Kurulumu
• Diyalog Handoff Tasarımı
• KVKK Güvenlik Kontrolü
• Kalite Risk Yönetimi
• Metrik İzleme Kurulumu
• Sürekli İyileştirme Rutini

Niyet Ayrımı Kararı

Chatbot projelerinin büyük kısmı daha ilk haftada yanlış soruya cevap aradığı için zorlanır: “Hangi aracı alalım?” Doğru başlangıç sorusu şudur: Kurulumu hangi iş niyetiyle yapıyoruz ve kullanıcı hangi sohbet niyetiyle geliyor? Bu ayrımı netleştirmeden seçilen teknoloji, genelde ya fazla karmaşık ya da yetersiz kalır.

İşletme kurulum niyeti ile kullanıcı sohbet niyeti farkı

İşletmenin niyeti çoğunlukla operasyoneldir: destek maliyetini düşürmek, satış dönüşümünü artırmak, 24/7 kapsama sağlamak, ajanların yükünü azaltmak. Kullanıcının niyeti ise daha “anlık” ve bağlamsaldır: kargo nerede, iade nasıl, ürün uyumlu mu, ücret iadesi ne zaman, şifreyi unuttum.

Pratikte şu çakışma olur: İşletme “deflection” ister, kullanıcı “insanla konuşmak” ister. Bu yüzden ilk karar, sohbetin hangi anlarında otomasyonun iyi çalışacağıdır.

Uygulanabilir bir yöntem:

• Son 30 gün ticket/chat konularını çıkarın.
• İlk 10 konuyu “bilgi ile çözülebilir” ve “işlem gerektirir” diye ikiye ayırın.
• Bilgi ile çözülebilir olanları bot kapsamına aday yapın.
• İşlem gerektirenlerde botu “yönlendirici ve bağlam toplayıcı” rolüne koyun.

Bu ayrım, ileride kalite risklerini de düşürür. Çünkü modelin en çok halüsinasyon yaptığı yerler genelde “işlem ve istisna” alanlarıdır.

Canlı destek mi chatbot mu birlikte mi kararı

Karar, “ya o ya bu” olmak zorunda değil. Çoğu ekip için doğru kurgu birlikte çalışma modelidir. Üç seçenek net:

1. Sadece canlı destek

   • Avantaj: kalite kontrol kolay, istisnalar yönetilir
   • Dezavantaj: yoğun saatlerde kuyruk, maliyet artışı

2. Sadece chatbot

   • Avantaj: 7/24, ölçeklenir
   • Dezavantaj: güven sorunu, karmaşık işlemlerde tıkanma

3. Hibrit (önerilen)

   • Bot; karşılama, niyet yakalama, bilgi tabanı, basit işlemler
   • İnsan; ödeme, iade istisnası, şikayet, müşteri kaybı riski yüksek konular

Burada kritik eşik: devre (handoff) tasarımı. Bot devri düzgün yapmazsa hibrit model “iki kez anlatma” cezasına döner. Bu rehberde handoff’u ayrıca derinleştiriyoruz.

İlk kurulum için minimum kapsam seçimi

İlk kurulumda hedef, “her şeyi çözen bot” değil; ölçülebilir, sınırlı bir MVP olmalı. Minimum kapsamı seçerken şu çerçeveyi kullanın:

• 3–5 ana niyet: kargo takibi, iade-değişim, ödeme/teslimat, ürün bilgisi, üyelik
• 10–20 SSS cevabı: kısa, net, linkli
• 2 işlem akışı: sipariş sorgu yönlendirmesi, iade adımı yönlendirmesi (tam otomasyon değilse bile)

Zaman planı gerçekçi olmalı:

• Hazırlık ve içerik: 1–2 hafta
• Kurulum ve test: 1 hafta
• İlk canlıya alma: 1–3 gün kontrollü yayın

Bu yaklaşım, hem ekibi yormaz hem de ölçüm altyapısını erken kurmanıza izin verir. Daha geniş kapsamı “sürekli iyileştirme” ile büyütürsünüz.

Supporting Article Potential:

• Chatbot projesi için kapsam belirleme: MVP nasıl çıkarılır?
• Canlı destek ve chatbot birlikte nasıl çalışır? Operasyon modeli
• Niyet analizi: destek taleplerinden chatbot senaryosu üretme

Chatbot Türü Seçimi

“Yapay zeka chatbot” tek bir ürün tipi değil. Seçim; yanıt kalitesi, bakım maliyeti, entegrasyon ihtiyacı ve KVKK risk profilini doğrudan etkiler. Bu bölümde seçenekleri teknik terimlere boğmadan, karar vermeyi kolaylaştıracak şekilde ayırıyorum.

Kural tabanlı ve akış tabanlı seçenekler

Kural tabanlı botlar; butonlar, menüler, anahtar kelime eşleşmeleri ve if-else mantığıyla çalışır. Akış tabanlılar ise daha görsel bir “decision tree” gibi tasarlanır.

Ne zaman mantıklı?

• Süreç çok netse (iade adımları, kargo firması seçimi, çalışma saatleri)
• Risk toleransı düşükse (yanlış bilgi vermek büyük sorun yaratıyorsa)
• İçerik sık değişmiyorsa

Pratik artıları:

• Tahmin edilebilirlik yüksek
• Test etmek kolay
• Yasal ve marka dili kontrolü rahat

Eksileri:

• Serbest yazımda niyeti kaçırır
• Kapsam büyüdükçe bakım maliyeti artar
• Kullanıcı deneyimi “form doldurma” hissine kayabilir

Eğer ilk kurulumunuzda ekip olgunluğu düşükse, akış tabanlı bir iskelet genelde iyi bir başlangıçtır. Sonra LLM katmanı eklenebilir.

LLM tabanlı ve RAG tabanlı seçenekler

LLM tabanlı bot, büyük dil modeliyle serbest metin üretir. RAG (Retrieval-Augmented Generation) ise modeli, sizin bilgi kaynaklarınızdan “çektiği” içerikle yanıt üretmeye zorlar.

Kritik ayrım:

• “LLM tek başına” = model kendi bilgisiyle üretir, güncellik ve doğruluk riski artar.
• “LLM + RAG” = yanıtlar bilgi tabanına dayandırılır, kaynak gösterme mümkün olur.

RAG ne zaman şart?

• Ürün, fiyat, kampanya, iade politikası, teslimat süresi gibi değişken bilgiler varsa
• Çok sayıda içerik ve doküman yönetiyorsanız
• Temsilci devrinde doğru bağlam istiyorsanız

Bu noktada gerçekçi beklenti önemli: RAG iyi kurulduğunda bile arama kalitesi, doküman yapısı ve chunk stratejisi yanıt kalitesini belirler. “PDF yükledim, bitti” yaklaşımı genelde hayal kırıklığı üretir.

Resmi araç örnekleri:

• Google Cloud AI Chatbot use cases sayfası, kurumsal yaklaşımı görmek için iyi bir referans çerçevesi sunar.
• Genel amaçlı LLM arayüzleri (ör. ChatGPT) prototipleme için hızlıdır; üretim ortamı için veri ve denetim katmanları ayrıca tasarlanmalıdır.

Hibrit kurgu ve sınırları

Hibrit kurgu, çoğu ekipte en iyi sonuç veren modeldir:

• “Güvenli alanlar” akış/kural
• “Bilgi yoğun alanlar” RAG
• “Belirsiz niyetler” LLM sınıflandırma + yönlendirme

Sınırlar net çizilmezse hibrit sistem karmaşıklaşır. Şu iki kural işinizi kolaylaştırır:

• Kritik işlemi bot yapmasın, bot sadece hazırlasın: ödeme itirazı, iptal istisnası, kimlik doğrulama gerektiren talepler.
• Tek cevap kaynağı belirleyin: Kampanya metni hem sitede hem PDF’de hem Notion’da farklıysa, RAG doğruyu seçemez.

Bakım maliyeti açısından hibritin bedeli şudur: Akışlar için içerik sahibi, RAG için bilgi yöneticisi, kalite için inceleme rutini gerekir. Ekipte bu rolleri tanımlamadan “hibrit” demek genelde sürdürülemez.

Supporting Article Potential:

• RAG nedir, e-ticarette nasıl uygulanır?
• Kural tabanlı chatbot ne zaman daha iyi sonuç verir?
• Hibrit chatbot mimarisi: akış + LLM birlikte nasıl yönetilir?

Kullanım Senaryosu Tasarımı

Bu bölüm, “bot neleri yapacak?” sorusunu senaryo bazında netleştirir. Senaryo tasarımı iyi yapılırsa eğitim ihtiyacı azalır, kullanıcı memnuniyeti artar, temsilci devri daha az sürtünmeyle gerçekleşir.

E ticaret satış öncesi senaryoları

Satış öncesi, chatbotun en hızlı değer ürettiği alandır çünkü sorular tekrar eder ve yanıtlar çoğunlukla “bilgi” sınıfındadır.

Yüksek getirili senaryolar:

• Ürün karşılaştırma: “A ile B farkı ne?”
• Uyum soruları: “Bu kılıf iPhone 15’e olur mu?”
• Kargo ve teslimat: “Bugün sipariş versem ne zaman gelir?”
• Stok ve varyant: “M bedeni var mı?”
• Kampanya ve kupon: “Sepette indirim görünmüyor”

Uygulama detayı:

• Ürün sayfasında açılan widget, ürün ID’sini bota bağlamalı. Bot “hangi üründen bahsediyoruz?” diye sormamalı.
• Mesaj şablonları kısa olmalı. 2–4 satır idealdir.
• Satışa giden her yanıt bir “sonraki adım” içermeli: ürün linki, kategori linki, kargo sayfası, iade politikası linki.

Burada ölçülebilir bir hedef koyun: örneğin satış öncesi sohbetlerde tıklama oranı ve “sepete ekle” yönlendirmesi. Dönüşüm ölçümü için UTM ve event takibi şart.

Destek talepleri ve self servis senaryoları

Destek tarafında amaç, kullanıcıyı “bana yaz”dan “kendim çözerim”e taşımak. Ama bunu kaba bir şekilde yaparsanız CSAT düşer.

Self servis için iyi senaryolar:

• Sipariş durumu: kullanıcıdan sipariş no veya e-posta al, ilgili sayfaya yönlendir
• İade süreci: adım adım, doğru politika linkleriyle
• Fatura talebi: e-fatura/e-arşiv süreçleri
• Üyelik/şifre: sıfırlama linki ve güvenlik uyarıları
• Kargo hasarı: kullanıcıdan fotoğraf isteme yerine “kanıt listesi” ve temsilciye devre

İşlem gerektiren konularda botun rolü:

1. Niyeti netleştir
2. Minimum gerekli bilgiyi topla
3. Doğru ekrana, doğru kuyruğa devret

Toplanacak bilgi için sınır koyun. Genelde en fazla 3 alan yeter: sipariş no, e-posta/telefon, sorun tipi. Daha fazlası terk oranını artırır.

Ajans ve KOBİ için kapsamlandırma örnekleri

Ajanslar ve KOBİ’ler aynı hatayı yapıyor: “müşteri ne isterse ekleyelim.” Sonuç, bakımı yapılamayan bir senaryo yığını.

KOBİ için örnek kapsam (2–3 hafta):

• 5 niyet + 20 SSS
• Web widget + WhatsApp (sadece yönlendirme)
• Temsilci devri + basit raporlama

Ajans için örnek kapsam (4–6 hafta):

• 8–12 niyet
• RAG bilgi tabanı + kaynak linkleme
• CRM/Helpdesk entegrasyonu (en azından ticket açma)
• Rol bazlı panel erişimi ve onay akışı

Kapsam dokümanı önerisi (tek sayfa):

• Hedefler: 3 madde
• Kapsam içi / kapsam dışı
• Handoff kuralları
• Ölçülecek metrikler
• Yayın planı: kontrollü rollout

Bu doküman, proje uzadığında sizi “sonsuz istek” döngüsünden korur.

Supporting Article Potential:

• E-ticaret chatbot senaryoları: satış öncesi 10 hazır akış
• Self servis tasarımı: botla destek yükü nasıl azaltılır?
• Ajanslar için chatbot proje kapsam şablonu ve fiyatlama mantığı

Kanal Entegrasyon Planı

Kanal stratejisi “nerede görünelim?” sorusundan çok, “hangi kanalda hangi deneyimi vaat ediyoruz?” sorusudur. Web widget’ında hızlı form toplamak kolaydır. WhatsApp’ta aynı şeyi yaparsanız kullanıcı tersler. Bu farkları baştan planlayın.

Web canlı chat ve widget kapsamı

Web canlı chat, bot için en kontrol edilebilir alandır:

• Kimlik bağlamı: oturum, sepet, ürün sayfası
• UI kontrolü: butonlar, quick reply, form alanları
• Event takibi: tıklama, dönüşüm, sayfa akışı

Minimum widget kapsamı:

• Açılış mesajı + 3 hızlı seçenek (satış, sipariş, iade)
• Arama kutusu davranışı (serbest yazım)
• Handoff butonu (görünür olmalı)
• Çalışma saatleri mantığı (mesai dışı farklı akış)

Performans tarafı:

• Widget script’i sayfayı şişirmemeli. Görseller 200KB altı, WebP tercih.
• Sayfa açılış süresi hedefi 2.5 saniye altı. Widget gecikmeli yüklenebilir.

Web için iyi bir başlangıç noktası, canlı destek sistemleri ve kurulum yazılarıdır. Bu konularda pratik içeriklere Canlı Destek Blog üzerinden (özellikle blog sayfasından) ulaşmak işinizi hızlandırır.

WhatsApp Instagram Messenger gerçekleri

Bu kanallar “chat” gibi görünür ama operasyonu farklıdır:

• Kullanıcı daha kısa yazar, daha sabırsızdır.
• Onaylı mesaj şablonları, oturum pencereleri gibi sınırlamalar olabilir.
• Medya (görsel, ses) gelir, sınıflandırma ihtiyacı artar.

Gerçekçi kullanım:

• WhatsApp’ta botu tam otomasyon yerine “yönlendirme + triage” için kullanmak genelde daha iyi çalışır.
• Instagram DM’de satış öncesi sorular güçlüdür, ama ürün kataloğu ve stok bağlamı yoksa bot sık sık “link atma makinesi” olur.

Kanal bazlı karar kuralı:

• Eğer temsilci ekibiniz aynı panelden çok kanalı yönetemiyorsa, entegrasyon eklemek yükü artırır.
• İlk aşamada 1 ana kanal + 1 ikincil kanal seçin. Hepsini aynı anda açmayın.

Araç seçerken resmî sayfaları inceleyin. Örneğin novaapp.ai gibi çözümler WhatsApp odaklı akışlar sunabilir; ama KVKK, veri saklama ve log erişimi tarafını ayrıca doğrulamak gerekir.

Sesli kanal olasılıkları ve sınırlar

Sesli botlar cazip görünür; pratikte maliyet ve hata payı daha yüksektir. Sınırlar:

• ASR (speech-to-text) hataları, özellikle isim, adres, sipariş no’da artar
• Kimlik doğrulama zorlaşır
• Kullanıcı “tekrar et” döngüsüne girerse memnuniyet düşer

Yine de iki durumda mantıklı olabilir:

• Çağrı merkezinde basit yönlendirme (IVR yerine)
• Mesai dışı “kayıt alma” (konu, sipariş no, geri arama talebi)

Sesli kanal düşünüyorsanız, önce yazılı kanalda niyet setinizi oturtun. Ses, üzerine eklenen bir katman olmalı; ilk adım değil.

Supporting Article Potential:

• Web chatbot widget’ı için UX kontrol listesi
• WhatsApp chatbot kurulumu: beklentiler, sınırlamalar, iyi pratikler
• Sesli bot ne zaman mantıklı? Çağrı merkezi için karar çerçevesi

Bilgi Tabanı Kurulumu

Bilgi tabanı, yapay zeka chatbot projesinin “görünmeyen altyapısıdır”. Kötü bilgi tabanı, en iyi modeli bile kötü konuşturur. İyi bilgi tabanı ise temsilci eğitimini azaltır, müşteri deneyimini tutarlı yapar.

Kaynak seçimi ve içerik hazırlığı

Başlangıçta “her şeyi indeksleyelim” dürtüsüne direnin. Kaynakları seçerken üç kriter kullanın: doğruluk, güncellik, sahiplik.

Önerilen kaynak önceliği:

1. Resmî politika sayfaları (iade, teslimat, KVKK aydınlatma)
2. SSS sayfaları
3. Ürün içerikleri (özellik, uyumluluk, bakım)
4. Dahili dokümanlar (temsilci makroları, süreç dokümanları)

İçerik hazırlığında pratik kurallar:

• Her cevap 1 ana mesaj + 1 kanıt linki içersin.
• Paragraflar kısa olsun. 2–4 satır.
• Tarih hassas içeriklerde “son güncelleme” alanı kullanın.
• Çelişen içerikleri tekleştirin. Aynı konunun 3 farklı versiyonu RAG’i bozar.

Sık yapılan hata: PDF katalogları olduğu gibi yüklemek. PDF’ler çoğu zaman tablo ve görsel ağırlıklıdır; parçalanınca anlam kaybeder. Kritik bilgileri düz metin makaleye çevirin.

RAG ile güncel bilgi sunma

RAG’in başarısı üç şeye bağlıdır: parçalama (chunk), arama (retrieval), yanıt şablonu.

Uygulanabilir ayarlar (başlangıç için):

• Chunk boyutu: 300–700 kelime aralığında deneyin
• Overlap: %10–20
• Top-k: 3–5 kaynak parçası

Yanıt politikası net olmalı:

• Bot, kaynak bulamazsa uydurmasın.
• Bulduğu kaynakları linklesin.
• Belirsizse kullanıcıya 1 net soru sorsun.

Örnek güvenli davranış:

• “Bu kampanya şu an geçerli mi?” sorusunda bot; kampanya sayfası kaynak değilse “kampanya sayfasına yönlendireyim” demeli, tarih uydurmamalı.

RAG’i canlıya almadan önce test seti hazırlayın:

• En az 30 soru: kolay, orta, zor
• 10 soru: kapsam dışı
• 5 soru: kasıtlı yanıltıcı (farklı marka, farklı ürün)

Bu test seti, ileride kalite rutininde tekrar kullanılacak.

Araç kullanımı ve sistem entegrasyonları

Bilgi tabanı tek başına yetmez; bazı sorular “bilgi” değil “durum” ister. Entegrasyon burada devreye girer: sipariş durumu, stok, kargo, iade kaydı.

Entegrasyon seviyeleri:

• Seviye 1: link ile yönlendirme (en hızlı)
• Seviye 2: form ile bilgi toplayıp ticket açma
• Seviye 3: API ile gerçek zamanlı sorgu (en değerli, en riskli)

Başlangıç için çoğu ekipte Seviye 2 iyi dengedir. Seviye 3’e geçerken şunları şart koşun:

• Rate limit ve hata senaryoları (API yanıt vermezse ne olacak?)
• Loglama (hangi kullanıcı için hangi çağrı yapıldı)
• Yetki kontrolü (sipariş bilgisi herkese gösterilmesin)

Araç seçimi yaparken “entegrasyon pazarı”na bakın ama söz verilen her konektörün üretimde aynı çalışmadığını bilin. Pilot yapmadan geniş kapsamlı bağlanmayın. Bu tür karşılaştırma ve kurulum odaklı içerikleri düzenli takip etmek için Canlı Destek Blog iyi bir referans havuzu.

Supporting Article Potential:

• RAG bilgi tabanı nasıl hazırlanır? Chunk ve kaynak stratejisi
• PDF’ten bilgi tabanına: chatbot için içerik dönüştürme rehberi
• Chatbot entegrasyon seviyeleri: link, ticket, API arasında seçim

Diyalog Handoff Tasarımı

Chatbotun gerçek başarısı, “insana devretmesi gerektiği anı bilmesi” ile ölçülür. Handoff tasarımı yoksa bot ya fazla erken devreder (değer üretmez) ya da fazla geç devreder (müşteriyi sinirlendirir). İkisi de kötü.

Karşılama ve niyet yakalama akışı

Karşılama mesajı, marka dili kadar operasyonu da taşır. İyi karşılama:

• Ne yapabildiğini söyler
• Kullanıcıyı seçeneklere iter
• Serbest yazımı da açık bırakır

Örnek yapı:

1. Tek cümle karşılama
2. 3 hızlı seçenek
3. “Temsilciye bağlan” seçeneği (saklamayın)

Niyet yakalama için pratik yaklaşım:

• İlk mesajdan sonra sınıflandırma yapın.
• Emin değilseniz 1 soru sorun, anket gibi 5 soru sormayın.
• Niyet eşleşmesi düşükse “hangi konuda yardımcı olayım?” menüsüne dönün.

Burada kritik metrik: ilk 2 mesajda niyet yakalama oranı. Yakalanmıyorsa ya seçenekler yanlış ya da kullanıcı dili farklıdır.

İnsan devri tetikleyicileri

Handoff tetikleyicileri “duyguya” göre değil, kurala göre çalışmalı. Net tetikleyici seti belirleyin:

Zorunlu handoff örnekleri:

• Ödeme sorunu, chargeback, dolandırıcılık şüphesi
• Kişisel veri değişikliği (adres, telefon) doğrulama gerekiyorsa
• Şikayet ve memnuniyetsizlik sinyali (küfür, “tüketici hakem heyeti” gibi)
• 2 kez üst üste “çözememe” (bot aynı tip yanıt veriyorsa)

Ayrıca kullanıcı tercihi:

• Kullanıcı “temsilci” diyorsa, ısrar etmeyin. İkinci kez engellemeyin.

Mesai dışı tetikleyici:

• Temsilci yoksa “ticket açma + geri dönüş süresi” net verilmeli. Belirsiz vaat CSAT’i düşürür.

Canlı destek ekip ekranı için gerekli bağlam

Devredilen konuşmanın temsilci paneline “boş” düşmesi, hibrit modelin en büyük hatasıdır. Temsilciye şu bağlamlar gitmeli:

• Kullanıcının yazdığı son 10 mesaj
• Botun tespit ettiği niyet ve güven skoru (varsa)
• Toplanan alanlar: sipariş no, e-posta, konu seçimi
• Kullanıcının bulunduğu sayfa / ürün
• Botun önerdiği makaleler ve tıklanma durumu

Bu bağlamla birlikte temsilci, sohbeti 15 saniyede toparlar. Bağlam yoksa kullanıcı her şeyi tekrarlar, AHT uzar.

Operasyon detayı: Temsilci ekranında 3 hazır makro ekleyin:

1. “Bilgileri aldım, kontrol ediyorum”
2. “Şu adımları denediniz mi?”
3. “Süreci başlattım, tahmini süre…”

Bu, botun açtığı bağlamı temsilcinin hızlı kullanmasını sağlar.

Supporting Article Potential:

• Chatbot handoff tasarımı: tetikleyiciler ve en iyi pratikler
• Temsilci paneli bağlamı: bot devrinde hangi veriler taşınmalı?
• Karşılama mesajı ve niyet yakalama: örnek akışlar ve metinler

KVKK Güvenlik Kontrolü

KVKK ve güvenlik, chatbot projelerinde “sonradan eklenen checklist” olmamalı. Çünkü sohbet verisi; kişisel veri, ödeme bilgisi, adres gibi hassas alanlara hızlıca kayar. En iyi tasarım, veriyi toplamamaktır. Toplamanız gerekiyorsa da kontrollü toplamaktır.

Veri minimizasyonu ve açık rıza noktaları

Veri minimizasyonu basit bir prensip: İhtiyacın yoksa sorma. Bot akışlarını incelerken şu soruyu sorun: “Bu alan olmadan da çözüm üretebilir miyim?”

Pratik kurallar:

• Sipariş sorgusu için çoğu zaman sipariş no + e-posta yeter.
• TCKN, doğum tarihi gibi alanları bot üzerinden istememeye çalışın.
• Serbest metinde kart bilgisi yazılmasını engellemek için uyarı ekleyin: “Kart bilgisi paylaşmayın.”

Açık rıza konusu, senaryoya göre değişir. Bazı durumlarda aydınlatma metni yeterlidir; bazı durumlarda açık rıza gerekir. Hukuk ekibinizle şu noktaları netleştirin:

• Sohbet kaydı hangi amaçla tutuluyor?
• Eğitim/iyileştirme için kullanılacak mı?
• Üçüncü taraf sağlayıcıya aktarım var mı?

Bu metinleri widget içinde görünür kılın. Kullanıcıya “okumadan geç” yaptırmak yerine, kritik noktaları 1–2 cümleyle özetleyin.

Veri saklama ve erişim yetkileri

Saklama süresi belirsiz bırakılırsa risk büyür. Operasyonel olarak bir politika belirleyin:

• Sohbet logları: örneğin 90–180 gün aralığında tutma (iş ihtiyacına göre)
• Ticket’a dönüşen kayıtlar: helpdesk politikasına göre
• Silme talepleri: süreç sahibi ve SLA

Erişim yetkisi:

• Her temsilci tüm logları görmemeli.
• Yönetici, kalite, hukuk gibi roller ayrılmalı.
• Dış ajans erişiyorsa, sadece ilgili projeyle sınırlanmalı.

Bu noktada “kim, neyi, ne zaman gördü?” sorusuna cevap verecek audit log ihtiyacı doğar. Sağlayıcı seçiminde bu detaylar sözleşmeden önce konuşulmalı.

Üçüncü taraf sağlayıcı riskleri

Chatbot sağlayıcısı seçerken sadece fiyat ve özellik değil, veri işleme modeli de kritik:

• Veri nerede barınıyor?
• Model eğitimi için kullanılıyor mu?
• Alt işlemciler kimler?
• Silme talebi nasıl uygulanıyor?

Pratik kontrol listesi:

• DPA (Data Processing Agreement) var mı?
• Veri şifreleme (at-rest ve in-transit) taahhüdü var mı?
• Tenant izolasyonu nasıl?
• Log dışa aktarma mümkün mü?

Bu soruların net yanıtı yoksa, “sonra bakarız” demeyin. Sonra bakınca genelde geç kalınmış olur.

Supporting Article Potential:

• KVKK uyumlu chatbot tasarımı: veri minimizasyonu nasıl yapılır?
• Chatbot sağlayıcısı seçerken güvenlik soruları (DPA, audit, silme)
• Sohbet log saklama politikası: süre, erişim ve süreç tasarımı

Kalite Risk Yönetimi

Yapay zeka chatbot projelerinde kalite; sadece “doğru cevap verdi mi?” değildir. Ton, belirsizlik yönetimi, kapsam dışı güvenliği ve temsilci devrine etkisi de kalite kapsamındadır. Burada amaç “sıfır hata” değil, hata olduğunda güvenli davranış tasarlamaktır.

Yanlış cevap ve halüsinasyon riskleri

Halüsinasyon riskini azaltmak için üç katman kullanın:

• Kapsam sınırı: botun cevap vermeyeceği alanlar
• Kaynak zorunluluğu: RAG yoksa kritik konularda yanıt verme
• Şablon yanıt: belirsizse soru sor ya da devret

Pratik önlemler:

• Politika, kampanya, fiyat gibi alanlarda “kaynak yoksa yanıt yok” kuralı koyun.
• Yanıtta “kesin” dilini azaltın. “Genelde”, “şu sayfaya göre” gibi çerçeveleyin.
• Kullanıcıyı yanlış yönlendirecek varsayımlardan kaçının.

Test yaklaşımı:

• En çok gelen 50 soruyu düzenli test edin.
• Her sürümde aynı test setini çalıştırın.
• Yanıtları “doğru/yanlış” dışında “riskli” diye de etiketleyin.

Burada hedef, riskli yanıtların oranını düşürmek. Çünkü riskli yanıtlar, iade/ödeme gibi alanlarda maliyet üretir.

Kapsam dışı sorular için güvenli yanıt

Kapsam dışı yanıt tasarımı, botun itibarını belirler. “Bilmiyorum” tek başına kötü durur. Daha iyi formül:

1. Kapsamı söyle (kısa)
2. Alternatif sun (link, temsilci, form)
3. 1 net soru sor (gerekliyse)

Örnek:

• “Bu konuda net bilgi veremiyorum. İstersen seni temsilciye bağlayayım veya iade politikası sayfasını paylaşayım. Sipariş numaran var mı?”

Kapsam dışı listesi oluşturun:

• Hukuki danışmanlık
• Tıbbi iddialar
• Rekabet karşılaştırması (marka riskine göre)
• Kişisel veri talepleri (kimlik doğrulama yoksa)

Bu liste, hem akışlarda hem LLM politika katmanında yer almalı.

İnceleme süreçleri ve onay mekanizması

Kaliteyi sürdürülebilir kılan şey “onay mekanizmasıdır”. Özellikle kampanya dönemlerinde içerik hızlı değişir.

Önerilen süreç:

• Haftalık kalite toplantısı: 30–45 dakika
• Rastgele 20 sohbet örneği inceleme
• 5 kritik hata sınıfı: yanlış politika, yanlış yönlendirme, kötü ton, gereksiz veri isteme, geç handoff

Onay mekanizması:

• Bilgi tabanı değişiklikleri için en az 1 onaylayıcı belirleyin.
• Kampanya metinleri için pazarlama onayı şart olsun.
• KVKK metinleri için hukuk onayı gerekebilir.

Bu süreçler “yavaşlatır” gibi görünür ama uzun vadede destek yükünü azaltır. Kontrolsüz bot, temsilcinin hatayı düzeltmesiyle daha çok zaman yer.

Supporting Article Potential:

• Halüsinasyon riskini azaltma: RAG ve politika katmanı pratikleri
• Kapsam dışı güvenli yanıt şablonları (e-ticaret için)
• Chatbot kalite inceleme süreci: haftalık rutin nasıl kurulur?

Metrik İzleme Kurulumu

Ölçemediğiniz şeyi yönetemezsiniz; chatbotta bu daha da sert. Çünkü “konuşuyor gibi görünür” ama işe yarayıp yaramadığını anlamak için doğru metrik seti gerekir. Üstelik metrikler kanal bazında farklı davranır.

CSAT deflection AHT dönüşüm metrikleri

Çekirdek metrik seti:

• CSAT: sohbet sonrası memnuniyet (tek soru bile yeter)
• Deflection: temsilciye gitmeden çözülen oturum oranı
• AHT: temsilciye devredilenlerde ortalama işlem süresi
• Conversion etkisi: satış öncesi sohbetlerden ürün tıklaması / sepete ekleme / satın alma

Burada en kritik nokta: Deflection tek başına başarı değildir. Deflection artarken CSAT düşüyorsa, bot “kaçırıyor” demektir.

Başlangıç hedefleri (sektöre göre değişir, ama mantık için):

• İlk ay: CSAT’ı koru, deflection’ı agresif zorlamadan ölç
• 2–3 ay: deflection’ı artır, AHT’yi düşürmeye odaklan
• 3–6 ay: dönüşüm etkisini netleştir (özellikle satış öncesi)

Etki penceresi gerçekçi olmalı: SEO gibi burada da optimizasyon sonuçları 3–6 ay içinde netleşir. İlk hafta mucize beklemeyin.

Kanal bazlı raporlama ihtiyaçları

Tek bir dashboard çoğu zaman yanıltır. Kanal bazında ayrı bakın:

Web:

• Oturum başlatma oranı
• Ürün sayfası bağlamıyla çözüm oranı
• Tıklama ve event’ler

WhatsApp/DM:

• İlk yanıt süresi (otomasyon varsa çok düşer)
• Mesaj sayısı (uzarsa sürtünme var)
• Handoff sonrası kapanma oranı

Canlı destek:

• Devredilen konuşmalarda AHT
• Temsilci notları (konu etiketleri)
• Yeniden açılma oranı

Raporlama ritmi:

• Günlük: kritik hata ve şikayet taraması
• Haftalık: niyet dağılımı, başarısız aramalar
• Aylık: kapsam genişletme kararları

Loglama ve izlenebilirlik gereksinimleri

Kalite ve KVKK için loglama iki ucu keskin bir kılıçtır: gerekli ama kontrollü olmalı.

İzlenebilirlik için minimum gereksinimler:

• Her oturum için tekil ID
• Niyet sınıflandırma sonucu (varsa)
• Kullanılan kaynaklar (RAG’de hangi dokümanlar çekildi)
• Handoff oldu mu, ne zaman oldu?
• Kullanıcı geri bildirimi (thumbs up/down, CSAT)

Bu loglar, “neden yanlış cevap verdi?” sorusunu yanıtlar. Kaynak görünürlüğü yoksa hatayı düzeltmek kör uçuş olur.

Dışa aktarma:

• En azından CSV/JSON export olmalı.
• BI aracı kullanıyorsanız (Looker, Power BI vb.) düzenli akış planlayın.

Bu bölümde sık yapılan hata: Her şeyi loglayıp kimse bakmamak. Logların sahibi ve inceleme ritmi tanımlanmalı. Aksi halde sadece risk biriktirirsiniz.

Supporting Article Potential:

• Chatbot KPI seti: CSAT, deflection ve dönüşüm birlikte nasıl okunur?
• Kanal bazlı chatbot raporlama şablonu (web vs WhatsApp)
• RAG izlenebilirliği: kaynak logları neden şart?

Sürekli İyileştirme Rutini

Chatbot “kurulur ve biter” değil. Ürün gibi yönetilir. Bu rutini kurmazsanız 2 ay sonra bot eskir, yanlış yanıtlar artar, ekip güvenini kaybeder. İyi haber: Düzenli küçük iyileştirmeler, büyük revizyondan daha ucuzdur.

Haftalık hata analizi ve düzeltme döngüsü

Haftalık döngü için pratik bir sistem:

1. En çok kullanılan 10 niyeti çıkar
2. Her niyetten 5 konuşma örneği seç (toplam 50)
3. Hataları etiketle: bilgi yanlış, bağlam eksik, ton, geç handoff, kapsam dışı
4. Her hata için aksiyon yaz: içerik güncelle, akış düzelt, tetikleyici ekle
5. 1 hafta içinde kapanacak 5 işi seç, geri kalanı backlog’a al

Burada disiplin önemli. “Hepsini düzeltelim” derseniz hiçbirini bitiremezsiniz.

Hızlı kazançlar genelde şunlardan gelir:

• Yanıtlara doğru link eklemek
• Kullanıcıdan gereksiz bilgi istemeyi kaldırmak
• Handoff’u 1 adım öne çekmek (özellikle şikayetlerde)

Bilgi tabanı güncelleme ritmi

Bilgi tabanı güncellenmezse RAG yanıltır. Güncelleme ritmi içeriğin hızına göre değişir:

• Kampanya yoğun e-ticaret: haftalık kontrol
• B2B SaaS yardım merkezi: 2 haftada bir
• Sabit politikalar: aylık gözden geçirme

Uygulama detayı:

• Her makaleye sahip atayın (owner).
• “Son güncelleme” alanı koyun.
• Eski linkleri tarayın (404 kontrolü).

İçerik tazeleme döngüsü olarak 12–18 ay iyi bir genel periyottur; ama kampanya ve fiyat gibi alanlar daha sık ister. Burada tek doğru yok, iş modeline göre ayarlayın.

Yeni senaryo ekleme ve kapsam genişletme

Kapsamı büyütürken “metrikle kanıt” kuralı koyun. Yeni senaryo eklemek için üç tetikleyici:

• Aynı konu haftalık raporda sürekli çıkıyorsa
• Temsilciye devrin büyük kısmı aynı niyetten geliyorsa
• Kullanıcılar aynı soruda botu terk ediyorsa

Kapsam genişletme adımları:

1. Niyet tanımı yaz (1 paragraf)
2. Başarı kriteri koy (ör. deflection + CSAT eşiği)
3. Bilgi kaynağını belirle
4. Handoff kuralını yaz
5. Test setine 10 soru ekle
6. Kontrollü yayınla (trafik %10 → %50 → %100)

Bu rollout yaklaşımı, ani kalite düşüşlerini yakalamanızı sağlar.

Son olarak: İyileştirme rutini için bir iletişim kanalı açın. Temsilciler, botun nerede saçmaladığını en hızlı gören kişilerdir. Onlardan gelen geri bildirimi bir form veya kısa etiket sistemiyle toplayın. Gerekirse iletişim sayfanız üzerinden iç ekip taleplerini bile yönetecek basit bir akış kurabilirsiniz.

Supporting Article Potential:

• Chatbot için haftalık kalite ve iyileştirme ritmi (örnek ajanda)
• Bilgi tabanı sahipliği: içerik owner modeli nasıl kurulur?
• Kapsam genişletme playbook’u: yeni senaryo canlıya alma kontrol listesi