Chatbot Nedir Canlı Destekle Nasıl Çalışır

Chatbot’lar, müşteri iletişimini ölçeklemek isteyen ekipler için cazip görünüyor. Ama pratikte “chatbot nedir?” sorusunun cevabı tek cümle değil: Botun türü, beslendiği veri, konuşma tasarımı, canlı temsilciye devir kurgusu ve KVKK gibi sınırlar sonucu belirliyor.

Bu rehber, canlı destek kurmak ya da mevcut sistemi iyileştirmek isteyen e-ticaret yöneticileri, KOBİ sahipleri, SaaS ürün ekipleri ve müşteri destek liderleri için yazıldı. Hedef, “bot ekleyelim” seviyesinde kalmadan, chatbot + canlı destek birlikteliğini bir işletim sistemi gibi ele almak: nerede otomasyon mantıklı, nerede riskli, hangi mimariyle sürdürülebilir, hangi metriklerle yönetilir.

Canlı destek sistemleriyle ilgili daha fazla kurulum ve karşılaştırma içeriği için Canlı Destek Blog üzerinden blog sayfasına göz atabilir, temel sayfalara ana sayfa üzerinden ulaşabilirsiniz. Sorunuz spesifikse iletişim kanalını kullanmak daha hızlı sonuç verir.

İçerikler

• Chatbot Tanımı
• Kullanım Senaryoları
• Chatbot Türleri
• Çalışma Mimarisi
• Veri ve Bilgi Kaynakları
• Diyalog Tasarımı
• Kanal Entegrasyonları
• Canlı Temsilci Devri
• Güvenlik ve KVKK
• Performans İşletim Döngüsü

Chatbot Tanımı

Chatbot, bir kullanıcıyla yazılı (bazen sesli) konuşma yaparak belirli hedefleri tamamlamaya çalışan yazılımdır. Bu hedefler “bilgi verme” olabilir, “işlem başlatma” olabilir, “doğru ekibe yönlendirme” olabilir. Gerçek dünyada başarılı botlar genelde tek bir şeye odaklanır: tekrarlayan temasları hızlı ve tutarlı çözmek.

Buradaki kritik ayrım şu: Chatbot bir kanal değil, bir “karar ve yanıt katmanı”. Web canlı destek widget’ına da konur, WhatsApp’a da, ürün içi mesaja da. Canlı destekle beraber çalıştığında ise botun görevi çoğu zaman “tam çözüm” değil, ilk temas yönetimi olur.

Chatbot ne yapar ne yapmaz

Chatbot’un iyi yaptığı işler:

• Sınıflandırma: Kullanıcının ne istediğini (niyeti) anlamaya çalışır.
• Bilgi sunma: SSS, kargo politikası, iade adımları gibi içerikleri hızlı getirir.
• Form toplama: İsim, e-posta, sipariş no, konu gibi alanları standartlaştırır.
• Basit aksiyon: Sipariş sorgulama, randevu talebi oluşturma gibi sınırlı işlemler.

Chatbot’un zorlandığı yerler:

• Belirsiz, çok adımlı, istisnalarla dolu süreçler.
• Duygusal gerilim içeren şikayetler.
• Politika yorumu gerektiren konular (hak talepleri, garanti istisnaları).
• Yetki gerektiren işlemler (hesap kapatma, ödeme iadesi) eğer sağlam doğrulama yoksa.

Pratik kural: Botun çözümlemesini istediğiniz iş, bir temsilcinin “kopyala-yapıştır + iki tık” ile yaptığı işse otomasyon mantıklıdır. Temsilci “dur, geçmişe bakayım, istisna var” diyorsa, botun sınırını çizmek gerekir.

Chatbot ile canlı destek farkı

Canlı destek, gerçek bir temsilcinin konuşmayı sahiplenmesidir. Chatbot ise bir sistemin “otomatik temsil” denemesidir. Bu fark, hedef metriklere de yansır:

• Chatbot’ta hedef: self-servis çözüm oranı, doğru yönlendirme, düşük bekleme.
• Canlı destekte hedef: ilk temas çözümü, müşteri memnuniyeti, karmaşık sorun çözümü.

Chatbot’u canlı desteğin yerine koymak çoğu ekipte ters teper. İyi kurgu şu olur: Bot, kapı görevlisi gibi çalışır; doğru bilgiyi verir, doğru veriyi toplar, gerekiyorsa temsilciyi doğru bağlamla devreye alır.

E ticaret ve KOBİ için kapsam sınırı

E-ticaret ve KOBİ’lerde bot kapsamını belirlerken, “her şeyi cevaplasın” yaklaşımı yerine bir kapsam sınırı dokümanı çıkarın. En basit haliyle:

• Botun kapsadığı 10–30 niyet (intent)
• Her niyet için “başarı kriteri” (ör. kargo durumunu göstermek)
• Her niyet için “devir eşiği” (ör. sipariş bulunamazsa 2 denemeden sonra temsilci)

E-ticarette genelde en yüksek hacim: kargo, iade, ödeme, ürün uygunluğu, kampanya koşulları. KOBİ’lerde: randevu, fiyat talebi, konum/çalışma saatleri, hizmet kapsamı.

Botu ilk sürümde küçük tutmak, ikinci ay büyütmek daha iyi sonuç verir. Çünkü ilk ayın gerçek verisi, tahmin ettiğinizden farklı çıkar.

Supporting Article Potential:

• Chatbot kapsam dokümanı nasıl hazırlanır? (Intent listesi, başarı kriteri, devir eşiği)
• Canlı destek mi chatbot mu? Hangi durumda hangisi daha mantıklı?
• E-ticaret için chatbot kapsamı: İlk 30 günde en doğru başlangıç seti

Kullanım Senaryoları

Chatbot projeleri “teknoloji” diye başlar, “operasyon” diye biter. Bu yüzden senaryoları iş çıktısına göre tanımlamak gerekir: süre kısalacak mı, bilet sayısı düşecek mi, dönüşüm artacak mı?

Aşağıdaki senaryolar, canlı destekle birlikte çalıştığında en hızlı geri dönüş veren alanlar. Her birinde kritik nokta, botun tek başına çözmesi değil; doğru veriyi toplayıp doğru sisteme yazması ve gerektiğinde temsilciyi hazırlamasıdır.

E ticarette sipariş ve kargo sorgusu

Sipariş/kargo sorgusu botların “en iyi koştuğu” parkur. Çünkü veri nettir: sipariş no, e-posta/telefon, kargo firması, takip kodu.

Uygulama notları:

• Kullanıcıdan en fazla 2 bilgi isteyin: “Sipariş no” + “telefon/e-posta”.
• Başarısız eşleşmede aynı soruyu tekrar etmek yerine alternatif sunun: “Takip kodun var mı?”
• Yanıta sadece durum yazmayın; bir sonraki adımı ekleyin: “Dağıtımda, bugün 18:00’e kadar teslim.”

Entegrasyon yoksa bile en azından “kargo politikası” ve “teslimat süreleri” gibi içerikleri güçlü verin. Entegrasyon varsa, botu sadece okuma yetkisiyle başlatmak çoğu ekipte riski azaltır.

KOBİ için randevu ve teklif toplama

KOBİ’lerde botun değeri, telefon trafiğini azaltması ve lead’i kaçırmamasıdır. Burada bot bir “mini asistan” gibi çalışır.

İyi bir akış:

1. Hizmet seçimi (tek seçenekli butonlar)
2. Tarih/saat tercihi (2–3 seçenek)
3. İletişim bilgisi (telefon + ad)
4. Not alanı (opsiyonel)
5. Onay ve takip mesajı

Teklif toplamada kritik: Kullanıcıyı 12 soru ile boğmayın. İlk temas için 3–5 alan yeterli: “İhtiyaç”, “ölçek” (adet/metrekare/kullanıcı), “şehir”, “iletişim”.

SaaS için onboarding ve destek triage

SaaS tarafında bot iki işi iyi yapar: onboarding sırasında doğru kaynağa yönlendirme ve destek taleplerini sınıflandırma (triage).

Pratik kurgu:

• Ürün içi bot: “Ne yapmak istiyorsun?” (3–6 hazır seçenek)
• Seçime göre: doküman linki + kısa adım listesi
• Çözülmezse: bilet açma, ama bilet formunu bot doldurur

Burada botun en büyük katkısı, destek ekibine gelen biletin kalitesini artırmasıdır. “Çalışmıyor” yerine “X sayfasında Y hatası, tarayıcı Z, kullanıcı planı P” gibi.

Pazarlama için lead toplama ve yönlendirme

Pazarlama tarafında botların en büyük hatası, herkese aynı lead formunu dayatmak. Daha iyi yöntem: önce segmentle, sonra formu kısalt.

Örnek:

• “Fiyat mı, demo mu, entegrasyon mu?”
• “E-ticaret mi SaaS mı?”
• “Aylık kaç talep alıyorsunuz?” (bant seçimi)

Sonra ilgili ekibe yönlendirin:

• Küçük paket: self-servis içerik + e-posta
• Orta: demo formu + takvim linki
• Büyük: satış temsilcisine direkt bildirim

Burada hedef, sadece form toplamak değil; yanlış lead’i erken filtrelemek.

Supporting Article Potential:

• E-ticarette kargo/sipariş botu: Entegrasyon olmadan da işe yarayan akışlar
• SaaS triage botu nasıl kurulur? Destek bileti kalitesini artıran soru seti
• Lead toplama botu: Formu kısaltarak dönüşüm artırma (segmentleme tasarımı)

Chatbot Türleri

“Chatbot” tek bir teknoloji değil. Aynı hedefe farklı motorlarla gidebilirsiniz. Seçim, bütçeden çok risk iştahıyla ilgilidir: yanlış yanıtın maliyeti yüksekse daha kontrollü sistem gerekir.

Bu bölümde üç ana tipi ve pratik seçim kriterlerini netleştirelim.

Kural tabanlı botlar

Kural tabanlı botlar, akış ve karar ağaçlarıyla çalışır. Kullanıcıya seçenek sunar, seçime göre ilerler. Doğru kurulduğunda tahmin edilebilir ve denetlenebilir.

Artıları:

• Yanıtlar kontrollü, sürpriz az.
• KVKK ve hukuki metinlerde daha güvenli.
• Raporlama ve optimizasyon basit.

Eksileri:

• Kapsam büyüdükçe bakım maliyeti artar.
• Kullanıcı serbest yazınca niyet yakalama zayıf kalabilir (ek NLU yoksa).

Kural tabanlı botlar; iade adımları, çalışma saatleri, randevu alma gibi süreçlerde çok iyi çalışır.

AI ve LLM tabanlı botlar

LLM tabanlı botlar, serbest metni anlama ve doğal yanıt üretmede güçlüdür. En iyi kullanımı “metin üret” değil, bilgi tabanından yanıt üret (RAG yaklaşımı) şeklindedir.

Artıları:

• Serbest sorularda kapsama hızlı genişler.
• Doğal dil kalitesi yüksek.
• Self-servis içerik tüketimini artırabilir.

Eksileri:

• Halüsinasyon riski: olmayan şeyi var gibi söyleyebilir.
• Doğru kaynak gösterme ve sınır koyma şart.
• Maliyet, trafikle birlikte artabilir.

LLM bot kuracaksanız, “her şeyi biliyor” gibi davranmasına izin vermeyin. “Bu konuda emin değilim, temsilciye bağlıyorum” diyebilmesi bir özellik olmalı.

Hibrit botlar

Hibrit yaklaşım çoğu işletme için en gerçekçi model: kritik akışlar kural tabanlı, serbest sorular bilgi tabanı üzerinden LLM ile.

Örnek:

• “Sipariş sorgu” akışı: kural tabanlı + API
• “İade koşulları” sorusu: LLM + yardım merkezi
• “İade talebi başlat” butonu: kural tabanlı form

Bu model, hem kaliteyi hem de kapsama hızını dengeler. Özellikle canlı destekle beraber çalışırken hibrit, devir noktalarını daha net yönetmenizi sağlar.

Hangi ihtiyaçta hangi tür

Seçimi hızlandıran bir çerçeve:

• Yanlış yanıtın maliyeti yüksek (iade, ödeme, sözleşme): kural tabanlı / hibrit
• Çok çeşitli soru, iyi dokümantasyon var: LLM (RAG) / hibrit
• Entegrasyon yoğun (sipariş, CRM, bilet): kural tabanlı + API, üstüne LLM katmanı opsiyonel
• Destek ekibi küçük, hızlı başlamak istiyor: hibrit (dar kapsam + iyi devir)

Araç seçimi yaparken resmi sayfalardan ilerleyin: örneğin Intercom, Zendesk, Freshdesk gibi platformlar canlı destek + otomasyon tarafında farklı seviyelerde yetenek sunar. Bot motorundan bağımsız olarak, sizin süreçlerinizi taşıyabilmesi önemli.

Supporting Article Potential:

• Kural tabanlı botlarla ilk 10 akış: E-ticaret için hızlı başlangıç
• LLM botlarda halüsinasyon riski nasıl azaltılır? Pratik kontrol listesi
• Hibrit chatbot mimarisi: Hangi akışlar kural tabanlı kalmalı?

Çalışma Mimarisi

Chatbot’un “çalışıyor” görünmesi kolaydır. Asıl konu, 3 ay sonra da aynı kalitede çalışmasıdır. Bunun için mimariyi kavramsal olarak doğru kurmak gerekir: niyet yakalama, diyalog yönetimi, arama-bilgi katmanı ve entegrasyonlar birbirinden ayrılmalı.

Intent ve entity mantığı

Klasik NLU yaklaşımında iki temel parça vardır:

• Intent (niyet): Kullanıcı ne yapmak istiyor? (kargo sorgu, iade, fiyat, randevu)
• Entity (varlık): Bu işi yapmak için gereken parametre ne? (sipariş no, tarih, ürün adı)

Pratik ipuçları:

• Intent sayısını ilk sürümde 10–20 aralığında tutun.
• Aynı intent içinde farklı varyasyonları entity ile çözün. Örn. “kargo nerede” ve “takip” ayrı intent olmak zorunda değil.
• Entity doğrulaması ekleyin: sipariş no formatı, telefon uzunluğu, e-posta regex kontrolü.

Intent yakalama zayıfsa bot “her şeyi anladım” sanır, yanlış akışa girer. Bu da canlı desteğe daha öfkeli kullanıcı düşmesi demek.

Diyalog akışları ve durum yönetimi

Botlar sadece “soru-cevap” değildir; bir durum makinesi gibi çalışır. Kullanıcı bir adımda kalır, geri döner, konu değiştirir.

İyi durum yönetimi için:

• Her akışın “başlangıç, ara adımlar, başarı, başarısızlık, iptal” durumları olmalı.
• Kullanıcı konu değiştirirse: “Sipariş sorgusunu bırakıp iade koşullarına geçeyim mi?” diye net soru sorun.
• 2–3 turda sonuç alamazsanız devir tetikleyin. 3. tekrar genelde sinir eşiğidir.

Bu yapı, canlı temsilciye devri de temizleştirir. Çünkü konuşmanın hangi adımda tıkandığı bellidir.

Bilgi tabanı ve arama katmanı

LLM kullanmasanız bile, botun “bilgi” verdiği her yerde bir kaynak olmalı: yardım merkezi, SSS, dokümanlar. LLM kullanıyorsanız bu katman daha kritik hale gelir.

Pratik gereksinimler:

• İçerikler parçalara bölünmeli (çok uzun sayfalar tek parça olmasın).
• Başlıklar net olmalı; “Genel” gibi başlıklar aramayı bozar.
• Aynı konunun iki farklı sayfada çelişmemesi gerekir.

Arama katmanı iyi değilse bot “doğal dil” ile güzel cümle kurar ama yanlış bilgi verir. Kullanıcı için en kötü kombinasyon.

Entegrasyon katmanı ve arka uç çağrıları

E-ticarette sipariş, SaaS’ta kullanıcı hesabı, KOBİ’de randevu takvimi. Botun gerçek değeri çoğu zaman entegrasyondan gelir. Ama entegrasyonlar da risk taşır.

Uygulama önerileri:

• Botun çağırdığı API’lerde zaman aşımı hedefi koyun: 2–3 saniye içinde cevap gelmiyorsa “kontrol ediyorum” mesajı + alternatif yol.
• Okuma ve yazma yetkilerini ayırın. İlk sürümde sadece okuma.
• Hata kodlarını kullanıcıya göstermeyin; temsilciye bağlam olarak kaydedin.

Entegrasyonlar büyüdükçe, bot bir “mini uygulama” haline gelir. Bu noktada versiyonlama ve test süreci şart.

Supporting Article Potential:

• Intent/entity tasarımı: E-ticaret botu için örnek şema ve doğrulama kuralları
• Diyalog durum yönetimi: Konu değiştiren kullanıcılarla başa çıkma teknikleri
• Chatbot entegrasyonlarında hata yönetimi: 2 saniye kuralı ve fallback tasarımı

Veri ve Bilgi Kaynakları

Chatbot kalitesi, büyük ölçüde beslendiği verinin kalitesidir. “Model iyi” cümlesi çoğu zaman gerçeği gizler: içerikler dağınıksa, sipariş verisi tutarsızsa, CRM alanları boşsa bot da kötü çalışır.

Bu bölümde, botu besleyen ana kaynakları ve pratik bakım yaklaşımını ele alalım.

SSS ve yardım merkezi içerikleri

En hızlı kazanım alanı burasıdır. Çünkü çoğu işletmede zaten içerik vardır ama:

• Güncel değildir,
• Dağınıktır,
• Aynı soruya iki farklı yanıt verir.

Aksiyon listesi:

• En çok sorulan 30 soruyu çıkarın (canlı destek etiketleri, e-posta konuları).
• Her cevapta “adım adım” yapı kullanın, 5–7 maddeyi geçmeyin.
• Meta düzeyde: bir sayfa bir konu. “Her şey burada” sayfaları bot için zayıf kaynaktır.

İçerikleri bot için yazmak, SEO için de iyi sonuç verir. Ama burada amaç arama motoru değil, doğru yanıtın tek versiyonu.

Ürün katalog ve sipariş verileri

E-ticarette ürün verisi, botun “ürün öner” ya da “uyumluluk” gibi soruları cevaplamasını sağlar. Sipariş verisi ise sorgu akışının temelidir.

Dikkat edilmesi gerekenler:

• Ürün varyantları (beden/renk) net kodlanmalı.
• Kargo durumları standart bir sözlükte tutulmalı (dağıtımda, teslim edildi, iadede).
• Sipariş sorgusunda kimlik doğrulama: en az iki faktör gibi düşünün (sipariş no + e-posta/telefon).

Veri tutarsızlığı botun hatası gibi görünür. O yüzden bot projesi genelde veri projesine dönüşür, şaşırmayın.

CRM ve destek kayıtları

CRM verisi botun “kim bu kullanıcı” sorusunu cevaplar. Destek kayıtları ise botun “hangi konular sorun” analizini besler.

İyi bir kurgu:

• Bot, konuşma sonunda etiket atar (intent + sonuç: çözüldü/çözülmedi).
• Temsilci devralınca aynı etiketleri düzeltir. Bu geri besleme altın değerinde.
• CRM’e yazılacak alanları minimal tutun: ad, iletişim, konu, izin durumu, kaynak kanal.

Bu sayede pazarlama ve destek aynı veriye bakar. Ayrı ayrı Excel tutulmaz.

Bilgi güncelliği ve versiyonlama

Botlar “eski bilgi” yüzünden itibar kaybeder. Kampanya biter, bot hâlâ aynı indirimi söyler. İade süresi değişir, bot eskiyi anlatır.

Uygulanabilir süreç:

• Kritik içerikler için 12–18 ay yerine daha sık kontrol: kampanya, fiyat, iade, kargo politikası gibi.
• İçeriklerde “son güncelleme” alanı tutun (kullanıcıya göstermek zorunda değilsiniz).
• Bot yanıtlarında kaynak sayfayı linkleyin; hem şeffaflık hem de düzeltme kolaylığı sağlar.

Bu bakım döngüsü yoksa, en iyi bot bile 6 ay sonra “yanlış bilgi üreten robot”a dönüşür.

Supporting Article Potential:

• Yardım merkezi içeriklerini chatbot’a uygun hale getirme: Parçalama ve tek kaynak yaklaşımı
• E-ticarette sipariş verisiyle chatbot güvenliği: Doğrulama ve veri sözlüğü
• Chatbot bilgi güncelliği: Kampanya ve politika değişikliklerinde versiyonlama rutini

Diyalog Tasarımı

Diyalog tasarımı, botun zekasından daha belirleyici olabilir. Çünkü kullanıcı “anlaşıldım mı” hissine, “kolay ilerliyor mu” akışına ve tonun tutarlılığına tepki verir.

İyi diyalog tasarımı; kısa, net, yönlendirici ve gerektiğinde özür dileyip toparlayan bir yapı kurar.

Karşılama ve niyet yakalama

Karşılama mesajı botun vitrinidir. İki hedefi olmalı: beklentiyi ayarlamak ve kullanıcıyı hızlı seçim yaptırmak.

Örnek yapı:

• “Size nasıl yardımcı olabilirim? Aşağıdakilerden seçin.”
• 4–6 buton: “Sipariş/kargo”, “İade”, “Ürün sorusu”, “Ödeme”, “Temsilciye bağlan”
• Serbest yazma alanı açık kalabilir ama butonlar yön verir.

Burada kritik: “Her şeyi sorabilirsiniz” demeyin. Bu cümle kapsamı gereksiz büyütür ve kullanıcıyı hayal kırıklığına iter.

Soru sorma ve doğrulama adımları

Bot, bilgi toplarken bir temsilci gibi davranmamalı. Kullanıcıyı sorguya çekmek yerine, neden sorduğunu açıklamalı.

İyi pratik:

• “Siparişini bulmak için sipariş numaranı alabilir miyim?”
• Doğrulama: “123456 doğru mu?” (tek tık onay)
• Bir seferde tek soru. Aynı mesajda 3 alan istemek dönüşümü düşürür.

Form alanları için ölçü: İlk temas akışında 3–5 alan aralığını aşmayın. Daha fazlası, “bilet formu” hissi verir.

Hata mesajları ve geri kazanım

Hata mesajı, kullanıcı deneyiminin en kritik anıdır. Kötü hata mesajı, iyi botu bile çöpe atar.

Kurallar:

• Hata mesajı “ne oldu” + “ne yapalım” içermeli.
• 2 başarısız denemeden sonra alternatif yol verin: “Sipariş numaran yoksa e-posta ile arayayım.”
• Kullanıcı sinyali: Küfür, tekrar, büyük harf, “insan” yazımı. Bu sinyallerde devir daha erken olmalı.

Basit ama etkili: “Bunu çözemiyorum” yerine “Şu an siparişini bulamadım. İstersen temsilciye aktarayım, sohbet geçmişini de ileteceğim.”

Ton ve marka dili tutarlılığı

Botun tonu, markanın müşteri deneyiminin bir parçası. Ama “sevimli” olmak uğruna belirsizleşmek pahalıya patlar.

Denge önerisi:

• Kısa cümleler, net fiiller.
• Gereksiz şaka yok.
• Özür bir kere, açıklama kısa.
• Politika cümleleri net: süre, koşul, istisna.

Bir de tutarlılık: WhatsApp’ta resmi, web’de aşırı samimi olmak kullanıcıyı şaşırtır. Kanallar farklı ama marka dili tek olmalı.

Supporting Article Potential:

• Chatbot karşılama mesajı nasıl yazılır? 6 buton kuralı ve kapsam yönetimi
• Hata mesajı tasarımı: 2 deneme eşiği ve geri kazanım akışları
• Bot tonu ve marka dili: Resmiyet/samimiyet dengesini bozmadan net yazma

Kanal Entegrasyonları

Chatbot’unuzu nerede çalıştıracağınız, teknik bir karar gibi görünür ama aslında operasyon kararıdır. Web’deki kullanıcı ile WhatsApp’taki kullanıcı aynı davranmaz. E-posta yakalama ile canlı sohbet aynı ritimde ilerlemez.

Web sitesi canlı destek widgetı

Web widget, en kontrol edilebilir kanaldır. Kimlik eşleme, sayfa bağlamı, UTM bilgisi gibi veriler burada daha rahat taşınır.

Uygulama detayları:

• Widget açılışını agresif yapmayın. 3–5 saniyede patlayan pop-up dönüşümü düşürebilir.
• Sayfa bazlı tetikleyin: ödeme sayfasında farklı, iade sayfasında farklı karşılama.
• Performans: widget script’i sayfayı yavaşlatmasın. Hedefiniz 2.5 saniye altında yüklenme ise, üçüncü taraf script’leri izleyin.

Canlı destek yazılımı seçerken, bot + temsilci geçişinin pürüzsüz olması gerekir. Sadece “bot var” demesi yetmez.

WhatsApp ve sosyal mesajlaşma

WhatsApp, kullanıcı için “daha kişisel” bir kanal. Bu yüzden botun hata toleransı daha düşüktür. Yanlış cevap, daha sert tepki doğurur.

Pratik öneriler:

• İlk mesajda açık yazın: “Otomatik asistan” ve “temsilciye bağlan” seçeneği.
• Uzun menülerden kaçının; 2–4 seçenek daha iyi.
• Mesajlaşma uygulamalarında oturum kopabilir. Kullanıcı ertesi gün yazınca bağlam kaybolmasın diye “kısa özetle tekrar sor” akışı tasarlayın.

Kanal politikaları ve resmi entegrasyonlar için WhatsApp Business tarafını doğru kurgulamak gerekir; resmi bilgi için WhatsApp Business sayfasından ilerleyin.

E posta ve form yakalama

E-posta “anlık sohbet” değildir. Bu kanalda bot yaklaşımı daha çok:

• Akıllı form,
• Otomatik yanıt,
• Sınıflandırma ve yönlendirme şeklinde çalışır.

İyi uygulama:

• Formda konu seçimi + 1 serbest alan.
• Otomatik yanıt: tahmini dönüş süresi ve self-servis linkleri.
• Destek sistemine otomatik etiketleme (fatura, iade, teknik).

E-posta tarafında amaç, kullanıcıyı konuya göre doğru kuyruğa sokmak ve ilk yanıt kalitesini yükseltmektir.

Çok kanalda oturum ve kimlik eşleme

Gerçek zorluk burada başlar: Aynı kişi web’den yazdı, sonra WhatsApp’tan devam etti. Bu iki konuşmayı birleştirmezseniz kullanıcı aynı şeyleri tekrar eder.

Pratik kimlik eşleme seçenekleri:

• E-posta bazlı eşleme (B2B/SaaS’ta güçlü)
• Telefon bazlı eşleme (WhatsApp için doğal)
• Sipariş no bazlı eşleme (e-ticarette geçici ama işe yarar)

Minimum hedef: Temsilciye devredildiğinde, temsilci kullanıcının önceki kanal konuşmasını görebilsin. Bu, tekrar soru sorma maliyetini düşürür.

Supporting Article Potential:

• Web canlı destek widget’ında bot tetikleme stratejisi: Sayfa bazlı senaryolar
• WhatsApp chatbot tasarımı: Kısa menü, hızlı devir, oturum kopması yönetimi
• Omnichannel kimlik eşleme: E-posta/telefon/sipariş no ile pratik birleştirme

Canlı Temsilci Devri

Chatbot’un en kritik yeteneği, gerektiğinde konuşmayı doğru şekilde canlı temsilciye devretmesidir. Devir kötü tasarlanırsa bot, destek ekibinin yükünü azaltmaz; tersine artırır. Çünkü temsilci “ne oldu” diye baştan sorar, kullanıcı da sinirlenir.

Devir tetikleyicileri ve eşikler

Devir tetikleyicilerini baştan tanımlayın. “Kullanıcı isterse” tek başına yetmez; kullanıcı bazen istemez ama ihtiyaç vardır.

Yaygın tetikleyiciler:

• 2 kez anlaşılmama (intent confidence düşük)
• 3 turda çözülemeyen akış
• Negatif duygu sinyali (hakaret, “şikayet”, “mahkeme”, “dolandırıcılık” gibi kelimeler)
• Yüksek riskli konu: ödeme iadesi, hesap güvenliği
• VIP müşteri etiketi (CRM’den)

Eşikler net olmalı. Özellikle “3 tur” kuralı, pratikte iyi çalışır: botun inadı kullanıcıyı kaybettirir.

Temsilciye bağlam aktarımı

Devir anında temsilciye aktarılacak bağlamı bir “paket” gibi düşünün. Temsilci ekranında şunlar olmalı:

• Kullanıcının son 10 mesajı
• Tespit edilen intent ve toplanan entity’ler (sipariş no, e-posta)
• Botun denediği aksiyonlar (API çağrısı başarısız, bilgi tabanı yanıtı gösterildi)
• Kanal ve sayfa bağlamı (web’de hangi sayfadaydı)

Bu aktarım yoksa devir, sadece “sohbeti başka kuyruğa atmak” olur. Kullanıcı için değersiz.

Mesai dışı ve kuyruk yönetimi

Temsilci yokken botun rolü artar. Ama burada da dürüst olmak gerekir.

Mesai dışı kurgusu:

• “Şu an çevrim dışıyız, ilk iş gününde dönüş yapacağız.”
• Bekleme yerine seçenek: bilet bırak, e-posta al, yardım merkezi linki ver.
• Acil konularda otomatik yön: “Kargo iptal” gibi konularda politika netse bot çözebilir.

Kuyruk yönetiminde, botun “bekleme süresi” tahmini vermesi faydalı olabilir ama uydurma olmamalı. Tahmin yoksa söylemeyin. Sadece “sıradasınız” deyin.

Devir sonrası takip ve kapanış

Devirden sonra botun tamamen susması gerekmiyor. Konuşma kapanışında devreye girebilir:

• Memnuniyet sorusu (1–2 soru)
• Konuşma özeti ve kayıt numarası
• Self-servis önerisi (aynı konu tekrar olursa)

Ama ölçüyü kaçırmayın. Kapanıştaki anket 5 soru olursa, kullanıcı yanıtlamaz.

Supporting Article Potential:

• Chatbot canlı temsilci devri: 3 tur kuralı ve risk bazlı tetikleyiciler
• Temsilciye bağlam aktarımı nasıl tasarlanır? Alan listesi ve örnek ekran mantığı
• Mesai dışı bot kurgusu: Bilet toplama ve kullanıcı beklentisi yönetimi

Güvenlik ve KVKK

Chatbot, veri toplar. Bu yüzden sadece UX ve otomasyon konusu değildir; güvenlik ve uyum konusudur. KVKK tarafında “gereksiz veri” toplamak bile risk doğurur. LLM tarafında ise yanlış yönlendirme ve halüsinasyon, marka ve hukuki risk yaratır.

Kişisel veri minimizasyonu

İlk ilke: minimizasyon. Bot, çözüm için gerekmeyen kişisel veriyi sormamalı.

Pratik öneriler:

• Sipariş sorgusunda TCKN gibi alanlar çoğu senaryoda gereksizdir.
• Kimlik doğrulama gerekiyorsa “sipariş no + kayıtlı telefon/e-posta” çoğu e-ticarette yeterlidir.
• Serbest metin alanlarında kullanıcı gereksiz veri yazabilir. Bu yüzden “Lütfen kart bilgisi paylaşmayın” gibi uyarılar ekleyin.

Ayrıca loglama: Konuşma kayıtlarını saklama süresi ve erişim yetkileri net olmalı.

Açık rıza ve aydınlatma metni temasları

Bot üzerinden veri topluyorsanız, kullanıcıyı aydınlatmanız gerekir. Bu, her mesajda uzun metin göstermek demek değil.

Uygulama yaklaşımı:

• Widget içinde “Aydınlatma metni” linki.
• Lead toplama akışında kısa bilgilendirme: “Bilgilerinizi talebinizi yanıtlamak için işleyeceğiz.”
• Pazarlama izni ayrı bir onay olmalı; destek talebiyle karıştırılmamalı.

Metinleri hukuk ekibinizle netleştirin. Bot, yanlış kurguyla “izinsiz pazarlama” riskine sürükleyebilir.

Yetkilendirme ve erişim kayıtları

Bot paneline kim erişiyor? Temsilci konuşma kayıtlarını kim görebiliyor? Yönetici mi, ajans mı?

Minimum güvenlik:

• Rol bazlı yetki (temsilci, takım lideri, admin)
• Erişim logları (kim, neyi, ne zaman gördü)
• API anahtarlarının rotasyonu
• SSO mümkünse tercih

Özellikle entegrasyonlar (CRM, sipariş) varsa, bot paneli fiilen bir “veri kapısı” olur.

Halüsinasyon ve yanlış yönlendirme kontrolleri

LLM tabanlı botlarda en kritik risk: uydurma bilgi. Bunu “modelin doğası” deyip geçemezsiniz; kontrol mekanizması kurmanız gerekir.

Pratik kontroller:

• Botun sadece onaylı kaynaklardan yanıt üretmesi (bilgi tabanı ile sınırlama).
• Emin değilse “bilmiyorum” diyebilmesi. Bu bir kalite göstergesidir.
• Yüksek riskli konularda sabit yanıt: iade süresi, garanti koşulu, ödeme gibi.
• Yanıtların sonuna kaynak linki eklemek (kullanıcı doğrulasın, siz de iz sürün).

Bu kontroller yoksa, bot kısa vadede bilet azaltır gibi görünür; orta vadede şikayet artırır.

Supporting Article Potential:

• KVKK açısından chatbot veri minimizasyonu: Hangi alanlar gerçekten gerekli?
• Chatbot yönetim paneli güvenliği: Rol bazlı yetki ve loglama kontrol listesi
• LLM botlarda halüsinasyon önleme: Sabit yanıt, kaynak sınırlama ve devir stratejisi

Performans İşletim Döngüsü

Chatbot’u yayına almak “bitti” değildir. Asıl iş, ondan sonra başlar. Botlar canlı bir sistemdir: kullanıcı davranışı değişir, ürün değişir, kampanya değişir, niyetler kayar. Yönetmezseniz performans düşer.

Bu bölüm, chatbot’u bir ürün gibi işletmek için minimum döngüyü verir.

Hedef metrikler ve raporlama

Metrikler, botun gerçekten işe yarayıp yaramadığını gösterir. Herkesin baktığı metrik farklı olunca, bot “iyi mi kötü mü” tartışması bitmez.

Önerilen metrik seti:

• Self-servis çözüm oranı: Temsilciye devretmeden tamamlanan oturum yüzdesi
• Devir oranı: Hangi niyetlerde devre gidiyor?
• İlk yanıt süresi: Bot anlık olmalı; gecikme varsa entegrasyon sorunu vardır
• CSAT / kısa memnuniyet: 1 soru yeter (ör. “Yardımcı oldu mu?”)
• Containment vs kalite dengesi: Çözüm oranı artarken şikayet artıyorsa yanlış şey çözüyorsunuz demektir

Raporlama sıklığı: ilk 4 hafta haftalık, sonra aylık. Büyük değişikliklerde tekrar haftalık.

Kalite kontrol ve konuşma inceleme

Bot konuşmalarını rastgele incelemek şart. Çünkü metrikler bazen “yanlış başarı”yı gösterir: kullanıcı pes edip çıkmıştır, bot bunu çözüm sayar.

Kalite rutini:

• Haftada 30–50 oturum örneklemesi (hacme göre).
• 3 etiket: doğru yönlendirdi, yanlış yönlendirdi, gereksiz uzattı.
• En çok kaçırılan intent listesi çıkarın.

İnceleme sırasında özellikle şu sinyalleri arayın: kullanıcı aynı şeyi tekrar yazıyor mu, “temsilci” diyor mu, uzun boşluklar var mı.

Eğitim güncellemeleri ve bilgi bakımı

Kural tabanlı botta eğitim “akış güncelleme”dir. LLM botta eğitim çoğu zaman “bilgi tabanını düzeltme” ve prompt kurallarını iyileştirmedir.

Bakım planı:

• Haftalık: yeni çıkan 5 soru, yanlış yanıtlar
• Aylık: intent listesi revizyonu, yeni akış ekleme
• 3 ayda bir: kanal performansı karşılaştırma (web vs WhatsApp)

Bilgi içeriklerini WebP görsel, hızlı sayfa yükleme gibi teknik detaylarla da iyileştirmek faydalı olur. Yardım merkezi sayfalarında görselleri 200KB altı tutmak gibi basit kurallar, kullanıcı deneyimini etkiler.

Sürümleme ve geri alma planı

Bot değişiklikleri bazen performansı düşürür. Bu yüzden sürümleme ve geri alma (rollback) planı olmalı.

Minimum uygulama:

• Her değişikliği bir sürüm notu ile kaydedin (ne değişti, neden).
• Büyük değişiklikleri A/B yapamıyorsanız, en azından kademeli yayınlayın (trafik %10 → %50 → %100).
• Kritik hata durumunda eski sürüme dönme adımı 10 dakikada yapılabilmeli.

Bu disiplin, botu “deneme-yanılma oyuncağı” olmaktan çıkarır, operasyonel bir kanala dönüştürür.

Supporting Article Potential:

• Chatbot KPI seti: Self-servis çözüm oranı mı CSAT mi? Dengeli raporlama şablonu
• Konuşma kalite inceleme süreci: Haftalık 50 oturumla gerçek iyileştirme nasıl yapılır?
• Chatbot sürümleme ve rollback: Kademeli yayın stratejisi ve risk azaltma