Senaryo Seçim Kriterleri
Yapay zeka chatbot kurulumunda en çok hata, “bot kuralım” ile başlayıp senaryoyu sonra düşünmek. Oysa canlı destek tarafında işe yarayan botlar, net bir niyet ve ölçülebilir iş sonucu ile başlar. Buradaki hedef, herkese her şeyi yapan bir bot değil; belirli temasları hızlı, tutarlı ve denetlenebilir biçimde çözmek.
Hedef niyet ve iş sonucu tanımı
Senaryoyu “kullanıcı ne istiyor?” sorusuna tek cümleyle bağlayın. Niyet belirsizse bot da belirsiz yanıt verir.
Pratik şablon:
- Niyet: “Kargom nerede?”
- İş sonucu: “Kargo takip linkini ve son durumunu 30 saniye içinde göstermek”
- Kapsam dışı: “Adres değişikliği” (handoff)
Bu yaklaşım, botun konuşma tasarımını ve hangi entegrasyonların şart olduğunu belirler.
Girdi ve çıktı örnekleri
Her senaryoda 5–10 gerçek kullanıcı mesajı toplayın (WhatsApp, web chat, e-posta). Sonra her birinin “ideal bot çıktısını” yazın.
İyi çıktı tanımı şunları içerir:
- Kullanıcıya sorulacak minimum ek bilgi (ör. “sipariş no”)
- Net aksiyon (link, durum, adım listesi)
- Güvenlik notu (gerekirse kimlik doğrulama)
Bu küçük liste, model seçimini ve test planını ciddi hızlandırır.
Entegrasyon noktası kontrolü
“Bot cevaplar” demek yetmez; çoğu senaryoda botun bir yerden veri çekmesi gerekir. Başlamadan önce şu kontrolü yapın:
- Veri nerede? (CRM, OMS, kargo sağlayıcı, yardım merkezi)
- Erişim nasıl? (API, webhook, CSV export)
- Gecikme toleransı nedir? (anlık mı, 15 dk mı)
- Yetki modeli nasıl? (temsilci gibi mi, kullanıcı gibi mi)
Entegrasyon yoksa, bot tahmin yapmaya başlar. Canlı destekte bu, yanlış yönlendirmeye hızlı gider.
Başarı metriği ve hedef değer
Senaryo başına tek bir “ana metrik” seçin, yanına 1–2 destek metriği ekleyin. Örnek:
- Ana metrik: self servis çözüm oranı
- Destek: ortalama yanıt süresi, handoff oranı
Hedef değerleri gerçekçi koyun. İlk 4–6 haftada %80 self servis hedeflemek çoğu ekipte hayal kırıklığı yaratır; önce %20–40 bandını stabil hale getirmek daha sağlıklı.
Türkiye e ticaret ve KOBİ örneği
Türkiye’de e-ticaret KOBİ’lerinde en hızlı geri dönüş veren senaryolar genelde şunlar:
- Sipariş/kargo sorgusu (yüksek hacim, net veri)
- İade/değişim (politika + RMA adımı)
- Ürün uygunluk soruları (katalog + stok)
Eğer ekibiniz 2–5 temsilciyse, botu “temsilciyi azaltma” yerine yoğun saatleri dengeleme aracı gibi kurgulamak daha az riskli olur. İhtiyaç duyarsanız Canlı Destek Blog içindeki canlı destek kurulumu ve yönetimi rehberi operasyon tarafında iyi bir başlangıç sağlar.
Bot Türü Eşleştirmesi
Her “yapay zeka chatbot” aynı değil. Senaryonun ihtiyacı, bot türünü belirler. Yanlış eşleşme genelde iki şeye yol açar: ya bot boş konuşur ya da gereksiz pahalı/karmaşık hale gelir. Aşağıdaki şablonlar, hızlı karar vermek için.
Destek botu uygunluk şablonu
Destek botu, akış bazlı ve kural + AI karışımı çalışır. Şunlar uygunsa doğru seçimdir:
- Niyetler az ve tekrar eden (kargo, iade, fatura)
- Birkaç net soru ile çözüm çıkıyor
- Handoff sık yaşanacak ama kontrollü
Destek botu için en kritik konu: fallback metni ve devre kuralları. Bot “emin değilim” dediğinde kullanıcıyı oyalamamalı.
Bilgi botu RAG uygunluk şablonu
RAG (retrieval augmented generation) bilgi botu, içerikten yanıt üretir. Şunlarda parlıyor:
- Yardım merkezi makaleleri, politika metinleri, SSS’ler var
- Cevaplar “dokümana dayalı” olmalı
- Sık değişen kampanya/koşullar yönetilecek
RAG’de pratik başarı koşulu: kaynak içerik temizliği. 2 farklı sayfada çelişen iade koşulu varsa bot da çelişir. Bu noktada chatbot nedir ve canlı destekle nasıl çalışır yazısındaki akış mantığı işinize yarar.
Ajan tool calling uygunluk şablonu
Tool calling, botun API çağırıp işlem yapmasıdır (sipariş bul, adres doğrula, kupon oluştur gibi). Uygunluk işaretleri:
- “Bilgi” değil, işlem gerekiyor
- Kullanıcı verisiyle doğrulama şart
- Yanıtın doğruluğu kritik (stok, fiyat, teslimat)
Burada test yaklaşımı değişir: sadece konuşma değil, API yanıtları ve hata durumları da senaryolaştırılır.
Çok kanallı bot uygunluk şablonu
Web chat, WhatsApp, Instagram DM gibi kanallarda aynı senaryoyu çalıştıracaksanız:
- Mesaj uzunluğu ve dosya/medya desteği değişir
- Kimlik doğrulama yöntemi kanal bazlı farklılaşır
- Operasyonel handoff kuralları ayrışır
Çok kanallı tasarımda tek bir “evrensel akış” yerine kanal varyantları planlayın. WhatsApp’ta kısa, web’de daha yönlendirici metinler çalışır.
Yanlış eşleşme belirtileri ve düzeltme
Yanlış bot türü seçtiğinizi şu belirtilerden anlarsınız:
- Kullanıcılar aynı soruyu 2–3 kez soruyor (anlaşılamama)
- Temsilciye devir oranı %60+ ve düşmüyor
- Bot “politikayı” anlatırken sürekli çelişiyor (RAG içerik sorunu)
- API hataları kullanıcıya yansıyor (tool calling hata yönetimi eksik)
Düzeltme çoğu zaman “modeli büyütmek” değil; kapsam daraltmak, içerik temizlemek ve handoff kurallarını netleştirmektir.
Kanal ve Handoff Tasarımı
Canlı destek botu, tek başına değerlendirilemez. Kanal, hız beklentisini ve kullanıcı sabrını belirler. Handoff (insana devir) ise müşteri deneyiminin sigortasıdır. İyi tasarımda bot, temsilciyi “saklamaz”; doğru anda devreder.
Web canlı chat ve WhatsApp senaryoları
Web canlı chat’te kullanıcı aynı anda sayfada gezdiği için bot:
- ürün linki, kategori önerisi, sepet hatırlatma
- 1–2 tıkla form doldurtma
gibi aksiyonlarla iyi çalışır.
WhatsApp’ta ise kullanıcı “tek iş” için gelir. Bu yüzden mesajlar kısa olmalı, seçenekler 3–5 maddeyi geçmemeli. WhatsApp’ta gereksiz doğrulama adımı dönüşümleri düşürür, ama KVKK tarafını da unutmamak gerekir.
İnsan devri tetikleyicileri
Handoff tetikleyicilerini en baştan yazın. En pratik set:
- Kullanıcı 2 kez “olmadı / anlamadım” dedi
- Bot güven skoru düşük (platformunuz sunuyorsa)
- Ödeme, adres, iptal gibi riskli niyetler
- Duygu: öfke, hakaret, “şikayet edeceğim”
Handoff’ta hedef, sorunu çözmek kadar kullanıcıyı sakin tutmak. Botun “Sizi temsilciye bağlıyorum, şu bilgileri ileteceğim” demesi fark yaratır.
Temsilciye aktarılacak bağlam alanları
Temsilciye ham sohbeti atmak yetmez. Minimum bağlam paketi:
- Kanal + kullanıcı ID (telefon/e-posta maskeli)
- Tespit edilen niyet ve güven skoru
- Toplanan alanlar: sipariş no, ürün adı, konu
- Denenen çözümler (bot hangi adımları verdi)
- Son kullanıcı mesajı
Bu alanlar, temsilci AHT’yi düşürür ve “aynı soruları tekrar sorma” şikayetini azaltır.
Mesai dışı ve yoğunluk yönetimi
Mesai dışında botu “her şeyi çözer” gibi konumlamayın. Daha gerçekçi bir model:
- Self servis çözülebilen niyetler: kargo takip, iade başlatma, SSS
- Diğerleri: kayıt aç, geri dönüş zamanı ver
Yoğun saatlerde de bot, bekleme süresini dürüstçe söylemeli. 20 dakika bekletecekseniz, “Size 2 dakika içinde bağlanıyorum” demek güven kaybettirir.
Loglama ve denetim gereksinimleri
Canlı destek botlarında log, sadece “analiz” değil, itiraz yönetimi için de gerekir. Şunları saklamak mantıklı:
- Kullanıcı mesajı + bot yanıtı
- Kullanılan kaynak doküman linki (RAG)
- Yapılan API çağrısı (maskeli) ve sonuç kodu
- Handoff nedeni
Saklama süresini KVKK ve şirket politikanıza göre belirleyin; erişimi rol bazlı kısıtlayın.
E ticaret Satış Asistanı
Kullanıcı niyeti ve hedef çıktı
Bu senaryo, ürün keşfi ve seçim desteği içindir. Uygun olduğu ekipler:
- Katalogu geniş, ürün farkları ince olan mağazalar
- Sepete ekleme oranı düşük ama trafik yüksek olanlar
Hedef çıktı: kullanıcının kriterlerine göre 3 ürün önerisi + her biri için 1 cümle gerekçe + ilgili link. “Tek ürün dayatmak” yerine seçenek sunmak daha iyi çalışır.
Örnek prompt ve beklenen yanıt
Kullanıcı: “Kamp için hafif bir uyku tulumu arıyorum, 0 dereceye uygun olsun.”
Beklenen bot yanıtı:
- 2 soru: “Boy/kilo” ve “bütçe aralığı”
- Sonra 3 öneri: ağırlık, sıcaklık limiti, iade koşulu kısa not
- “Stokta var” gibi gerçek zamanlı bilgi (entegrasyon varsa)
Metin uzunluğunu kontrol edin. Web chat’te 6–8 satır, WhatsApp’ta 3–5 satır idealdir.
Entegrasyon noktaları ürün katalog stok fiyat
Satış asistanı için en az:
- Ürün katalog feed’i (kategori, özellik, varyant)
- Stok durumu
- Fiyat ve kampanya
Stok/fiyat entegrasyonu yoksa bot “şu ürün var” deyip hayal kırıklığı yaratır. Bu senaryoda tool calling genelde şarttır.
Başarı metrikleri dönüşüm sepet ortalaması
Ölçümde iki metrik yeter:
- Dönüşüm oranı: bot etkileşimli oturumlar vs kontrol grubu
- Sepet ortalaması: bot önerisiyle sepete eklenen ürünler
Etkisini görmek için 3–6 haftalık pencere verin. Günlük oynaklık çok olur.
Riskler yanlış yönlendirme ve handoff
Risk: botun uyumsuz ürün önermesi (ör. “0 derece” yerine “10 derece”). Çözüm:
- Net filtre kuralları (özellik alanı yoksa önerme)
- Emin değilse “2 seçenek var, hangisi öncelik?” diye sor
- Kritik sorularda temsilciye devret (teknik ürünler, garanti)
Sipariş ve Kargo Sorgusu
Kullanıcı niyeti ve hedef çıktı
En klasik canlı destek senaryosu. Uygun olduğu yerler:
- Günlük sipariş hacmi yüksek e-ticaret
- Kargo kaynaklı “nerede kaldı” teması yoğun ekipler
Hedef çıktı: siparişin son durumunu, tahmini teslim aralığını ve kargo takip linkini tek yanıtta vermek.
Örnek prompt ve beklenen yanıt
Kullanıcı: “Siparişim gelmedi, kargom nerede?”
Beklenen bot akışı:
- “Sipariş numaranızı ya da kayıtlı telefonunuzu yazar mısınız?”
- Doğrulama sonrası: “X kargo, takip no Y, son hareket Z, tahmini teslim T”
- Sorun varsa: “Gecikme görünüyor, temsilciye aktarıyorum.”
Burada hız önemli. Kullanıcıya 4 soru sorarsanız kaçıyor.
Entegrasyon noktaları sipariş OMS kargo takip
Gerekli entegrasyonlar:
- OMS/e-ticaret altyapısı sipariş API’si
- Kargo takip API’si (veya takip sayfası scraping değil, mümkünse resmi API)
- CRM’de müşteri eşleştirme (opsiyonel)
Entegrasyon yoksa bu senaryoyu botla çözmeye çalışmayın; en fazla “takip sayfası linki” verirsiniz.
Başarı metrikleri self servis oranı AHT
Bu senaryoda takip edilecek iki sayı:
- Self servis oranı: temsilciye devretmeden kapanan sorgular
- AHT: temsilciye gidenlerde ortalama işlem süresi
İyi bir bot, temsilciye gidenleri de hızlandırır; çünkü sipariş bilgisi hazır gider.
Riskler kimlik doğrulama ve KVKK
Kargo/sipariş verisi kişisel veri sayılır. Minimum güvenlik:
- Telefon/e-posta eşleştirmesi olmadan detay gösterme
- Son 4 hane maskeleme (telefon, takip no)
- Aynı konuşmada “adres” gibi verileri açıkça tekrar etmemek
KVKK kısmını en sonda değil, burada tasarıma gömün.
İade ve Değişim Akışı
Kullanıcı niyeti ve hedef çıktı
İade/değişim, hem duygusal hem operasyonel bir konu. Bot burada “engelleyici” değil, yol gösterici olmalı. Hedef çıktı:
- İade uygunluğu kontrolü (süre, ürün tipi, hijyen)
- RMA/başvuru oluşturma veya doğru form/linke yönlendirme
- Kargo kodu ve adımlar
Örnek prompt ve beklenen yanıt
Kullanıcı: “Ayakkabıyı iade etmek istiyorum.”
Beklenen bot yanıtı:
- “Sipariş numarası?”
- “Ürün kullanılmadı mı, kutusu duruyor mu?” (kısa)
- Uygunsa: iade adımları + kargo kodu + süre bilgisi
- Uygun değilse: gerekçe + istisna için temsilciye devir
Netlik önemli. 12 maddelik politika metni kimse okumaz.
Entegrasyon noktaları iade politikası RMA ödeme
İdeal kurulum:
- Politika içerikleri (RAG ile)
- RMA/iadeye başlat API’si (yoksa form)
- Ödeme iadesi durumu (muhasebe/ödeme sağlayıcı)
Bu entegrasyonlar yoksa bot, sadece “nasıl iade ederim” metni okur ve değer düşer.
Başarı metrikleri çözüm süresi CSAT
İade senaryosunda temel metrikler:
- Çözüm süresi: başvuru oluşturma veya doğru yönlendirme süresi
- CSAT: özellikle olumsuz deneyimi yumuşatıp yumuşatmadığı
Burada düşük CSAT hemen bot hatası değildir; gecikmeli iadeler gibi dış faktörleri ayırın.
Riskler istisnalar ve insan devri
İade istisnaları bitmez: hediye, kampanya, hijyen, eksik parça. Bu yüzden:
- İstisna listesi çıkarın (top 10)
- Bot “istisna” tespit edince otomatik handoff
- Temsilciye: sipariş, ürün, politika maddesi bağlamı gitsin
Bu senaryoda “her şeyi otomatikleştirme” ısrarı genelde ters teper.
Sık Sorulan Sorular Botu
Kullanıcı niyeti ve hedef çıktı
SSS botu, “temsilciye sormadan cevap” isteyen kullanıcılar içindir. Uygun olduğu yerler:
- Temasların büyük kısmı bilgi sorusuysa
- Yardım merkezi içerikleri düzenliyse
Hedef çıktı: 1–2 paragrafta net yanıt + ilgili sayfaya link + gerekiyorsa bir sonraki adım.
Örnek prompt ve beklenen yanıt
Kullanıcı: “Kapıda ödeme var mı?”
Beklenen yanıt: “Evet/Hayır” netliği, şartlar (limit, komisyon), geçerli kargo/şehir bilgisi varsa kısa. Sonuna “Ödeme seçenekleri” sayfası linki.
SSS botunda uzun cevaplar yerine netlik kazanır.
Entegrasyon noktaları yardım merkezi içerikleri
Entegrasyon çoğu zaman basit:
- Help center URL’leri (RAG)
- Kategori etiketleri ve güncelleme tarihi
- İçerik yönetim süreci (kim güncelliyor?)
İçerik yoksa botu kurmayın; önce 30–50 temel makale çıkarın.
Başarı metrikleri temas azaltma ve CSAT
SSS botunda başarı:
- Temas azaltma: aynı soruların canlı desteğe düşüşü
- CSAT: “cevap işe yaradı mı?” mikro anketi
Mikro anketi 1 soruya indirin. “Bu yanıt yardımcı oldu mu? E/H” yeter.
Riskler güncellik ve halüsinasyon
SSS botlarının en büyük riski: eski bilgi. Çözüm:
- İçerik refresh döngüsü: 12–18 ay değil, kampanyalı sektörlerde 3–6 ay
- Yanıt içinde “Kaynak: …” linki
- Belirsizlikte “emin değilim” + temsilciye yönlendirme
Halüsinasyonla savaşın en pratik yolu, botu “kaynak yoksa cevap verme” kuralına bağlamaktır.
İç Bilgi Bankası Botu
Kullanıcı niyeti ve hedef çıktı
Bu bot müşteri için değil, temsilci içindir. Uygun olduğu durumlar:
- Yeni temsilci onboarding’i zor
- Ürün, politika ve süreçler çok dağınık
- Ticket geçmişinden öğrenilecek çok şey var
Hedef çıktı: temsilcinin 30 saniyede doğru prosedürü bulması ve kullanıcıya doğru cümleyi kurması.
Örnek prompt ve beklenen yanıt
Temsilci: “Kullanıcı kargo hasarlı geldi diyor, hangi adımları izliyoruz?”
Beklenen yanıt:
- 4–6 maddelik adım listesi
- Gerekli belge/kanıt (fotoğraf, tutanak)
- İlgili iç doküman linki
- “Şu durumlarda eskalasyon” notu
Bu botun dili daha teknik olabilir. Kullanıcıya konuşur gibi olmamalı.
Entegrasyon noktaları dokümanlar CRM ticket geçmişi
İyi kurulum için:
- İç dokümanlar (Drive/Confluence/Notion)
- CRM alanları ve ticket şablonları
- Çözüm notları, makrolar
Ticket geçmişi değerlidir ama temizlenmemişse gürültü üretir. Önce en iyi 200–500 çözüm notunu seçip indekslemek mantıklı.
Başarı metrikleri temsilci AHT ve ilk temas çözümü
Burada KPI’lar nettir:
- Temsilci AHT düşüşü
- İlk temas çözümü artışı
- İç arama süresi (varsa) azalması
Bu bot, dışarıya görünmediği için daha hızlı iterasyon yapılabilir.
Riskler yetkilendirme ve denetim izi
En kritik risk: temsilci botunun hassas veriye erişmesi. Şunları şart koşun:
- Rol bazlı erişim (stajyer, kıdemli, yönetici)
- Müşteri verisi maskeleme
- “Kim, neyi sordu, hangi kaynağı kullandı” denetim izi
Bu kısım gevşek kalırsa bot faydadan çok risk üretir.
Başarı KPI Panosu
KPI seti AHT self servis CSAT dönüşüm
Tek bir pano, farklı senaryoları aynı anda izlemeli. Minimum KPI seti:
- AHT (temsilci süreleri)
- Self servis oranı
- CSAT
- Satış senaryosunda dönüşüm ve sepet ortalaması
Hepsini haftalık trend olarak görün. Günlük grafikler, operasyonda gereksiz panik yaratır.
Kanal bazlı raporlama kırılımları
Aynı bot web’de iyi, WhatsApp’ta kötü olabilir. Bu yüzden kırılımlar:
- Web chat / WhatsApp / Instagram
- Mesai içi / mesai dışı
- Yeni müşteri / mevcut müşteri
Bu ayrım, “bot kötü” genellemesini engeller.
Senaryo bazlı hedef ve eşik tanımı
Her senaryoya eşik koyun. Örnek:
- Kargo sorgusu: handoff %25 üstüne çıkarsa alarm
- SSS: “yardımcı oldu” oranı %70 altına düşerse içerik kontrolü
- Satış asistanı: öneri tıklama oranı %10 altı ise filtre revizyonu
Eşikler, ekibe neyi ne zaman düzeltmesi gerektiğini söyler.
Deney tasarımı A B ve sürüm takibi
Botu güncelledikçe neyin işe yaradığını unutmak kolay. Basit bir disiplin yeter:
- Her değişikliğe sürüm adı verin (v1.3 gibi)
- 1 hafta sadece tek büyük değişiklik yapın
- A/B mümkünse: trafiğin %10’unda deneyin
Amaç bilim yapmak değil; geri alınabilir değişiklikler yapmak.
Ajans ve KOBİ için rapor şablonu
Ajanslar ve KOBİ’ler için pratik rapor:
- 1 sayfa özet: KPI trend + 3 içgörü + 3 aksiyon
- Senaryo bazlı: en çok handoff nedeni, en çok yanlış anlaşılan 10 ifade
- İçerik/entegrasyon backlog’u
Daha fazlası genelde okunmuyor. AI ve chatbot içerikleri kategorisinde benzer operasyonel pratikleri de bulabilirsiniz.
Risk ve KVKK Kontrolleri
KVKK veri minimizasyonu ve maskeleme
Bot tasarımında altın kural: gerekmeyen veriyi isteme. Sipariş için TC kimlik gibi alanlar çoğu zaman gereksiz. Maskeleme örnekleri:
- Telefon: 5XX XXX 12**
- E-posta: a***@domain.com
- Adres: mahalle/kapı no göstermeden doğrulama
Ayrıca, kullanıcıya “Bu bilgiyi paylaşmayın” uyarısını botun giriş mesajına eklemek işe yarar.
Halüsinasyon önleme ve kaynak gösterimi
Halüsinasyonu tamamen sıfırlamak zor. Yönetebilirsiniz:
- RAG kullanıyorsanız: yanıt altında kaynak linki
- Kaynak yoksa: “Bu konuda net bilgim yok, temsilciye aktarıyorum.”
- Politika ve fiyat gibi kritik alanlarda “tahmin” yasak
Bu kurallar, botu daha “mütevazı” yapar ama canlı destek için doğru olan budur.
Handoff ve itiraz yönetimi
Kullanıcı bot yanıtına itiraz ettiğinde (ör. “iade olmaz diyorsun ama olur”) bot tartışmaya girmemeli:
- “Haklısınız, kontrol için temsilciye aktarıyorum.”
- İtiraz nedeni etiketi: “politika itirazı / fiyat itirazı / kargo itirazı”
- Temsilciye ilgili politika kaynağı iletilsin
Bu, hem CSAT’i korur hem de yanlış bot yanıtlarını hızlı yakalar.
Loglama saklama ve erişim yetkileri
Loglar KVKK kapsamında riskli olabilir. Pratik kontrol listesi:
- Saklama süresi: iş ihtiyacına göre, gereksiz uzatmayın
- Erişim: sadece ihtiyaç duyan рол’ler
- Silme talebi süreci: kullanıcı talep ederse nasıl silinecek?
Ayrıca eğitim amaçlı sohbet örnekleri kullanıyorsanız, kişisel verileri anonimleştirmeden paylaşmayın.
Düzenli denetim kontrol listesi
Aylık mini denetim yeterli olur:
- En çok şikayet alan 20 konuşmayı incele
- En çok handoff tetikleyen 10 niyeti kontrol et
- İçerik kaynaklarında çelişki var mı bak
- API hata oranlarını ve kullanıcıya yansıyan mesajları gözden geçir
Bu rutin, botun “ilk kurulumdan sonra çürümesini” engeller.
