Canlı Destek Kurulumu ve Yönetimi Rehberi

Canlı destek, tek başına “siteye chat eklemek” değildir. Doğru kurgulanmadığında satış ekiplerini oyalayan, destek ekibini yoran ve müşteriye “kimse ilgilenmiyor” hissi veren bir kutuya dönüşür. Doğru kurgulandığında ise satın alma kararını hızlandırır, iade ve kargo baskısını azaltır, müşteri memnuniyetini ölçülebilir biçimde yükseltir.

Bu rehber, canlı destek kurulumunu kanal seçiminden vardiya modeline, bot devrinden KVKK kontrollerine kadar uçtan uca ele alır. E-ticaret, SaaS ve hizmet işletmeleri için uygulanabilir çerçeveler sunar: hangi kanalı ne için kullanacağınız, hangi özelliklerin “olmazsa olmaz” olduğu, verinin nerede akacağı, ekibin nasıl çalışacağı ve performansın nasıl raporlanacağı netleşir.

Okuyucu profili: canlı destek kurmak isteyen e-ticaret yöneticileri, büyüme ekipleri, müşteri destek liderleri ve SaaS ürün ekipleri. Daha fazla pratik rehber için Canlı Destek Blog içeriğine de göz atabilirsiniz.

Table of Contents

• Kapsam ve kanal haritası
• Kullanım senaryosu tasarımı
• Özellik gereksinim matrisi
• Entegrasyon ve veri akışı
• Ekip ve vardiya modeli
• SLA ve yönlendirme kuralları
• Bot handoff kurgusu
• Makro ve hazır cevap seti
• Kalite ve eğitim rutini
• KPI ve raporlama döngüsü
• KVKK ve güvenlik kontrolü

Kapsam ve kanal haritası

Canlı desteğin kapsamını netleştirmeden seçilecek her araç, kısa sürede “yetmiyor” ya da “fazla karmaşık” hissi üretir. Buradaki hedef bir kanal listesi yapmak değil; kanal haritasını iş hedeflerine ve operasyon gerçeklerine bağlamak.

Web ve uygulama canlı sohbet kapsamı

Web chat genelde en düşük sürtünmeyle başlar: ziyaretçi sayfadayken soru sorar, siz de anında yakalarsınız. Mobil uygulamada ise sohbet daha “hesap bazlı” çalışır; kullanıcı login olduğu için bağlam zengindir ama push bildirim, sürüm uyumluluğu ve SDK yönetimi gibi ek yük getirir.

Pratik kapsam tanımı:

• Web için: ürün/kategori sayfaları, sepet, checkout ve yardım merkezi sayfaları öncelikli.
• Uygulama için: siparişlerim, iade başlatma, ödeme hatası ekranları kritik.
• Başlangıçta “tüm sayfalarda chat” yerine, en yüksek niyetli 5–10 sayfada görünürlük daha sağlıklıdır.

Bir de görünürlük kuralı koyun: chat balonu her zaman açık mı, yoksa çalışma saatlerine göre mi? Eğer 7/24 değilseniz, offline senaryoda form, e-posta veya WhatsApp’a yönlendirme net olmalı.

Çoklu kanal entegrasyonları kapsamı

Canlı destek çoğu ekipte tek kanalla kalmaz: web chat, e-posta, WhatsApp, Instagram DM, Facebook Messenger aynı kuyruğa düşer. Bu birleşim iyi yönetilirse tek ekran verim sağlar; kötü yönetilirse “her yerden mesaj geliyor” kaosuna döner.

Kapsamı belirlerken şu ayrımı yapın:

• “Gerçek zamanlı” kanallar: web chat, WhatsApp, DM. Burada FRT (ilk yanıt süresi) hedefi daha agresif olur.
• “Asenkron” kanallar: e-posta, form. Burada SLA saat bazlı kurgulanır.

Araç seçerken resmi sitelerden özellikleri doğrulayın: örnek olarak JivoChat, Desk360 ve Limondesk gibi çözümler çoklu kanal kutusu sunar; fakat her birinin kanal yetenekleri ve raporlama derinliği farklıdır.

Kanal bazlı riskler WhatsApp Instagram Facebook

Üçüncü taraf kanallarda risk, “entegrasyon var mı?” sorusundan öteye geçer. Asıl mesele platform politikaları, erişim kesintileri ve kimlik doğrulama akışlarıdır.

• WhatsApp: İşletme API kullanıyorsanız şablon mesaj, oturum penceresi ve numara doğrulama süreçleri kritik. Yanlış kurguda müşteriye dönüş gecikir.
• Instagram/Facebook: DM’ler kampanya dönemlerinde patlar. Bot kullanımı veya otomasyonlar platform kurallarına takılabilir. Ayrıca kullanıcı bazen aynı soruyu yorum, DM ve web chat’ten tekrarlar; birleştirme yoksa gereksiz iş çıkar.

Kontrol listesi:

1. Kanal hesabının sahipliği kimde?
2. Yetki devri, iki adımlı doğrulama ve yedek admin var mı?
3. Veri saklama ve silme talepleri bu kanalda nasıl yönetilecek?

Kanal seçiminde Türkiye bağlamı

Türkiye’de kullanıcı davranışı “mesajlaşma odaklı.” Birçok sektörde WhatsApp, e-posta yerine tercih ediliyor. Bu avantaj gibi görünse de operasyon yükünü artırabilir: WhatsApp’tan gelen mesajlar genelde daha dağınık ve “acil” tonda olur.

Kanal seçimini şu şekilde çerçeveleyin:

• E-ticarette: web chat + sipariş sayfası içi destek + WhatsApp (kontrollü) iyi bir başlangıç.
• Hizmet işletmelerinde: Instagram DM yoğun olabilir; ama satış sonrası destek için web chat ve e-posta daha izlenebilir.
• SaaS’ta: uygulama içi chat ve e-posta bilet sistemi, WhatsApp’a göre daha sürdürülebilir.

Site yapınızı ve içerikleri görmek isteyenler için ana sayfa ve kategori akışı için blog içeriği iyi bir başlangıç noktasıdır.

Supporting Article Potential:

• “Web chat mi WhatsApp mı? E-ticaret için kanal seçimi çerçevesi”
• “Instagram DM destek operasyonu: riskler, yetkiler, ölçüm”
• “Çoklu kanal canlı destek kurulumu: tek kuyruk mu ayrı kuyruk mu?”

Kullanım senaryosu tasarımı

Araçları kurmadan önce senaryoları yazmak zaman kazandırır. Çünkü canlı destek, en çok “hangi soru hangi akışa gidecek?” kararlarında tıkanır. Senaryo tasarımı, SLA ve bot devri dahil tüm sistemi besleyen çekirdektir.

E ticaret satış öncesi senaryolar

Satış öncesi sohbetlerin amacı “bilgi vermek” değil, karar engelini kaldırmak olmalı. Tipik engeller: beden/uyumluluk, teslimat süresi, stok, kampanya koşulu, güven.

Uygulanabilir bir şablon:

1. Ziyaretçi ürün sayfasında 30–60 saniye kaldıysa tetikleyici mesaj.
2. İlk soru: “Hangi kullanım için bakıyorsunuz?” gibi yönlendirici.
3. Ürün önerisi: 2 seçenek, net fark.
4. Son adım: sepete ekleme veya kupon açıklaması.

Burada kritik olan, temsilcinin sayfayı görmesi: hangi ürün, hangi varyant, sepet tutarı. Bu bağlam yoksa sohbet uzar, dönüşüm düşer.

Sipariş ve kargo destek senaryoları

Sipariş sonrası sohbetler hacim üretir. Bu yüzden süreç tasarımı şart. En iyi yaklaşım, sohbeti “sorgu ekranına” bağlamaktır: kullanıcı sipariş no yazmadan bile, login ise otomatik eşleşsin.

Senaryo seti:

• “Siparişim nerede?”: kargo firması, takip no, son hareket, tahmini teslim.
• “Adres değişikliği”: hangi aşamada mümkün, hangi koşullarda iptal/yeniden sipariş.
• “Eksik/hasarlı ürün”: fotoğraf talebi, tutanak, yeniden gönderim/iadeye yönlendirme.

Hedef: aynı soruyu 3 kere sormamak. Temsilci tek ekrandan sipariş durumunu görmeli.

İade ve ödeme sorun senaryoları

İade ve ödeme, gerilimin yüksek olduğu alan. Burada dil standardı ve kanıt toplama akışı çok önemli.

İade senaryosunu ikiye bölün:

• Cayma hakkı / vazgeçme: süre, ürün koşulu, kargo etiketi.
• Kusurlu ürün: foto/video, seri no, servis yönlendirmesi.

Ödeme sorunlarında “bankaya suç atma” refleksi marka algısını zedeler. Daha iyi çerçeve:

1. Hata mesajını aynen isteyin.
2. Kullanılan yöntemi doğrulayın (kart, havale, kapıda ödeme).
3. Alternatif ödeme önerin.
4. Gerekirse güvenli link veya tekrar deneme adımı verin.

Bu senaryoları makrolara bağlamazsanız, ekip aynı metni farklı şekillerde yazıp tutarsızlık üretir.

SaaS onboarding ve teknik destek senaryoları

SaaS’ta canlı destek çoğu zaman ürünün parçası. Onboarding sohbetleri satışa, teknik destek sohbetleri churn azaltmaya çalışır.

İyi bir senaryo ayrımı:

• Onboarding: “kurulum adımı”, “ilk başarı”, “entegrasyon”, “yetkilendirme”.
• Teknik destek: “hata ayıklama”, “log talebi”, “ekran görüntüsü”, “incident”.

Teknik senaryolarda şu kural iş görür: 5 dakikadan uzun sürecek bir konu varsa, sohbeti bilet veya çağrı planlamaya çevirin. Aksi halde temsilci “chat içinde debug” yaparken kuyruk şişer.

Supporting Article Potential:

• “E-ticaret canlı destek satış öncesi akışları: tetikleyici ve metin örnekleri”
• “Sipariş nerede? sohbetlerini otomatikleştirme: kargo entegrasyonu checklist’i”
• “SaaS canlı destek: onboarding ve teknik destek kuyruklarını ayırma modeli”

Özellik gereksinim matrisi

“Şu araç iyi mi?” sorusunun anlamlı cevabı, ihtiyaç matrisi olmadan verilemez. Çünkü canlı destek araçları, benzer görünen ama operasyonu doğrudan etkileyen ayrıntılarda ayrışır: kuyruk mantığı, raporlama, rol yetkileri, entegrasyon derinliği.

Aşağıdaki matrisi ekipçe doldurup sonra ürünleri kıyaslayın. Hedef, olmazsa olmaz ile “olsa güzel olur”u ayırmak.

Trafik ve hacim gereksinimleri

Hacim iki şeyi belirler: lisans maliyeti ve operasyon tasarımı. Günlük sohbet sayısı artınca tek kritik metrik eşzamanlı sohbet kapasitesi olur.

Pratik eşikler:

• Günlük 20–50 sohbet: basit canlı chat + temel raporlar yeter.
• Günlük 50–200: kuyruk yönetimi, etiketleme, vardiya ve kalite rutini şart.
• Günlük 200+: çoklu kanal, otomasyon, bot devri, gelişmiş raporlama neredeyse zorunlu.

Araçta arayın:

• Sohbet hacmi artınca performans düşüyor mu?
• Raporlar kanal/temsilci/etiket kırılımında mı?
• Sohbet başına maliyet mi, temsilci başına mı fiyatlanıyor?

Ekip büyüklüğü ve uzmanlık gereksinimleri

3 kişilik ekip ile 30 kişilik ekip aynı aracı aynı şekilde kullanamaz. Büyük ekipte rol bazlı yetki ve denetim kaydı kritik hale gelir.

Minimum gereksinimler:

• Rol ayrımı: admin, takım lideri, temsilci, sadece-izleyici.
• Yetkiler: makro düzenleme, etiket yönetimi, export, entegrasyon ayarları.
• Eğitim: yeni temsilci için “sandbox” veya test ortamı varsa büyük avantaj.

Uzmanlık yönlendirmesi gerekiyorsa (teknik destek, iade ekibi, B2B satış), kuyrukların ayrılabildiğini doğrulayın.

Kanal ve cihaz gereksinimleri

Müşteri hangi cihazda? Ekip hangi cihazda?

• Mobil ziyaretçi yüksekse chat widget’ının mobil UX’i belirleyici: tek satırda açılmalı, klavye üstüne binmemeli.
• Temsilciler saha ekibiyse mobil uygulama şart; ama güvenlik nedeniyle cihaz yönetimi de düşünülmeli.

Kanal gereksinimleri için kısa liste:

• Web chat (olmazsa olmaz)
• E-posta / form (çoğu ekipte)
• WhatsApp/DM (sektöre göre)
• Uygulama içi chat (SaaS)

Yedi yirmi dört kapsama gereksinimleri

7/24 ihtiyacı çoğu ekipte “bizde de olsa iyi olur” diye başlar; gerçek maliyeti görünce geri adım gelir. Bu yüzden önce kapsama seviyesini tanımlayın:

• Seviye 1: Mesai saatleri canlı, mesai dışı form.
• Seviye 2: Mesai dışı bot + ertesi gün dönüş.
• Seviye 3: 7/24 insan (vardiya veya dış kaynak).
• Seviye 4: 7/24 insan + incident/on-call (SaaS kritik).

Araçta offline modun nasıl çalıştığı önemli: “mesaj bırak” akışı, otomatik yanıt, bekleme süresi bilgisi ve bilet oluşturma.

Supporting Article Potential:

• “Canlı destek aracı seçimi için gereksinim matrisi: indirilebilir şablon”
• “7/24 canlı destek gerçekten gerekli mi? maliyet ve kapsama modelleri”
• “Büyüyen ekiplerde canlı destek yetkilendirme ve rol tasarımı”

Entegrasyon ve veri akışı

Canlı destek, veri akışı kurmadığınızda “konuşma kutusu” olarak kalır. Oysa değer, temsilcinin müşteriyi tanıması ve operasyonun ölçülebilmesidir. Entegrasyonları ikiye ayırın: temsilci deneyimini güçlendirenler ve raporlamayı doğru yapanlar.

CRM ve sipariş sistemleri veri akışı

E-ticarette sipariş sistemi, SaaS’ta CRM ve abonelik yönetimi canlı desteğin çekirdeğidir. Temsilci şu bilgileri 1–2 tıkla görmeli:

• Müşteri kimliği, iletişim bilgisi
• Son siparişler / abonelik planı
• Teslimat durumu veya fatura bilgisi
• Daha önce açılan talepler

Veri akışını tasarlarken “iki yönlü” düşünün:

• Canlı destek ekranına müşteri verisi gelsin.
• Sohbet çıktısı CRM’e not olarak gitsin.

Bu sayede satış ekibi “hangi müşteri ne sordu?”yu, destek ekibi “bu müşteri kronik mi?”yi görür.

Etiketleme ve müşteri bağlamı aktarımı

Etiketleme, raporlamanın omurgasıdır ama çoğu ekipte gelişi güzel kalır. Başlangıç için 15–25 etiket idealdir. Daha fazlası seçimi zorlaştırır.

Önerilen etiket yapısı:

• Niyet: satış öncesi, destek, iade, teknik
• Konu: kargo, ödeme, kupon, ürün uyumu
• Sonuç: çözüldü, eskalasyon, iade açıldı
• Duygu: öfkeli, kararsız, memnun (opsiyonel)

Bağlam aktarımı için temel alanlar:

• URL/referrer
• Sepet tutarı (varsa)
• Sipariş ID / müşteri ID
• Dil ve ülke
• Cihaz

Bu alanlar, bot handoff ve yönlendirme kurallarını da besler.

Analitik ve dönüşüm ölçümü veri akışı

Canlı desteğin performansı sadece CSAT değil, dönüşüm etkisiyle de anlaşılır. Bunun için analitik tarafında minimum kurulum:

• Chat başlatma olayı (event)
• Chat’ten sonra satın alma olayı (attribution penceresi tanımıyla)
• “Sohbet alan vs almayan” segment karşılaştırması

Burada hassas nokta, yanlış çıkarım yapmamak. Canlı desteğe gelenler zaten daha niyetli olabilir. Yine de zaman içinde trendler ve sayfa bazlı etkiler net sinyal verir.

Pratik öneri:

• Checkout sayfasında chat gösteriyorsanız, “chat açıldı” olayını ayrıca işaretleyin.
• Kampanya döneminde chat hacmi artınca dönüşüm düşüyorsa, sebep genelde yetersiz kapasite ve kaçırılan sohbetlerdir.

Veri saklama ve erişim yetkileri

Sohbet kayıtları değerli ama riskli. Hangi veriyi ne kadar süre saklayacağınız, kimlerin erişeceği, export yetkisi olup olmayacağı baştan belirlenmeli.

Minimum politika:

• Saklama süresi: iş ihtiyacına göre belirleyin; “sınırsız” varsayılan olmasın.
• Export: sadece admin veya sınırlı rol.
• Maskeleme: kart, TC kimlik, IBAN gibi verileri sohbet içinde istememek; gerekiyorsa maskelemek.

Bu bölüm, KVKK başlığının operasyonel ayağıdır. Teknik ayar olmadan “uyum” sadece niyet olur.

Supporting Article Potential:

• “Canlı destek + CRM entegrasyonu: iki yönlü veri akışı nasıl tasarlanır?”
• “Etiketleme sistemi kurma: 25 etiketle rapor üretilebilir yapı”
• “Canlı destek dönüşüm ölçümü: event planı ve attribution hataları”

Ekip ve vardiya modeli

Canlı destek performansını en çok belirleyen şey araç değil, ekip modeli. Rol dağılımı, kapasite hesabı ve yoğun saat planı yoksa en iyi yazılım bile kaosu gizleyemez.

Rol dağılımı destek satış teknik ekip

En sık hata: canlı destek tek bir ekibe bırakılır, sonra her konu onlara düşer. Daha iyi yaklaşım, rollerin sınırını çizmek:

• Satış: ürün önerisi, kampanya, B2B teklif ön eleme
• Destek: sipariş, kargo, iade süreçleri
• Teknik: SaaS’ta hata/entegrasyon, e-ticarette ödeme altyapısı veya teknik sorunlar

Operasyonel kural:

• Temsilci, yetkisi olmayan konuda “çözmeye çalışmak” yerine doğru ekibe hızlı eskale etsin.
• Eskalasyon kanalı net olsun: iç bilet, Slack/Teams, görev atama.

Takım lideri rolü genelde ihmal edilir. Oysa lider, kuyruk şiştiğinde sohbet dağıtır, kaliteyi izler, makro ve etiket disiplinini korur.

Vardiya planı ve kapasite hesabı

Vardiya planı için kabaca şu hesap iş görür:

• Saatlik sohbet hacmi (peak)
• Ortalama ele alma süresi (ART)
• Temsilci başına eşzamanlı sohbet limiti (genelde 2–3 iyi bir başlangıç)

Örnek düşünme:

• Peak saatte 30 sohbet başlıyor.
• ART 8 dakika.
• Eşzamanlı 2 sohbet/temsilci.
  Bu durumda o saat için 30 x 8 = 240 dakika iş yükü var. 60 dakikaya bölerseniz 4 tam zamanlı “temsilci-saat” gerekir. Eşzamanlılıkla birlikte pratikte 4–6 kişi planlamak daha gerçekçidir.

Bu hesabı haftalık yapın, sonra vardiya çizelgesine oturtun. Tahmininiz 1 ay sonra değişecek; önemli olan yöntemin olması.

Yoğun saat kapsama planı

Yoğun saatler genelde:

• E-ticarette öğle arası, akşam 20:00–23:00
• Kampanya günlerinde gün boyu dalgalı
• SaaS’ta iş saatleri ve release sonrası

Yoğun saat planı için 3 hamle:

1. O saatlerde sadece “chat” görevi olan temsilci.
2. Bot ile basit soruları filtreleme (kargo sorgu, çalışma saatleri).
3. “Geri dönüş sözü” verip bilet açma: 5 dakikada çözülemeyecek konuyu chat’te uzatmama.

Burada amaç, kaçırılan sohbetleri düşürmek. Kaçırılan sohbet, çoğu zaman satış kaybı ya da tekrar başvuru demek.

Dış kaynak ve hibrit ekip kurgusu

7/24 veya kampanya dönemlerinde dış kaynak cazip gelir. Hibrit model çalışır, ama sınırları net olmalı:

• Dış kaynak hangi konuları çözer, hangilerini eskale eder?
• Makrolar ve bilgi tabanı aynı mı?
• Kalite puanlaması aynı sistemde mi?

En büyük risk “marka dili.” Dış kaynak ekibin ton standardı yoksa, müşteri aynı gün iki farklı kişiyle konuştuğunda marka tutarsız görünür.

Dış kaynak kullanacaksanız, başlangıçta sadece Seviye 1 sorularla sınırlayın: sipariş durumu, iade koşulu, temel bilgi. Karmaşık vakaları iç ekibe yönlendirin.

Supporting Article Potential:

• “Canlı destek kapasite hesabı: ART ve eşzamanlı sohbetle vardiya planlama”
• “Satış ve destek aynı canlı destek ekranında çalışır mı? rol ayrımı modeli”
• “Dış kaynak canlı destek: sözleşme, kalite ve bilgi tabanı kontrol listesi”

SLA ve yönlendirme kuralları

SLA, müşteriye verilen söz olduğu kadar ekip içi öncelik sistemidir. Yazılı değilse, herkes “en acil” olana koşar ve sistem çöker. Buradaki hedef, hedef süreleri ve yönlendirme mantığını anlaşılır hale getirmek.

Öncelik seviyeleri ve hedef süreler

4 seviyeli bir model çoğu işletmeye yeter:

• P1: ödeme alınamıyor, sistem down, sipariş verilemiyor
• P2: kargo/teslimat gecikmesi, iade kritik
• P3: ürün soruları, kampanya detayları
• P4: genel bilgi, iş birliği talepleri

Hedef süreleri kanal bazlı tanımlayın:

• Web chat FRT: 30–60 saniye hedeflenebilir (mesai içinde).
• WhatsApp/DM FRT: 5–15 dakika daha gerçekçi olabilir (hacme göre).
• E-posta/form: 4–24 saat aralığı, sektör beklentisine göre.

Önemli: SLA’yı “ortalama” değil, yüzde dilimiyle takip edin (ör. görüşmelerin %80’i hedefte). Araç raporlaması buna izin veriyor mu bakın.

Kuyruk yönetimi ve atama mantığı

Kuyruk yönetimi iki temel modelde çalışır:

1. Round-robin: sırayla dağıtır. Basit ve adil.
2. Skill-based: uzmanlığa göre dağıtır. Daha verimli ama kurması zor.

Başlangıç için öneri:

• Genel kuyruk + 1–2 uzman kuyruk
• Mesai dışında tek kuyruk
• VIP müşteriler için ayrı etiket ve öncelik

Atama mantığında “boşta olan alsın” yaklaşımı, kaliteyi düşürebilir. Bazen en doğru kişi meşguldür ama 2 dakika sonra boşalacaktır. Bu yüzden kuyrukta bekleme mesajı ve tahmini süre göstermek önemlidir.

Uzmanlığa göre yönlendirme kuralları

Uzmanlığa göre yönlendirme, ancak doğru sinyalleriniz varsa çalışır:

• Seçilen konu (kargo, iade, teknik)
• Müşteri segmenti (B2B, VIP, yüksek sepet)
• Dil/ülke
• Ürün kategorisi

Müşteriye konu seçtirmek bazen sürtünme yaratır. Alternatif: bot ilk 1–2 soruyla konuyu tahmin eder, sonra kuyruğa atar.

Kural yazarken “istisna”ları düşünün:

• Uzman kuyruk doluysa ne olacak?
• 2 dakika içinde atama olmazsa genel kuyruğa düşsün mü?
• VIP her durumda öne mi alınacak?

Kaçırılan sohbet azaltma kuralları

Kaçırılan sohbetler genelde üç nedenle artar: kapasite yetersiz, bildirimler kaçıyor, vardiya disiplini yok.

Somut önlemler:

• Temsilci başına eşzamanlı sohbet limitini 2 ile başlatın, kalite oturunca 3’e çıkarın.
• 90 saniye yanıt yoksa otomatik “hala buradayım” mesajı.
• 3 dakika sessizlikte sohbeti kapatmak yerine, “size şu kanaldan dönebilir miyiz?” diye izin istemek.
• Yoğun saatlerde chat tetikleyicilerini azaltmak (her sayfada pop-up yapmamak).

Kaçırılan sohbetleri haftalık takip edin ve neden kodu ekleyin: “temsilci yok”, “müşteri ayrıldı”, “atama hatası”. Aksi halde sadece sayı görürsünüz.

Supporting Article Potential:

• “Canlı destek SLA nasıl yazılır? kanal bazlı FRT hedefleri”
• “Skill-based routing kuralları: e-ticaret ve SaaS örnekleri”
• “Kaçırılan sohbetleri düşürme: kapasite, tetikleyici ve bildirim ayarları”

Bot handoff kurgusu

Bot, canlı desteği “az insanla çok iş”e çevirebilir. Aynı zamanda yanlış kurguda müşteri sinirini ikiye katlar. Bu bölümde amaç, botu doğru yerde kullanmak ve insana devri sorunsuz hale getirmek.

Bot ve insan görev ayrımı

Botun en iyi olduğu işler:

• Sık sorulan sorular (kargo süresi, iade şartı, çalışma saatleri)
• Bilgi toplama (sipariş no, e-posta, konu seçimi)
• Yönlendirme (doğru kuyruğa atma)
• Basit self-servis (kargo takip linki üretme)

İnsanın gerekli olduğu yerler:

• İstisnalar (teslimat sorunu, hasarlı ürün)
• Pazarlık/ikna (B2B satış, yüksek sepet)
• Duygusal gerilim (şikayet, kriz)
• Teknik teşhis (SaaS hata, entegrasyon)

Kural: Bot, müşteriyi 2–3 adımdan fazla oyalıyorsa muhtemelen yanlış yerde devrediyor.

Devretme tetikleyicileri ve eşikler

Handoff tetikleyicileri ölçülebilir olmalı:

• Müşteri “temsilci” yazdıysa anında devret.
• Bot aynı soruya 2 kez cevap veremiyorsa devret.
• Negatif duygu sinyali (küfür, “iptal edeceğim”) algılanırsa devret.
• Sepet tutarı yüksekse (ör. belirlediğiniz eşik) satış temsilcisine devret.

Eşiklerinizi basit tutun. Çok karmaşık kural seti, beklenmeyen boşluklar üretir.

Bağlam aktarımı ve konuşma özeti

En kötü deneyim: botla 5 mesaj, sonra temsilci “sipariş numaranızı alabilir miyim?” diye başa sarar. Handoff’un kalitesi, bağlam aktarımıdır.

Minimum aktarım paketi:

• Toplanan alanlar: sipariş no, e-posta, konu, ürün
• Son 10 mesaj
• Botun çıkardığı kısa özet: “Müşteri kargo gecikmesi yaşıyor, takip no var, adres değişikliği istiyor.”

Temsilci ekranında bu özet görünmüyorsa, botun değeri düşer.

Hata yakalama ve geri dönüş akışı

Bot hata yapacak. Önemli olan hatayı saklamak değil, yakalayıp toparlamak.

Geri dönüş akışı:

1. Bot anlayamadı: “Bunu netleştireyim” + 2 seçenekli soru.
2. Yine anlayamadı: temsilciye devret.
3. Temsilci yoksa: bilet aç + net dönüş zamanı ver (ör. “en geç yarın 11:00’e kadar”).

Ayrıca bot içeriklerini sürümleyin. Haftalık 20–30 konuşma örneği inceleyip “bot nerede takılıyor?”u çıkarın. Bu, kalite rutininin bir parçası olmalı.

Supporting Article Potential:

• “Bot mu insan mı? canlı destekte görev ayrımı çerçevesi”
• “Handoff tasarımı: bağlam aktarımı için alan listesi ve ekran kurgusu”
• “Bot başarısızlıkları: fallback akışı ve ölçümleme yaklaşımı”

Makro ve hazır cevap seti

Hazır cevaplar, temsilciyi hızlandırır ama kötü yazılırsa markayı robotlaştırır. Buradaki hedef, makro kütüphanesini sürdürülebilir bir sistem haline getirmek: kategori, dil standardı, değişkenler ve güncelleme süreci.

Makro kütüphanesi kategori yapısı

Başlangıç kütüphanesi için 30–60 makro çoğu ekipte yeterlidir. Kategori yapısı basit olmalı:

• Satış öncesi: ürün uyumu, beden/ölçü, kampanya, ödeme seçenekleri
• Sipariş: durum sorgu, adres değişikliği, fatura talebi
• Kargo: takip, gecikme, teslim edilemedi
• İade: şartlar, süreç adımları, kargo etiketi
• Teknik: site/app hata, ödeme hatası, giriş problemi
• Genel: çalışma saatleri, iletişim kanalları

Makroları “konu”ya göre değil, “temsilcinin aradığı an”a göre gruplayın. Örneğin iade makroları içinde “müşteri öfkeli” varyantı ayrıca yer alabilir.

Ton ve dil standardı

Ton standardı yazılı değilse, ekip büyüdükçe dil bozulur. 1 sayfalık bir dil rehberi yeter:

• Hitap: “siz” mi “sen” mi?
• Noktalama ve emoji kullanımı (kurumsal çizgiye göre)
• Özür dili: ne zaman, nasıl?
• Kısa cümle kuralı: 1 mesajda 1–2 cümleyi geçmemek çoğu kanalda daha okunur.

Özellikle iade/şikayet makrolarında savunmacı dil risklidir. “Bizim hatamız değil” yerine “beraber çözelim” yaklaşımı daha az gerilim üretir.

Kişiselleştirme alanları ve değişkenler

Makrolar düz metin olursa yapay durur. Değişken kullanın:

• {isim}
• {siparis_no}
• {kargo_firmasi}
• {takip_linki}
• {tahmini_teslim}

Ama abartmayın. Her cümlede değişken kullanmak metni garipleştirir. Ayrıca veri yoksa ne olacağını tanımlayın: isim yoksa “Merhaba” ile başlasın gibi.

Bir de “kısmi otomasyon” iyi çalışır: makro, temsilciye dolduracağı alanlar bırakır. Örn: “Size yardımcı olabilmem için {eksik_bilgi} bilgisini paylaşır mısınız?”

Güncelleme ve onay süreci

Makro kütüphanesi yaşayan bir şey. Kampanya biter, iade politikası değişir, kargo firması değişir. Güncellenmeyen makro, yanlış bilgi üretir.

Basit süreç:

1. Makro sahibi: takım lideri veya operasyon.
2. Değişiklik talebi: temsilci “makro geri bildirimi” etiketiyle iletir.
3. Onay: hukuk/ürün/operasyon (içeriğe göre).
4. Yayın: haftalık veya iki haftada bir “makro release”.

Makro değişikliklerini log’layın. “Ne zaman ne değişti?” bilmek, kalite incelemesinde çok iş görür.

Supporting Article Potential:

• “E-ticaret için 50 makroluk hazır cevap kütüphanesi nasıl kurgulanır?”
• “Canlı destek ton rehberi: kısa, net ve tutarlı dil standardı”
• “Makro yönetimi: onay süreci ve sürümleme yaklaşımı”

Kalite ve eğitim rutini

Kalite, tek seferlik eğitimle gelmez. Rutin ister. İnceleme, koçluk, bilgi tabanı ve yeni başlayan planı birlikte çalışırsa ekip hem hızlanır hem tutarlılık kazanır.

Kalite puanlama kriterleri

Kalite puanlama subjektif kalmamalı. 10 üzerinden giden basit bir rubrik bile fark yaratır.

Örnek kriterler:

• Doğruluk: bilgi doğru mu?
• Çözüm odaklılık: net adım verdi mi?
• Ton: saygılı, sakin, marka diliyle uyumlu mu?
• Süreç uyumu: etiket, not, eskalasyon doğru mu?
• İlk temas çözümü: mümkünse chat içinde kapandı mı?

Her görüşmeyi puanlamak gereksiz. Haftada temsilci başına 5–10 sohbet örneklemek yeterli olur.

Görüşme inceleme ve koçluk ritmi

İnceleme ritmi olmadan kalite raporu “dosyada kalır.” En iyi çalışan sistem:

• Haftalık 30 dakikalık 1:1 koçluk (lider + temsilci)
• Aylık ekip kalibrasyonu (liderler aynı görüşmeye aynı puanı veriyor mu?)
• “En iyi 3 konuşma” paylaşımı (iyi örnek üzerinden öğrenme)

Koçluk, sadece hatayı söylemek değil; bir sonraki hafta için 1 davranış hedefi koymaktır. Örn: “Her sohbetin ilk 30 saniyesinde bağlam sorusu sor.”

Yeni başlayan eğitim planı

Yeni temsilciyi canlıya atıp “izleye izleye öğrenir” demek pahalıya patlar. 2 haftalık basit bir plan kurgulayın:

1–2. gün: ürün, politika, iade/kargo süreçleri
3–5. gün: makro kütüphanesi, etiketleme, örnek sohbet inceleme
2. hafta: gölge çalışma (shadow), sonra kontrollü canlı (günde 10–20 sohbet)

Bu süreçte kontrol noktaları koyun:

• 1. hafta sonunda kısa test (politika ve süreç)
• 2. hafta sonunda kalite örneklemesi

Bilgi tabanı ve iç dokümantasyon

Canlı destek, bilgi tabanı olmadan ölçeklenmez. İki katmanlı düşünün:

• Dış bilgi tabanı: müşterinin okuyacağı yardım merkezi
• İç dokümantasyon: temsilcinin kullanacağı “nasıl yapılır” ve istisnalar

İç dokümantasyonda şu sayfalar altın değerinde:

• Kampanya kuralları (son güncel)
• Kargo istisnaları ve çözüm yolları
• İade red kriterleri
• Eskalasyon rehberi: hangi konu hangi ekibe gider

Dokümanlar güncel değilse temsilci yine chat’te “bilmiyorum” der. O yüzden doküman sahipliği ve güncelleme periyodu (ör. 12–18 ay içerik yenileme, kampanya dönemlerinde anlık güncelleme) belirleyin.

Supporting Article Potential:

• “Canlı destek kalite rubriği: 10 puanlık değerlendirme sistemi”
• “Yeni başlayan canlı destek temsilcisi için 2 haftalık eğitim planı”
• “İç dokümantasyon nasıl kurulur? destek operasyonu wiki yapısı”

KPI ve raporlama döngüsü

KPI’lar yanlış seçilirse ekip “hız uğruna kalite” ya da “CSAT uğruna verimsizlik” tuzağına düşer. Raporlama döngüsünün amacı, günlük yönetimle aylık iyileştirmeyi ayırmaktır: bugün kuyruk yönetimi, bu ay süreç düzeltme.

FRT ve ART takibi

İki temel hız metriği:

• FRT (First Response Time): ilk yanıt süresi
• ART (Average Resolution/Handle Time): ortalama ele alma/çözüm süresi

FRT, algıyı yönetir. 30 saniyede “merhaba” deyip 10 dakika bekletmek iyi deneyim değildir; bu yüzden ART ve “bekleme süresi”ni birlikte izleyin.

Pratik rapor:

• Günlük: kanal bazlı FRT, kaçırılan sohbet
• Haftalık: temsilci bazlı FRT/ART dağılımı (ortalama değil, dağılım)

ART’yi düşürmek için ilk hamle genelde makro ve bağlam entegrasyonudur, temsilciyi “hızlan” diye zorlamak değil.

Çözüm oranı ve yeniden başvuru

Canlı destek sadece yanıt vermek değil, işi bitirmek. Bu yüzden:

• İlk temas çözüm oranı (FCR)
• Yeniden başvuru oranı (aynı konu 7 gün içinde geri geldi mi?)

Yeniden başvuru yüksekse iki ihtimal vardır:

1. Temsilci yanlış/eksik bilgi verdi.
2. Süreç bozuk, müşteri mecburen tekrar yazıyor (ör. iade süreci belirsiz).

Bu metrikleri etiketlerle bağlayın. “Kargo gecikmesi” etiketinde yeniden başvuru yükseliyorsa, sorun çoğu zaman kargo SLA’sı değil, müşteriye verilen bilginin net olmamasıdır.

CSAT ve kalite sinyalleri

CSAT (memnuniyet) tek başına yeterli değildir çünkü yanıtlayan müşteri seçilimi vardır. Yine de trend için değerlidir.

CSAT kuralları:

• Anketi sohbet kapanınca 1 soruyla sorun.
• 1–5 ölçek basit kalır.
• Düşük puanda “neden” alanı eklemek faydalı ama zorunlu yapmayın.

Kalite sinyalleri:

• Negatif duygu etiketleri
• Eskalasyon oranı
• Şikayet kanalına kayma (müşteri chat’ten çözmeyip sosyal medyaya gidiyor mu?)

Dönüşüm etkisi ve kaçırılan sohbetler

E-ticarette canlı desteğin en kritik iş KPI’ı: sohbet alan kullanıcıların dönüşümü ve kaçırılan sohbetlerin maliyeti.

Ölçüm yaklaşımı:

• Chat başlatanların satın alma oranı (trend)
• Checkout’ta chat açanların terk oranı
• Kaçırılan sohbet sayısı ve oranı (kaçırılan / gelen)

Kaçırılan sohbetler arttığında iki hızlı aksiyon:

1. Yoğun saatlerde tetikleyicileri azalt.
2. Vardiyayı o saatlere kaydır veya dış kaynakla destekle.

Raporlama döngüsü önerisi:

• Günlük 10 dakika: kuyruk, kaçırılan, kritik etiketler
• Haftalık 45 dakika: KPI trendleri, en çok gelen 5 konu, makro/KB güncellemesi
• Aylık 90 dakika: süreç iyileştirme, entegrasyon backlog’u, bot performansı

Supporting Article Potential:

• “Canlı destek KPI seti: FRT, ART, FCR ve yeniden başvuru nasıl okunur?”
• “Kaçırılan sohbet analizi: neden kodları ve aksiyon planı”
• “Canlı destek dönüşüm ölçümü: e-ticaret için pratik rapor şablonu”

KVKK ve güvenlik kontrolü

Türkiye’de canlı destek operasyonu, KVKK ve güvenlik olmadan sürdürülebilir değil. Burada amaç hukuk metni yazmak değil; sistemin günlük işleyişinde veri risklerini azaltmak. Üç konu belirleyici: rıza/aydınlatma, saklama-silme, erişim ve denetim.

Açık rıza ve aydınlatma metni ihtiyaçları

Canlı destek widget’ı üzerinden kişisel veri işlenir: isim, telefon, e-posta, sipariş bilgisi, hatta bazen adres. Bu yüzden aydınlatma metni ve gerektiğinde açık rıza akışı gerekir.

Pratik uygulama:

• Chat başlatmadan önce veya ilk mesajda “Aydınlatma Metni” linki.
• Eğer pazarlama amaçlı iletişim (kampanya mesajı) toplanıyorsa, bunu ayrı rıza olarak ayırın.
• Çocuklara yönelik ürünlerde daha dikkatli olun; yaş doğrulama gerekebilir.

Metinleri hukuk ekibinizle netleştirin; operasyon tarafında önemli olan, müşteriye kolay erişilebilir şekilde sunulmasıdır.

Veri saklama süresi ve silme politikası

Saklama süresi, “her ihtimale karşı” sınırsız olmamalı. İş ihtiyacına göre belirleyin ve araca uygulayın.

Politika bileşenleri:

• Sohbet kayıtları kaç ay/yıl tutulacak?
• Müşteri silme talebi gelirse süreç ne?
• Yedeklerde silme nasıl ele alınacak?
• Export edilmiş dosyalar nerede saklanacak?

Silme talebi için tek bir iletişim kanalı belirleyin ve bunu görünür kılın. Gerekirse iletişim sayfanızda süreç adımlarını netleştirin.

Üçüncü taraf kanal riskleri

WhatsApp, Instagram, Facebook gibi kanallarda veri sadece sizde değil, platformda da bulunur. Bu kanallarda:

• Hesap ele geçirilmesi riski daha yüksek olabilir.
• Yetki yönetimi dağınık kalabilir.
• Veri silme talepleri platform sınırlamalarına takılabilir.

Bu yüzden kritik konuşmaları mümkünse kendi sisteminize taşıyın:

• “Detayları güvenli şekilde paylaşmak için size e-posta ile form gönderebilir miyiz?”
• “Sipariş ekranınızdan chat’e devam edelim” gibi yönlendirme.

Ayrıca temsilcilere net kural: kart bilgisi, şifre, tek kullanımlık kod gibi bilgileri asla istemeyin. Bu kural makrolarda da yazmalı.

Erişim kontrolü ve denetim kayıtları

Güvenlikte en sık açık, fazla yetkidir. Minimum prensip: herkes sadece işini yapacak kadar görsün.

Kontrol listesi:

• Rol bazlı erişim ve iki faktörlü doğrulama açık mı?
• Admin sayısı sınırlı mı, yedek admin var mı?
• Denetim log’ları tutuluyor mu (kim export aldı, kim ayar değiştirdi)?
• Temsilci ayrıldığında erişim aynı gün kapatılıyor mu?

Bu maddeler “kurumsal” görünebilir ama küçük ekiplerde bile kritik. Çünkü canlı destek ekranı, müşteri verisinin en yoğun olduğu yerlerden biridir.

Son not: Operasyonunuzu büyütürken kontrol listelerini güncellemek için Canlı Destek Blog içeriğini takip etmek işinizi kolaylaştırır.

Supporting Article Potential:

• “Canlı destek KVKK kontrol listesi: aydınlatma, saklama, silme”
• “WhatsApp ve Instagram destek kanallarında güvenlik: yetki ve hesap koruması”
• “Canlı destek erişim yönetimi: rol tasarımı ve denetim log’ları”