Web sitesine canlı sohbet eklemek, “bir chat kutusu koyup beklemek” değil. Doğru kurgulanırsa satış öncesi soruları hızla yanıtlar, destek yükünü dengeler, iade ve memnuniyetsizliği azaltır. Yanlış kurgulanırsa da tam tersi olur: ekip boğulur, kullanıcılar sinirlenir, chatbot gereksiz döngülere girer, KVKK riski doğar.
Bu rehber; e-ticaret yöneticileri, destek ekip liderleri, ürün ve büyüme ekipleri ile ajansların, web sitesi için canlı destek ve chatbot kurulumunu stratejiden operasyona doğru kurabilmesi için yazıldı. Amaç; niyet sınıflandırmasından başlayıp, kanal seçimi, senaryo tasarımı, iş akışları, bot-temsilci orkestrasyonu, ekip planı, SLA, KVKK, güvenlik, entegrasyon, KPI ve sürekli iyileştirme döngüsüne kadar “çalışan sistem” kurmak.
Kurulum adımlarını daha uygulamalı görmek isterseniz canlı destek kurulumu ve yönetimi rehberi içeriğini de referans alabilirsiniz. Chatbot tarafında ise chatbot nedir ve canlı destekle nasıl çalışır yazısı iyi bir başlangıç noktasıdır.
Table of Contents
- Niyet Sınıflandırması
- Kanal ve Platform Seçimi
- Kullanım Senaryosu Tasarımı
- İş Akışı Kurgusu
- Chatbot Temsilci Orkestrasyonu
- Ekip ve Vardiya Planı
- SLA ve Yanıt Standartları
- Gizlilik ve KVKK Kontrolleri
- Güvenlik ve Moderasyon Kontrolleri
- Entegrasyon ve Veri Akışı
- Raporlama ve KPI Seti
- Sürekli İyileştirme Döngüsü
Niyet Sınıflandırması
Canlı sohbeti verimli yapan şey, gelen mesajı “kim yazdı?”dan önce “neden yazdı?” diye sınıflandırmaktır. Niyet sınıflandırması; senaryo tasarımını, bot kapsamını, kuyruk önceliğini, SLA hedeflerini ve raporlamayı tek bir çatı altında toplar. Pratikte üç ana sınıf yeterli olur: destek, satış, topluluk/sosyal.
Destek niyeti belirtileri ve hedefleri
Destek niyeti genelde bir problem, belirsizlik veya işlem takibiyle gelir. Mesaj örnekleri: “Siparişim gelmedi”, “İade nasıl yapılıyor?”, “Ödeme hata verdi”, “Şifremi unuttum”. Belirtiler net: geçmiş işlem referansı (sipariş no), hata ekranı, aciliyet.
Hedefler:
- İlk temas çözüm oranını yükseltmek (FCR). Bunun için temsilciyi doğru bilgiye hızlı ulaştırmak gerekir.
- Gerekli veriyi doğru almak: sipariş no, e-posta/telefon gibi doğrulama alanları. Fazlasını istememek.
- “Destek” konuşmalarında satış baskısı yaratmamak. Kullanıcı zaten stresli olabilir.
Uygulama ipucu: destek niyeti tespiti için mesaj içeriğindeki anahtar kelimeleri (iade, kargo, hata, iptal) etiketleyin ve widget’ta ilk soruyu buna göre uyarlayın. “Ne ile ilgili?” sorusunu 3 seçenekle sınırlamak, serbest metinden daha temiz sınıflandırma üretir.
Satış niyeti belirtileri ve hedefleri
Satış niyeti; ürün karşılaştırma, stok, teslimat süresi, kampanya, fiyat, taksit, uyumluluk gibi satın alma kararına yakın sorulardır. Mesaj örnekleri: “Bu ürün şu modelle uyumlu mu?”, “Bugün sipariş verirsem ne zaman gelir?”, “Kupon nasıl uygulanıyor?”
Hedefler:
- Karar süresini kısaltmak: ürün sayfasına gömülü bilgi (kargo süresi, iade koşulu, ödeme seçenekleri) hazır olmalı.
- Sepet terkini azaltmak: ödeme adımında “yardım” tetikleyicisi.
- Uygun olduğunda lead toplamak: B2B’de “demo talebi” veya “teklif” akışı.
Satış niyetinde sohbetin başarısı, konuşmayı uzatmak değil; doğru CTA’yı doğru anda vermektir. Temsilciye ürün linki, karşılaştırma tablosu ve net teslimat bilgisi sunacak makrolar hazırlayın. Bot, fiyat pazarlığına girmemeli; kampanya koşullarını net aktarmalı.
Topluluk ve sosyal niyet sınırları
Bazı mesajlar destek de satış da değildir: “Merhaba”, “Sohbet edelim”, uygunsuz içerik, trolleme, spam. Bu sınıfın yönetimi, ekibin zamanını korumak için kritiktir.
Sınırlar:
- Canlı sohbeti “sosyal chat”e çevirmeyin. Widget’ta amaç beyanı net olsun: “Sipariş, ürün ve destek için yazın.”
- Uygunsuz dil için moderasyon kuralı: tek uyarı, sonra kapatma. Kapanış metni standart olmalı.
- Spam ve bot trafiği için rate limit ve captcha benzeri kontrolleri değerlendirin.
Burada hedef operasyonel koruma. Topluluk niyeti büyürse, ayrı kanal açmak (ör. Discord, forum) daha doğru olur; canlı destek ekibine bindirmeyin.
Supporting Article Potential:
- Canlı sohbette niyet sınıflandırması nasıl yapılır? Etiketleme ve örnek akışlar
- Destek vs satış konuşmalarında farklı SLA ve dil standardı nasıl kurulur?
- Canlı sohbet spam ve sosyal mesajları operasyonu nasıl bozar, nasıl engellenir?
Kanal ve Platform Seçimi
Canlı sohbet “hangi araç?” sorusundan önce “hangi kanal, hangi bağlam?” sorusudur. Web widget, mobil SDK, WhatsApp, Instagram DM, e-posta, helpdesk formu… Hepsi aynı konuşma gibi görünür ama beklenti ve hız farklıdır. Yanlış kanal seçimi, iyi ekibi bile başarısız gösterir.
Web sitesi widget gereksinimleri
Web widget seçerken kontrol listesiyle ilerleyin. Sadece tema ve fiyat değil, operasyon kabiliyeti önemlidir:
- Performans: script yükü düşük olmalı; sayfa hızını bozmayın. Görsel ve dosyalar mümkünse 200KB altı, WebP tercih edin; widget da benzer şekilde hafif olmalı.
- Tetikleyiciler: sayfa bazlı açılma, sepette bekleme süresi, çıkış niyeti (exit intent) gibi kurallar.
- Form + sohbet hibriti: “Mesaj bırak” modu, dosya ekleme, konu seçimi.
- Çoklu dil ve çalışma saatleri: saat dışı otomatik yönlendirme.
- Yetkilendirme: kullanıcı girişliyse müşteri profilini tanıyabilme.
- Entegrasyon: CRM/helpdesk, e-ticaret olayları, webhook.
Araç örnekleri: Intercom, Zendesk, Freshdesk, Tawk.to. Seçim yaparken “en iyisi hangisi?” yerine, mevcut stack ve süreçle uyumuna bakın.
Mobil uygulama ve web farkları
Mobilde canlı sohbet aynı akışla çalışmaz. Bildirim, giriş durumu, bağlantı kopması, küçük ekran tasarımı gibi farklar doğrudan metrikleri etkiler.
Pratik farklar:
- Mobilde konuşma daha parçalıdır. Bu yüzden bot mesajlarını kısa tutun, seçenekleri 3–5 aralığında sınırlayın.
- Push bildirim şart. Yoksa kullanıcı konuşmayı yarıda bırakır.
- Uygulama içi kimlik doğrulama daha kolaydır. Sipariş ekranından sohbet açılıyorsa, sipariş ID’yi otomatik taşıyın. Bu temsilci süresini ciddi düşürür.
- Dosya ve ekran görüntüsü gönderimi mobilde daha yaygındır; güvenlik ve KVKK tarafını buna göre planlayın.
Web ve mobilde aynı bilgi tabanı kullanılabilir, ama tetikleyici kuralları ve mesaj tasarımı farklı olmalı.
Ajans ve KOBİ için seçim kriterleri
KOBİ ile ajansın ihtiyacı aynı değil. Ajans; çoklu müşteri, rol yönetimi, kurulum templateları ister. KOBİ ise hızlı kurulum ve düşük bakım yükü arar.
Aşağıdaki tablo karar vermeyi hızlandırır:
| Kriter | KOBİ Önceliği | Ajans Önceliği |
|---|---|---|
| Kurulum süresi | Hızlı, hazır şablon | Tekrar edilebilir kurulum |
| Çoklu marka | Genelde yok | Zorunlu |
| Raporlama | Temel KPI | Müşteri bazlı detay |
| Yetki/rol | Basit | İnce yetkilendirme |
| Entegrasyon | 1–2 kritik sistem | Farklı stack’ler |
| Maliyet modeli | Öngörülebilir | Ölçeklenebilir |
Ajans tarafında teslim modeli de önemlidir: müşteri hesabı mı açılacak, ajans mı yönetecek, kim veri sorumlusu olacak? Bu soruları en başta netleştirin.
Supporting Article Potential:
- Web canlı sohbet widget seçim kontrol listesi (performans, tetikleyici, entegrasyon)
- Mobil uygulamada canlı chat kurulumunda en sık yapılan 10 hata
- Ajanslar için çoklu müşteri canlı destek kurulumu: hesap, rol ve raporlama modeli
Kullanım Senaryosu Tasarımı
Senaryo tasarımı, canlı sohbetin “konuşma” değil ürün akışı olduğunu kabul ettiğiniz noktadır. Her sayfa, her adım aynı konuşmayı hak etmez. Senaryoları müşteri yolculuğuna oturtun; satış öncesi, destek, self servis ve form tetikleri ayrı ele alın.
E ticaret satış öncesi senaryoları
Satış öncesi senaryolar, en hızlı gelir etkisi yaratan alandır. Ama agresif tetikleyiciyle değil, doğru sayfada doğru yardım ile.
Örnek senaryolar:
- Ürün sayfası: “Uyumluluk / ölçü / garanti” soruları için 3 seçenekli hızlı menü.
- Kargo ve teslimat: kullanıcının şehrine göre teslimat penceresi. Bilgi yoksa “posta kodu” isteyip hesaplayın.
- Sepet: kupon uygulama yardımı, taksit seçenekleri, iade koşulu özeti.
- Checkout: ödeme hatasında ekran görüntüsü + hata kodu isteme, ardından temsilciye hızlı devir.
Kural: Satış öncesi bot mesajı tek ekran okunabilir olmalı. Uzun açıklamayı linkleyin (SSS, kargo sayfası). Temsilciye devir gerekiyorsa, bağlamı taşıyın: hangi ürün, hangi varyant, sepet tutarı.
Destek talebi karşılama senaryoları
Destek senaryosu; doğru veri toplama + doğru kuyruğa yönlendirmedir. En çok kayıp, “sipariş numarası alınmadan” temsilciye düşen konuşmalarda olur.
Minimum destek triage akışı:
- Konu seçimi: Kargo, iade, ödeme, ürün sorunu, hesap.
- Kimlik doğrulama: girişli kullanıcıdan otomatik; değilse e-posta/telefon.
- İşlem referansı: sipariş no veya takip no.
- Aciliyet: “Bugün teslimat bekliyordum” gibi sinyalleri etiketleyin.
Burada amaç, temsilcinin “5 soru sorup” konuya girmesini engellemek. İyi triage, ortalama çözüm süresini düşürür ve SLA’yı gerçekçi kılar.
Form ve self servis tetikleyicileri
Canlı sohbet her şeyi çözmemeli. Bazı konular form veya self servisle daha iyi çözülür: fatura talebi, teknik inceleme, iade belgesi yükleme, resmi talepler.
İyi tetikleyiciler:
- Çalışma saatleri dışında sohbet açılırsa “mesaj bırak” + konu seçimi + dönüş süresi beklentisi.
- Aynı kullanıcı 2 dakika içinde 3 kez aynı sayfaya dönerse SSS önerisi.
- İade sayfasında sohbet yerine “iade başlat” butonu ve adım adım self servis.
Self servis içerikleri düzenli güncellenmiyorsa canlı sohbet “yardım merkezi”ne yönlendirdiğinde kullanıcı daha çok sinirlenir. Bu yüzden SSS sayfalarını 12–18 ay döngüsünde yenileyin; en çok aranan 20 soruyu her çeyrekte kontrol edin.
Supporting Article Potential:
- E-ticarette canlı sohbet tetikleyicileri: ürün, sepet ve ödeme sayfası için örnek kurallar
- Destek triage akışı nasıl kurulur? Sipariş no toplama ve doğru yönlendirme
- Canlı sohbet mi form mu? Hangi talep hangi kanala gitmeli?
İş Akışı Kurgusu
İş akışı; kullanıcı deneyimi kadar ekip deneyimini de belirler. Net kurallar yoksa sohbet “herkesin baktığı ama kimsenin sahiplenmediği” kuyruk olur. Burada üç alanı disipline edin: karşılama-yönlendirme, kuyruk-öncelik, devir-kapanış.
Karşılama ve yönlendirme adımları
Karşılama metni, marka dili değil; operasyonel netlik taşımalı. Kullanıcıya iki şeyi söyleyin: neye yardımcı olabilirsiniz, ne kadar sürede döneceksiniz.
Önerilen giriş yapısı:
- “Sipariş, iade ve ürün soruları için buradayız.”
- “Ortalama yanıt süremiz: 2–5 dakika.”
- Hızlı seçenekler: “Sipariş takibi / İade / Ürün sorusu / Ödeme sorunu”
Yönlendirmede kritik nokta: konuşmayı erken etiketlemek. Etiket yoksa raporlar çöker, bot eğitimi zorlaşır, SLA yönetimi bulanıklaşır.
Kuyruk ve öncelik kuralları
Kuyruklar, organizasyon şemasını değil müşteri ihtiyacını yansıtmalı. Çok fazla kuyruk yönetimi zorlaştırır; çok az kuyruk uzmanlaşmayı engeller. Çoğu ekip için 3–5 kuyruk yeterlidir: Satış, Sipariş/Kargo, İade, Teknik, VIP.
Öncelik sinyalleri:
- VIP müşteri, yüksek sepet, abonelik yenileme gibi etiketler.
- “Ödeme alındı ama sipariş oluşmadı” gibi kritik hata türleri.
- SLA riski: bekleme süresi eşik aşımı.
Kural örneği: 10 dakikayı geçen sohbet otomatik “yüksek öncelik” olur ve daha kıdemli temsilciye yönlenir. Bu basit kural, kaçan konuşmaları azaltır.
Devir ve kapanış kuralları
Devir (handoff) tasarımı, bot ve temsilci arasında olduğu kadar temsilciler arasında da gerekir. Devirde hedef, kullanıcının kendini tekrar etmesini engellemektir.
Devir standardı:
- Özet: 1–2 cümle
- Etiketler: konu, ürün, sipariş no
- Yapılanlar: denenen adımlar
- Beklenen aksiyon: iade başlatma, kargo sorgulama, teknik inceleme
Kapanış kuralı:
- Çözüm teyidi: “Bu adımla sorun çözüldü mü?”
- Takip gerekiyorsa net söz: “Bugün 16:00’ya kadar e-posta ile döneceğiz.”
- Sohbeti kapatma: kullanıcı yanıt vermiyorsa 2 hatırlatma + 5 dakika sonra otomatik kapanış (süreyi işinize göre ayarlayın).
Supporting Article Potential:
- Canlı sohbette kuyruk tasarımı: kaç kuyruk yeterli, nasıl isimlendirilir?
- Handoff (devir) standardı: bot → temsilci ve temsilci → temsilci için şablonlar
- Sohbet kapanış kuralları ve otomatik kapanış süreleri nasıl belirlenir?
Chatbot Temsilci Orkestrasyonu
Chatbot eklemek, canlı destek ekibini küçültmekten önce trafik şekillendirme işidir. Botun sınırlarını iyi çizmezseniz ya temsilciye hiç iş bırakmaz (kalite düşer) ya da hiçbir şeyi çözemez (kullanıcı sinirlenir). Orkestrasyon; kapsam, devir koşulları ve bilgi akışı üçlüsünden oluşur.
Bot kapsamı ve sınırları
Botun iyi olduğu alanlar:
- Tekrarlayan SSS: kargo süresi, iade koşulu, ödeme seçenekleri
- Basit yönlendirme: doğru form, doğru sayfa, doğru kuyruk
- Veri toplama: sipariş no, e-posta, konu seçimi
- Durum sorgu: entegrasyon varsa sipariş/kargo durumu
Botun kötü olduğu alanlar:
- Müşteri öfkesi ve kriz yönetimi
- Karmaşık iade istisnaları
- Pazarlık, özel fiyat, kurumsal teklif
- Kimlik doğrulama gerektiren hassas işlemler
Sınır kuralı koyun: bot, 2 başarısız anlama denemesinden sonra “temsilciye bağlayayım” demeli. “Sürekli aynı soruyu sorma” botların en yaygın hatası.
Temsilciye devir koşulları
Devir koşulları “kullanıcı isterse” ile sınırlı olmamalı. Sistem, riskli durumları otomatik algılayıp devretmeli.
Örnek devir tetikleri:
- Duygu sinyali: “şikayet”, “mahkemeye”, “dolandırıcılık” gibi kelimeler
- Yüksek değer: sepet tutarı belli bir eşik üstü (işinize göre)
- Kimlik doğrulama ihtiyacı: adres değişikliği, ödeme itirazı
- Botun güven puanı düşük: “emin değilim” durumları
Devir anında temsilciye “konuşma özeti” düşürün. Bu özet yoksa temsilci ilk 2 dakikayı toparlamaya harcar; kullanıcı da “yine mi anlatacağım” der.
Bilgi tabanı ve eğitim verisi akışı
Chatbot kalitesi, modelden çok bilgi tabanı disiplinine bağlıdır. İçerik dağınıksa bot dağılır.
İyi bir bilgi akışı:
- Tek kaynak: yardım merkezi/SSS sayfaları birincil kaynak olsun.
- Parçalama: uzun iade politikası yerine, botun okuyacağı 6–10 kısa madde üretin.
- Versiyonlama: kampanya ve kargo süreleri değişince eski içerik kalmasın.
- Geri besleme: temsilci konuşmalarından “cevap bulunamadı” etiketli konuları haftalık listeleyin.
AI tabanlı bot kullanıyorsanız, eğitim verisinde müşteri verisi kullanırken KVKK tarafını ayrıca kontrol edin. Bu konuda daha fazla perspektif için AI ve chatbot içerikleri kategorisine göz atabilirsiniz.
Supporting Article Potential:
- Chatbot kapsamı nasıl belirlenir? Yapabilecekleri ve yapmaması gerekenler
- Bot → temsilci devir tetikleri: duygu, risk ve değer bazlı kurallar
- Bilgi tabanı yönetimi: chatbot kalitesini artıran içerik operasyonu
Ekip ve Vardiya Planı
Canlı sohbetin başarısı, “kaç kişi var”dan çok ne zaman, hangi yetkinlikte kişinin hazır olduğudur. Vardiya planı yoksa SLA kâğıt üzerinde kalır. Ajans modelinde ise iş daha da karmaşıklaşır: kim yanıtlıyor, kim raporluyor, kim sorumlu?
Rol ve sorumluluk dağılımı
Minimum rol seti:
- L1 Temsilci: standart sorular, triage, basit çözümler
- L2 Uzman: iade istisnaları, teknik konular, kriz yönetimi
- Takım lideri: kuyruk dengeleme, kalite kontrol, vardiya yönetimi
- Bot/KB sorumlusu: makro, bilgi tabanı, bot akışları
Net sorumluluk kuralı: Her kuyrukta “sahip” olmalı. Sahip yoksa konuşmalar sürünür. Ayrıca satış konuşmaları ile destek konuşmalarını aynı kişiye yıkmak genelde kaliteyi düşürür; en azından saat bazlı ayrım yapın.
Vardiya kapsama ve yoğunluk planı
Vardiya planını sezgiyle değil veriye yakın şekilde kurun. En basit yaklaşım:
- Trafiği saatlik çıkarın: en yoğun 3 saat, en sakin 3 saat.
- Ortalama sohbet süresini ölçün.
- Aynı anda yönetilebilir sohbet sayısını belirleyin: çoğu ekipte kişi başı 2–3 eşzamanlı sohbet üst sınırdır (karmaşıksa 2).
Basit kapasite hesabı: yoğun saatlerde gelen sohbet sayısı, eşzamanlı kapasiteyi aşıyorsa ya vardiya ekleyin ya da bot/self servis ile kırpın. “Herkes aynı anda 6 sohbet baksın” yaklaşımı hızlı gibi görünür ama hata ve memnuniyetsizlik üretir.
Ajans teslim modeli sorumlulukları
Ajanslar için kritik konu: hesap sahipliği ve veri sorumluluğu. Operasyonel olarak şu soruları sözleşme öncesi netleştirin:
- Araç lisansı kimin adına?
- Konuşma verisi kimde kalıyor?
- Makro ve bot akışlarını kim güncelliyor?
- SLA ihlalinde sorumluluk kimde?
- Müşteri tarafında ürün/kampanya bilgisi güncellenmezse süreç nasıl ilerler?
Ajans için en sağlıklı model: müşteri tarafında “içerik ve kampanya sahibi” bir kontaktan haftalık güncelleme almak, ajansın da operasyon ve raporlamayı yürütmesidir. Aksi halde canlı sohbet, bilgi güncelliği yüzünden patlar.
Supporting Article Potential:
- Canlı sohbet ekip rolleri: L1/L2 ayrımı ve liderlik kontrol listesi
- Vardiya planı nasıl yapılır? Eşzamanlı sohbet kapasitesi ve yoğunluk hesabı
- Ajanslar için canlı destek teslim modeli: sorumluluk, sözleşme ve raporlama
SLA ve Yanıt Standartları
SLA sadece “hız” değildir. Hız, doğrulukla birleşmezse maliyet artar. Bu bölümde SLA hedeflerini gerçekçi kurmak, dil standardını netleştirmek ve makroları kontrollü kullanmak esastır.
İlk yanıt ve çözüm hedefleri
İki temel hedef belirleyin:
- İlk yanıt süresi: kullanıcı “görüldü” hissi alır.
- Çözüm süresi: işin gerçekten bittiği an.
Pratik hedefler (başlangıç için):
- Satış niyeti: ilk yanıt 1–3 dakika
- Destek niyeti: ilk yanıt 3–5 dakika
- Çözüm: konuya göre değişir; iade gibi süreçlerde aynı gün dönüş taahhüdü daha gerçekçidir.
Önemli: SLA’yı çalışma saatleriyle bağlayın. Saat dışı gelen konuşmada “ilk yanıt 2 dakika” yazıp 12 saat sonra dönmek güven kaybıdır. Widget’ta çalışma saatlerini ve beklenen dönüş süresini açık gösterin.
Ton ve yazım kuralları
Canlı sohbet dili e-posta gibi olamaz. Kısa, net, adım adım. Kuralları yazılı hale getirin:
- 1 mesaj = 1 konu. Aynı balonda 5 soru sormayın.
- Kullanıcıyı suçlamayın: “Yanlış yapmışsınız” yerine “Şu adımda takılmış olabiliriz”.
- Teknik terimi azaltın; gerekiyorsa parantez içinde açıklayın.
- Gereksiz samimiyet zorlamayın. Destek konuşmalarında “aşırı neşeli” ton ters tepebilir.
Dil standardı, özellikle ajans ve vardiyalı ekiplerde kaliteyi sabitler.
Makro ve şablon kullanım sınırları
Makrolar hız kazandırır, ama kör kullanılırsa kullanıcıyı uzaklaştırır. Sınır koyun:
- Makro mesajları kişiselleştirin: ad, sipariş no, ürün adı alanları otomatik dolsun.
- Aynı konuşmada 2’den fazla uzun makro kullanmayın; araya temsilci cümlesi girsin.
- Makroları 3 sınıfa ayırın: Bilgi, İstenen Veri, İşlem Adımı.
Makro yönetimi için aylık temizlik yapın: kullanılmayanları kapatın, yanlış yönlendirenleri düzeltin. Makro sayısı büyüdükçe kalite düşer; çoğu ekip için 30–60 arası makro yeterlidir.
Supporting Article Potential:
- Canlı sohbette SLA nasıl belirlenir? Çalışma saatleri ve niyete göre hedefler
- Canlı destek yazım dili rehberi: kısa mesaj, adım adım çözüm, kriz dili
- Makro yönetimi: şablon sayısı, kişiselleştirme ve kalite kontrol
Gizlilik ve KVKK Kontrolleri
Canlı sohbet, kişisel veri toplamanın en hızlı yollarından biri. Bu yüzden KVKK tarafını “sonradan bakarız” diyemezsiniz. Aydınlatma metni, açık rıza gerektiren noktalar, veri minimizasyonu, saklama süresi ve erişim talepleri süreci baştan planlanmalı.
Not: Bu bölüm hukuki danışmanlık değildir; uygulama tasarımında kontrol noktalarını doğru konumlandırmaya odaklanır. Kurumunuzun hukuk ekibiyle birlikte netleştirin.
Aydınlatma ve açık rıza temas noktaları
Aydınlatma yükümlülüğü için kullanıcıya, sohbet başlamadan veya en geç ilk temas sırasında, verinin hangi amaçla işlendiğini bildirmek gerekir. Pratik temas noktaları:
- Widget ilk açılışında kısa bilgilendirme + “detaylar” linki
- Sohbet formunda (e-posta/telefon isteniyorsa) aydınlatma linki
- Pazarlama amaçlı iletişim varsa ayrıca açık rıza kutusu (destek için zorunluymuş gibi sunmayın)
Özellikle “kampanya, bülten, SMS” gibi pazarlama izinlerini destek akışına gizlemek, şikayet riskini büyütür. Ayrıştırın.
Veri minimizasyonu ve saklama süreleri
Kural basit: ihtiyacın olmayan veriyi isteme. Sipariş takibi için TCKN istemek gibi örnekler hem kullanıcıyı kaçırır hem risk yaratır.
Uygulama prensipleri:
- Destek için zorunlu alanları minimumda tutun: e-posta/telefon + sipariş no çoğu zaman yeter.
- Özel nitelikli veriyi (sağlık, biyometri vb.) istemeyin; gelirse maskeleme ve silme prosedürü belirleyin.
- Saklama süresini belirleyin: konuşma kayıtları, loglar, dosya ekleri farklı sürelerde tutulabilir. “Süresiz sakla” yaklaşımı genelde savunulamaz.
Araç tarafında otomatik silme politikası veya arşivleme kuralı yoksa, bunu süreçle kapatmanız gerekir.
Kayıt ve erişim talepleri süreçleri
Kullanıcı “Hakkımda tuttuğunuz verileri gönderin/silin” dediğinde ne olacak? Canlı sohbet sisteminiz bu talepleri yönetebilmeli.
Minimum süreç:
- Talep kanalı: e-posta veya form; canlı sohbetten talep alınırsa kayıt altına alınır.
- Kimlik doğrulama: yanlış kişiye veri vermeyin.
- Sistem taraması: chat aracı + CRM + helpdesk.
- Yanıt şablonu ve süre takibi.
Bu süreçler yazılı değilse, talepler ekip içinde kaybolur. KVKK tarafında risk genelde “kötü niyet”ten değil, dağınıklıktan çıkar.
Supporting Article Potential:
- Canlı sohbette KVKK temas noktaları: aydınlatma metni ve açık rıza nerede olmalı?
- Veri minimizasyonu: canlı destekte hangi alanlar gerçekten gerekli?
- KVKK erişim/silme talepleri canlı sohbet kayıtlarında nasıl yönetilir?
Güvenlik ve Moderasyon Kontrolleri
Canlı sohbet; kimlik doğrulama, yetkilendirme, kötüye kullanım ve kayıt güvenliği açısından hem saldırı yüzeyi hem de iç denetim alanıdır. “Sadece chat” diye hafife alınır ama özellikle sipariş ve hesap işlemlerinde ciddi risk taşır.
Kimlik doğrulama ve yetkilendirme
Kullanıcıyı doğrulamadan işlem yapmayın. En sık hata: sohbetten “adres değiştirir misiniz?” talebini doğrulamasız yapmak.
Pratik yaklaşım:
- Girişli kullanıcı: oturum bilgisiyle bağlayın, ama yine de kritik işlemde ek doğrulama isteyin.
- Girişsiz kullanıcı: sipariş no + e-posta/telefon eşleşmesi olmadan işlem yapmayın.
- Temsilci yetkileri: iade onayı, kupon tanımlama, adres değişikliği gibi aksiyonları role bağlayın.
Yetkilendirme sadece kullanıcı için değil, temsilci için de geçerli. Her temsilci her işlemi yapmamalı.
Kötüye kullanım ve spam önleme
Spam, hem maliyet hem moral bozar. Basit kontrollerle ciddi fark yaratırsınız:
- IP bazlı hız limiti: kısa sürede çok sohbet açanı engelleyin.
- Aynı mesajın tekrarını algılama: kopyala-yapıştır spam.
- Link ve küfür filtreleri: otomatik uyarı ve kapatma.
- Bot koruması: form alanlarında basit doğrulama.
Moderasyon metnini standartlaştırın. Temsilciye “tartışma” görevi vermeyin. Uyarı metni kısa olmalı, kapatma gerekçesi net olmalı.
Kayıt güvenliği ve denetim izi
Sohbet kayıtları, hem müşteri şikayetinde hem iç denetimde delildir. Bu yüzden denetim izi (audit trail) önemlidir:
- Kim, hangi kaydı ne zaman görüntüledi?
- Kim, hangi konuşmayı sildi veya maskeledi?
- Hangi entegrasyonla veri aktı?
Ayrıca dosya ekleri risklidir: ekran görüntüsü içinde kart bilgisi veya adres olabilir. Dosya eklerini otomatik maskeleme mümkün değilse, temsilci yönergesi yazın: “Kart bilgisi göndermeyin”, “Hassas bilgi varsa silme talebi açın” gibi.
Supporting Article Potential:
- Canlı sohbette kimlik doğrulama: hangi işlemler için ek doğrulama gerekir?
- Spam ve kötüye kullanım önleme: canlı destek operasyonunu koruyan kurallar
- Denetim izi ve kayıt güvenliği: canlı sohbet logları nasıl yönetilir?
Entegrasyon ve Veri Akışı
Canlı sohbet tek başına kalırsa “konuşma kutusu” olur. Entegrasyonla birlikte iş sistemine dönüşür: CRM’de müşteri profili güncellenir, helpdesk’te kayıt açılır, e-ticaret olayları tetiklenir, raporlama gerçekçi hale gelir.
CRM ve helpdesk veri eşlemesi
İki temel model var:
- Chat → Ticket: her konuşma bilet olur (destek ağırlıklı ekipler)
- Chat → Event: sadece belirli koşullarda bilet açılır (satış ağırlıklı veya düşük hacim)
Eşleme yaparken alanları netleştirin:
- Kimlik: e-posta, telefon, müşteri ID
- İşlem: sipariş ID, iade ID
- Bağlam: sayfa URL, ürün ID, kampanya kodu
- Sınıflandırma: etiketler, konu, öncelik
Araçlar arasında alan isimleri farklı olabilir; bir “mapping dokümanı” hazırlayın. Bu doküman, entegrasyon bozulduğunda sorunu hızlı buldurur.
E ticaret olayları ve tetikleyiciler
E-ticarette canlı sohbeti güçlendiren şey, olay verisidir. Örnek olaylar:
- Sepete ekleme
- Checkout başlatma
- Ödeme hatası
- Kargo durumu değişimi
- İade başlatma
Bu olayları sohbet sistemine taşırsanız:
- Temsilci, “ne yaşandı?”yı görür.
- Bot, doğru akışı başlatır.
- Raporlama, sohbetin satışa etkisini daha doğru ölçer.
Kural: Olay verisi geldiğinde, kullanıcıyı rahatsız eden otomatik mesajlara boğmayın. Tetikleyiciler sınırlı ve anlamlı olmalı.
Etiketleme ve kategori veri modeli
Raporlama ve iyileştirme için veri modeli şart. Etiketler rastgele olursa KPI’lar çöp olur.
İyi etiket modeli:
- Niyet: satış, destek, sosyal
- Konu: kargo, iade, ödeme, ürün uyumu, hesap
- Sonuç: çözüldü, bilet açıldı, devredildi, kullanıcı terk etti
- Kalite: yanlış yönlendirme, eksik bilgi, memnuniyetsizlik sinyali
Etiket sayısını kontrol edin. 200 etiketli sistem yönetilmez. Başlangıç için 20–40 etiket aralığı iyi çalışır; her ay gereksizleri budayın.
Supporting Article Potential:
- Canlı sohbeti CRM ve helpdesk’e bağlama: alan eşleme ve ticket stratejisi
- E-ticaret olay verisiyle canlı sohbet tetikleyicileri nasıl kurulur?
- Etiketleme veri modeli: raporlama ve bot eğitimi için sürdürülebilir yapı
Raporlama ve KPI Seti
Raporlama; canlı sohbetin “hissettirdiği” etkiyi değil, gerçek etkisini gösterir. KPI setini üçe ayırın: operasyon, satış dönüşümü, kalite. Bu ayrım olmazsa ekip hız için kaliteyi feda eder ya da satış için destek kuyruğunu yakar.
Operasyon KPIları ve ekip verimliliği
Operasyon KPI’ları, kapasite ve süreç sağlığını ölçer:
- İlk yanıt süresi (median + p90)
- Çözüm süresi / konuşma süresi
- Backlog: bekleyen sohbet sayısı
- Eşzamanlı sohbet yükü: temsilci başına ortalama
- Devir oranı: bot→temsilci ve L1→L2
- Kaçırılan sohbet oranı
Sadece ortalamaya bakmayın. p90 (en kötü %10) genelde müşteri şikayetlerini açıklar. Ayrıca hedef koyarken ekip kapasitesiyle uyumlu olmalı; aksi halde temsilciler “hızlı kapat” davranışına kayar.
Satış dönüşüm KPIları ve etki ölçümü
Satış etkisini ölçmek zordur ama imkansız değil. Net tanımlar gerekir:
- Chat başlatanların satın alma oranı (chat vs non-chat)
- Chat kaynaklı gelir: konuşma sonrası belirli süre içinde satın alma (attribüsyon kuralı şart)
- Sepet terk oranı: chat müdahalesi olan vs olmayan
- Lead dönüşümü: B2B’de demo/teklif formu tamamlanma oranı
Attribüsyon penceresini belirleyin (ör. 24 saat, 7 gün). Tek bir “doğru” yok; önemli olan tutarlılık. A/B test ile de destekleyin: belirli sayfalarda widget’ı kapatıp farkı izlemek gibi.
Kalite KPIları ve müşteri memnuniyeti
Kaliteyi ölçmeden ölçeklemek risklidir. Kullanılabilir metrikler:
- CSAT (sohbet sonrası 1–5)
- NPS (daha geniş programın parçasıysa)
- QA skoru: örneklem konuşma incelemesi
- Tekrar iletişim oranı: aynı konu için 7 gün içinde tekrar yazma
- Negatif duygu etiketleri: “şikayet”, “iptal” vb.
CSAT toplarken anketi yormayın: 1 soru + opsiyonel yorum yeterli. Anketi her konuşmada sormak yerine, çözümle kapanan konuşmalarda sormak daha temiz veri verir.
Supporting Article Potential:
- Canlı sohbet KPI seti: operasyon metrikleri ve p90 yaklaşımı
- Canlı sohbetin satışa etkisi nasıl ölçülür? Attribüsyon ve A/B test mantığı
- CSAT ve kalite kontrol: konuşma inceleme (QA) süreci nasıl kurulur?
Sürekli İyileştirme Döngüsü
Canlı sohbet sistemi, kurulduğu gün eskiyebilir. Kampanya değişir, kargo süreleri oynar, ürün gamı büyür, kullanıcı dili evrilir. Bu yüzden sürdürülebilir başarı, düzenli inceleme, bot/makro güncellemesi ve kontrollü deneylerle gelir.
Haftalık inceleme ve aksiyon listesi
Haftalık ritim, küçük ekiplerde bile fark yaratır. 45–60 dakikalık toplantı yeter.
Haftalık ajanda:
- SLA sapmaları: hangi saatler patladı?
- Kaçırılan sohbetler: neden kaçtı (vardiya, tetikleyici, spam)?
- Top 10 konu: etiketlere göre
- “Cevap bulunamadı” listesi: bot ve temsilci tarafında
- 3 aksiyon: sahip + tarih
Aksiyon sayısını sınırlayın. 20 madde yazıp hiçbirini bitirmemek yerine, 3 net iyileştirme daha değerlidir.
Bot ve makro güncelleme ritmi
Bot ve makro güncellemesi plansız yapılırsa kalite dalgalanır. Ritmi sabitleyin:
- Makro güncellemesi: 2 haftada bir küçük revizyon
- Bot akış güncellemesi: ayda bir planlı sürüm
- Bilgi tabanı kontrolü: kampanya dönemlerinde haftalık, normalde aylık
Her güncellemede bir “değişiklik notu” tutun. Hangi makro değişti, neden değişti, hangi KPI etkilenecek? Bu, geriye dönük analizde hayat kurtarır.
Deney tasarımı ve A B testleri
Canlı sohbet optimizasyonu, “bence böyle” tartışmasıyla ilerlemez. Basit deneyler kurun:
- Tetikleyici testi: ürün sayfasında 30 saniye mi 60 saniye mi?
- Karşılama metni testi: seçenekli menü vs serbest metin
- Bot kapsam testi: iade triage botu açık vs kapalı
- Çalışma saatleri mesajı: net SLA yazmak CSAT’i artırıyor mu?
Deneylerde tek değişken kuralına sadık kalın. Ölçüm penceresini en az 1–2 hafta tutun; trafik düşükse daha uzun gerekebilir. Sonuçları Canlı Destek Blog gibi kaynaklarda gördüğünüz örneklerle kıyaslayabilirsiniz ama kendi veriniz en belirleyici olandır.
Supporting Article Potential:
- Canlı sohbet haftalık operasyon toplantısı: metrikler, ajanda ve aksiyon şablonu
- Chatbot ve makro güncelleme süreci: sürümleme ve değişiklik yönetimi
- Canlı sohbette A/B test fikirleri: tetikleyici, karşılama ve bot kapsam deneyleri
