Canlı Destek Kurulumu ve Operasyon Checklisti

Canlı destek kurmak “widget’ı siteye koyduk, bitti” işi değil. Satışa dokunan, destek yükünü azaltan, KVKK’ya takılmayan ve ekip tarafından gerçekten kullanılan bir düzenek kurmanız gerekiyor. Aşağıdaki checklist’i kurulumdan operasyona kadar adım adım tikleyerek ilerleyin. Detaylı kurulum anlatımı için ayrıca canlı destek kurulumu ve yönetimi rehberi içeriğine de göz atabilirsiniz.

Hedef ve kapsam kilidi

Kurulumun ilk yarım saati, sonraki 3 ayın kalitesini belirler. Bu bölümde “neyi çözüyoruz, neyi çözmüyoruz?” netleşmeden araca geçmeyin.

Birincil hedefler satış dönüşümü ve destek verimliliği

• Canlı desteğin birincil hedefini yazın: satış dönüşümü mü, destek verimliliği mi, ikisi mi?
• Satış odaklıysa: hedef sayfaları seçin (ürün, sepet, ödeme, kargo/iade). Her sayfa için “chat açılınca beklenen aksiyon” belirleyin (kupon, alternatif ürün, ödeme adımı desteği).
• Destek odaklıysa: ilk 10 konu başlığını çıkarın (kargo, iade, üyelik, ödeme, fatura) ve hangi oranının self-servis, hangisinin temsilci ile çözülmesi gerektiğini not edin.
• 2–3 KPI seçin ve hedef koyun: ilk yanıt süresi, çözüm süresi, chat başına mesaj sayısı, satışa etki için chat kaynaklı sipariş etiketi.

Kapsam dışı senaryolar ve eskalasyon sınırları

• Kapsam dışını net yazın: hukuki talepler, KVKK başvuruları, finansal itirazlar, tehdit/istismar, tedarikçi anlaşmazlıkları.
• Temsilcinin “durup eskale edeceği” çizgiyi koyun:
  • Ödeme provizyon/chargeback: finans ekibine
  • Kişisel veri silme talebi: KVKK sorumlusuna
  • Teknik hata (500, ödeme ekranı çöküyor): ürün/teknik ekibe
• Eskalasyon için tek format belirleyin: kısa özet + ekran görüntüsü + kullanıcı bilgisi + URL + zaman damgası. Bu formatı SOP olarak saklayın.

Başarı kriterleri ve sahiplik onayı

• “Kim sahip?” sorusunu yazılı kapatın:
  • Operasyon sahibi (destek lideri)
  • Teknik sahibi (frontend/CRM entegrasyon)
  • İçerik sahibi (hazır cevaplar, bot akışları)
• Yayına çıkış için onay kapıları koyun: KVKK onayı, marka dili onayı, performans onayı.
• Haftalık kontrol toplantısı için 20 dakikalık sabit ajanda tanımlayın: metrikler, top 5 konu, top 5 kaçan fırsat, aksiyon listesi.

Kanal ve cihaz kapsamı

Canlı desteği “webde var” diye işaretleyip geçmeyin. Kullanıcı kitleniz mobildeyse, yanlış bir kapsam kararı tüm deneyimi bozar.

Web masaüstü ve mobil web kapsamı

• Widget’ın masaüstü ve mobil web’de davranışını ayrı ayrı kontrol edin:
  • Mobilde kaplama (overlay) yapıp sayfayı kilitliyor mu?
  • Klavye açılınca input alanı görünür kalıyor mu?
• Mobil web için kurallar:
  • Tetikleyicileri daha konservatif kullanın (ör. sayfada 20 sn yerine 45–60 sn).
  • Kapatma (X) ve küçültme butonları tek elle erişilebilir olmalı.
• Mobil veri tüketimi için görselleri sınırlayın; widget asset’leri mümkünse 200KB altı olacak şekilde optimize edin.

Mobil uygulama SDK gereksinimleri

• Uygulamanız varsa “sonra bakarız” demeyin; SDK entegrasyonu ayrı backlog ister.
• Checklist:
  • iOS/Android SDK uyumluluğu (minimum OS sürümü)
  • Push bildirim gereksinimi (temsilci yanıtı geldiğinde kullanıcıya bildirim)
  • Oturum/kimlik eşleme (app login ile chat identity)
• Uygulama içinde hangi ekranlarda chat görünecek? Sepet/ödeme ekranlarında “tam ekran chat” yerine küçültülebilir panel daha iyi çalışır.

WhatsApp ve Instagram yönlendirme senaryoları

• Her kanalı canlı destek yerine koymaya çalışmayın. WhatsApp/IG genelde “devam eden konuşma” için iyi, anlık satış engeli için her zaman değil.
• Yönlendirme kuralı yazın:
  • “Sipariş takibi” gibi konular WhatsApp’a
  • “Ödeme adımı hatası” canlı chat’te kalır
• UTM ve kaynak takibi: WhatsApp linklerine kaynak parametresi ekleyin, “chatten WhatsApp’a geçti” olayını raporlayın.
• Resmi kanallar: WhatsApp Business ve Instagram üzerinden işletme doğrulama ve mesaj şablonu süreçlerini önceden planlayın.

Widget ve marka uyumu

Widget iyi çalışsa bile “marka dışı” konuşuyorsa güven kaybettirir. Bir de performansı bozuyorsa, SEO ve dönüşüm tarafında bedeli olur.

Konumlandırma ve tetikleyici kuralları

• Varsayılan konum: sağ alt genelde standart, ama çakışmaları kontrol edin (çerez bildirimi, kampanya barı, ödeme butonu).
• Tetikleyicileri sayfa bazında yazın:
  1. Sepette exit-intent (masaüstü) veya “geri” davranışı
  2. Ödeme sayfasında hata yakalanırsa (validation error) chat önerisi
  3. Ürün sayfasında 2. kez aynı ürüne dönüşte proaktif mesaj
• Proaktif mesaj metni kısa olmalı: 90–120 karakter aralığını hedefleyin. “Yardımcı olayım mı?” yerine bağlam verin: “Beden/ölçü konusunda destek ister misiniz?”

Dil tonu ve mikro metin kontrolü

• Mikro metin checklist’i:
  • Karşılama: tek cümle, net vaat (ör. “Kargo ve iade sorularını hemen yanıtlayabilirim.”)
  • Bekleme mesajı: süre ve alternatif (ör. “2–3 dk içinde döneceğiz, isterseniz form bırakın.”)
  • Offline mesajı: ne zaman dönüş + kanal
• Temsilci imzası standardı: ad + ekip (örn. “Ayşe | Müşteri Deneyimi”). Kopyala-yapıştır imza karmaşasını bitirir.

Erişilebilirlik ve performans etkisi

• Erişilebilirlik:
  • Kontrast oranlarını kontrol edin, metin 14px altına düşmesin.
  • Klavye ile aç/kapat yapılabiliyor mu?
• Performans:
  • Widget script’ini mümkünse async yükleyin.
  • Sayfa yükleme hedefi: LCP 2.5 saniye altı. Widget ekledikten sonra ölçün; kötüleşiyorsa tetikleme gecikmesi veya lazy-load düşünün.
• Cookie/consent: Çerez onayı olmadan takip yapan widget ayarlarını kapatın.

Kurulum ve entegrasyon adımları

Kurulumda küçük bir hata (ortam ayrımı yok, olaylar eksik) raporlamayı ve otomasyonu bozar. Baştan düzenli kurarsanız ileride çok zaman kazanırsınız.

Etiket kurulumu ve ortam ayrımı

• Tag Manager kullanıyorsanız canlı destek tag’ini ayrı bir container/etiket grubu olarak yönetin.
• Ortam ayrımı checklist’i:
  • Test (staging) ve canlı (prod) için ayrı widget/anahtar
  • Staging’de “internal only” kuralı (IP allowlist veya gizli parametre)
  • Sürüm notu: hangi tarihte hangi ayar değişti
• Yayın öncesi: staging’de çalışan bir şeyin prod’da CSP/consent yüzünden bozulduğunu çok görürsünüz. CSP (Content Security Policy) whitelist’i erken planlayın.

E ticaret olayları ve sayfa bağlamı

• Temsilcinin “kullanıcı nerede?” sorusunu sormasını engelleyin. Sayfa bağlamı otomatik gelsin:
  • URL, sayfa tipi (ürün/sepet/checkout)
  • Ürün adı, SKU, fiyat
  • Sepet tutarı ve adet (varsa)
• Olay seti (minimum):
  • view_product, add_to_cart, begin_checkout, purchase
  • ödeme hatası (varsa) ve hata kodu
• Bu olaylar hem temsilci ekranına hem raporlamaya akmalı. Yoksa canlı destek sadece sohbet kutusu olarak kalır.

CRM ve helpdesk veri akışı

• “Chat bitti, sonra ne olacak?” sorusunu akışa bağlayın:
  • Müşteri profiline sohbet dökümü düşsün
  • Etiketler CRM’e gitsin (konu, sonuç, satış fırsatı)
• Entegrasyon seçenekleri: HubSpot, Zendesk, Freshdesk gibi araçlarla iki yönlü kimlik eşleme planlayın.
• Veri alanları standardı belirleyin: e-posta, telefon, sipariş no, konu etiketi, çözüm kodu. “Serbest metin” büyüdükçe rapor çöker.

Ekip ve vardiya kurgusu

Canlı destek, ekip planı olmadan açıldığında en hızlı “kötü deneyim” üreten kanallardan biri. Kullanıcı anında cevap bekler. Yanıt yoksa sinir var.

Rol ve yetki matrisi

• Roller:
  • Temsilci: yanıtlar, etiketler, gerekli alanları doldurur
  • Takım lideri: eskalasyon, kalite kontrol, vardiya düzeni
  • Admin: kurallar, entegrasyon, güvenlik
• Yetkiler checklist’i:
  • Hazır cevap düzenleme kimde?
  • Bot akışı düzenleme kimde?
  • KVKK silme taleplerini kim işliyor?
• Minimum prensip: gereken kadar erişim. Admin sayısını sınırlayın, değişiklikleri loglayın.

Vardiya planı ve kapasite hesabı

• Kapasiteyi kabaca hesaplayın:
  • Ortalama chat süresi (ör. 6–10 dk)
  • Eş zamanlı chat limiti (yeni başlayan için 2, deneyimli için 3–4)
• Vardiya checklist’i:
  • Pik saatleri GA4/CRM’den çıkarın
  • Haftanın günlerine göre ayrı plan yapın
  • Öğle arası için “gölge vardiya” bırakın
• SLA hedefi koyun: canlı chat’te ilk yanıt 60–120 sn aralığı çoğu e-ticarette gerçekçidir. Daha iddialıysanız kapasiteyi artırmanız gerekir.

Yoğunluk planı ve yedekleme

• Kampanya günleri için playbook:
  • Eş zamanlı chat limiti düşür, hız kazan
  • Proaktif tetikleyicileri azalt, kuyruk şişmesin
  • Bot daha fazla filtrelesin (sık sorular)
• Yedekleme: bir temsilci bağlantı sorunu yaşarsa devralacak kişi belli olsun. “Kim boşsa baksın” pratikte çalışmaz.

Atama ve yönlendirme kuralları

Atama kuralları iyi değilse en iyi temsilci bile verimsiz çalışır. Kuyruk doğru akmıyorsa SLA da tutmaz.

Kuyruk mantığı ve önceliklendirme

• Öncelik seviyeleri tanımlayın:
  1. Ödeme/checkout hataları
  2. Sepet ve kargo ücretleri
  3. Sipariş sonrası destek
• VIP/üyelik seviyesi varsa ayrı kuyruk düşünün ama abartmayın; fazla kuyruk yönetimi zorlaştırır.
• “Boşta olana ata” yerine dengeli dağıtım: temsilci başına aktif chat sayısını eşitleyin.

Uzmanlık bazlı yönlendirme

• Uzmanlık etiketleri oluşturun: ödeme, iade, teknik, ürün bilgisi, B2B.
• Yönlendirme sinyalleri:
  • Sayfa bağlamı (checkout ise ödeme uzmanı)
  • Kullanıcının seçtiği konu (form dropdown)
  • Botun niyet tahmini (varsa)
• Temsilciye “yetkin değilse” tek tıkla devretme opsiyonu verin. Ama devretme sebebi seçtirmeyi unutmayın; rapor için altın değerinde.

SLA uyarıları ve yeniden atama

• SLA alarm eşikleri:
  • 60 sn: temsilciye uyarı
  • 120 sn: lider uyarısı
  • 180 sn: otomatik yeniden atama veya offline’a teklif
• Yeniden atamada müşteri tekrar hikaye anlatmasın. Önceki mesajlar ve sayfa bağlamı yeni temsilciye otomatik taşınmalı.

Hazır cevap kütüphanesi

Hazır cevaplar, hız kadar tutarlılık da sağlar. Ama kontrolsüz büyürse çöplüğe döner.

Kategori yapısı ve sahiplik

• Kategori önerisi:
  • Kargo ve teslimat
  • İade/değişim
  • Ödeme ve fatura
  • Ürün özellikleri ve ölçü
  • Kampanya/kupon
• Her kategori için bir sahip atayın. Sahipsiz kütüphane 1 ayda bozulur.
• Kütüphaneye “kullanım sayısı” metriği ekleyin. Kullanılmayan cevaplar ya kötü yazılmıştır ya da yanlış yerde duruyordur.

Onay süreci ve güncelleme sıklığı

• Onay akışı:
  1. Taslak (temsilci/lider)
  2. Marka dili kontrolü
  3. Hukuk/KVKK kontrolü (gerekiyorsa)
  4. Yayın
• Güncelleme ritmi: minimum ayda 1, kampanya dönemlerinde haftalık mini revizyon.
• Tarih damgası koyun: “Son güncelleme: 2026-02”. Eski metinleri yakalamayı kolaylaştırır.

Kişiselleştirme değişkenleri

• Değişkenleri standardize edin:
  • {ad}, {siparis_no}, {kargo_firmasi}, {tahmini_teslim}
• Değişken boş gelirse ne olacak? Fallback metin yazın. “Merhaba ,” gibi hatalar güveni düşürür.
• Kişiselleştirme kuralı: tek mesajda 1–2 değişkeni geçmeyin; fazlası yapay durur.

Chatbot devretme akışı

Bot iyi filtreler, temsilciyi rahatlatır. Kötü bot ise canlı desteğe öfkeyle gelen kullanıcı üretir. Devretme akışını net kurun. Bu konuda daha geniş anlatım için chatbot devretme akışı nasıl çalışır içeriği faydalı olur.

Devretme tetikleyicileri ve eşikler

• Devretme tetikleyicileri:
  • Kullanıcı “temsilci” yazarsa
  • 2 kez üst üste “işe yaramadı” seçimi
  • Bot 2 turda niyeti anlayamazsa
• Eşik koyun: bot 3. soruyu soruyorsa genelde geç kalmıştır. 2 tur iyi bir sınır.
• Kuyruk doluysa: temsilciye devretmek yerine offline form veya WhatsApp seçeneği sunun.

Bağlam aktarımı ve müşteri özeti

• Temsilciye aktarılacak minimum özet:
  • Konu (niyet)
  • Kullanıcının seçtiği seçenekler
  • Sipariş no (varsa)
  • Hata mesajı ekran görüntüsü linki (varsa)
• “Özet şablonu” kullanın: 2 satırda okunmalı. Temsilci, 30 saniyede bağlamı kapmalı.

Devretme sonrası takip adımları

• Devretme sonrası checklist:
  • Bot konuşmayı kapatmaz, sadece geri çekilir
  • Temsilci selamlaşma yerine doğrudan özete referans verir: “Ödeme adımında X hatasını görmüşsünüz…”
  • Çözüm sonrası etiket zorunlu: “bot devretti” + konu + sonuç kodu
• Botun öğrenmesi için başarısız devretmeleri işaretleyin. Haftalık 10 örnek bile ciddi iyileştirme sağlar.

Offline ve ticket akışı

Canlı destek 7/24 değilse, offline akış “ikinci sınıf” kalmamalı. Aksi halde kullanıcı kaybolur.

Offline form alanları ve zorunluluklar

• Zorunlu alanlar:
  • E-posta veya telefon (tekini zorunlu yapın)
  • Konu seçimi (dropdown)
  • Mesaj
• Opsiyonel ama değerli:
  • Sipariş numarası
  • Ekran görüntüsü yükleme
• Formu uzatmayın. 5 alanı geçince terk oranı artar. Kısa tutun, sonra gerekirse ticket içinde tamamlatın.

Ticket kategorileri ve yönlendirme

• Ticket kategorileri canlı destek etiketleriyle aynı olsun. Aksi halde raporlar parçalanır.
• Yönlendirme:
  • İade/değişim: operasyon
  • Ödeme: finans/teknik karma (triage kuralı yazın)
  • Teknik hata: ürün/teknik
• Ticket açılınca otomatik yanıt: “talebini aldık” + beklenen dönüş süresi + takip linki.

Yanıt süresi taahhüdü ve bildirimler

• Taahhüt gerçekçi olmalı: “24 saat” deyip 3 gün dönmek güveni bitirir.
• Bildirim checklist’i:
  • Kullanıcıya e-posta bildirimi (ticket açıldı)
  • Temsilciye/ekibe bildirim (kuyruk)
  • SLA yaklaşınca lider uyarısı
• Mesai dışı gelen ticket’larda otomatik mesaj: “Şu saatlerde yanıtlıyoruz” net olsun.

Raporlama ve KPI seti

Rapor yoksa iyileştirme yok. Ama 30 metrik de istemiyorsunuz. Az ve işlevsel bir set kurun.

Operasyon KPIları ilk yanıt ve çözüm

• Takip edilecek temel metrikler:
  • İlk yanıt süresi (median ve p90)
  • Çözüm süresi
  • İlk temasta çözüm oranı (FCR)
  • Temsilci başına chat sayısı
• Haftalık raporda p90’a bakın. Ortalama sizi kandırır; kötü deneyim p90’da saklanır.

Satış KPIları dönüşüm ve gelir etkisi

• Satış etkisini ölçmek için minimum:
  • “Chat başladı” olayı
  • “Chat sonrası satın aldı” eşlemesi (oturum veya kullanıcı bazlı)
• Segmentleyin:
  • Sepet/checkout’ta chat açanların dönüşümü
  • Ürün sayfasında chat açanların dönüşümü
• Bu noktada araç seçimi ve event seti kritik. Canlı destek aracı ile analitik/CRM arasında düzgün köprü kurmadan “gelir etkisi” sadece tahmin olur.

Kalite KPIları memnuniyet ve denetim

• CSAT kısa olmalı: 1 soru + opsiyonel yorum.
• Kalite denetimi:
  • Haftada temsilci başına 3 görüşme örneklemi
  • Skor kart: doğruluk, hız, dil tonu, çözüm netliği
• Kırmızı bayraklar: kopyala-yapıştır paragraflar, sorunu okumadan yanıt, gereksiz eskalasyon.

KVKK ve veri kontrolleri

Canlı destek, kişisel veri toplamanın en hızlı yollarından biri. Bu yüzden KVKK kontrolü “sonradan” değil, tasarımın parçası olmalı.

Aydınlatma metni ve açık rıza noktaları

• Widget içinde aydınlatma metnine erişim verin: kısa link + detay sayfa.
• Açık rıza gerektiren yerleri ayırın: pazarlama izni ile destek amaçlı iletişimi karıştırmayın.
• Formlarda “zorunlu” alanları minimumda tutun. Gereksiz telefon istemek risk doğurur.

Veri saklama süresi ve silme süreçleri

• Saklama süresi politikasını yazın: chat kayıtları kaç ay/yıl tutulacak?
• Silme checklist’i:
  • Kullanıcı talebiyle silme (kim doğrulama adımı ile)
  • Otomatik periyodik silme (retention)
  • Yedeklerde silme prosedürü (en azından süreç tanımı)
• “Silindi” demek için sistemler arası tutarlılık gerekir: canlı destek, CRM, helpdesk.

Yetkilendirme kayıtları ve erişim logları

• Admin/leader erişimlerini loglayın: kim, ne zaman, hangi kayda baktı/değiştirdi.
• 2FA zorunlu olsun.
• Ayrılan çalışan için offboarding checklist’i: aynı gün erişim kapatma, API anahtarlarını döndürme.

Yayın öncesi test planı

Yayın öncesi test, canlı destek projelerinin en çok atlanan kısmı. Sonra “müşteri yazdı ama düşmedi” gibi can yakan sorunlar çıkar.

Kanal cihaz tarayıcı testleri

• Test matrisi oluşturun:
  • iOS Safari, Android Chrome
  • Masaüstü Chrome, Safari, Edge
• Kontroller:
  • Açılış, kapanış, minimize
  • Klavye açılınca input görünürlüğü
  • Çok uzun mesaj, emoji, link gönderimi
• Görsel yükleme varsa dosya limitini netleştirin (ör. 5MB). Büyük dosyada hata mesajı anlaşılır olmalı.

Atama devretme offline senaryo testleri

• Senaryo testleri (tik kutusu gibi ilerleyin):
  1. Bot 2 tur sonra temsilciye devreder
  2. Temsilci meşgul, kuyrukta bekler, SLA uyarısı çalışır
  3. Mesai dışı: offline form açılır, ticket oluşur
  4. Yeniden atama: temsilci bağlantı kopar, konuşma kaybolmaz
• Her senaryoda log alın: konuşma ID, zaman, atanan kişi, sonuç etiketi.

Güvenlik performans ve izleme kontrolleri

• Güvenlik:
  • XSS riskine karşı mesaj içerikleri render kontrolü
  • Yetkisiz erişim denemeleri için rate limit (varsa)
• Performans:
  • Widget eklenince Core Web Vitals değişimi
• İzleme:
  • Widget yüklenmediğinde alarm (console error takibi)
  • Chat başlatma oranı aniden düşerse bildirim

İlk 30 gün iyileştirme döngüsü

Kurulum bittiğinde iş yeni başlar. İlk 30 günde kural revizyonu yapmazsanız canlı destek ya pahalılaşır ya da kalitesizleşir.

Haftalık metrik gözden geçirme ritmi

• Haftalık 30 dakika:
  • İlk yanıt p90, kaçırılan chat, kuyrukta terk
  • En yoğun saatler ve kapasite uyumu
  • En çok kullanılan hazır cevaplar ve işe yaramayanlar
• Tek sayfalık dashboard yeter. Karmaşık raporlar ekip tarafından takip edilmiyor.

En çok gelen konulara göre içerik güncelleme

• İlk 2 haftada en çok gelen 10 konuyu çıkarın.
• Aksiyon:
  • 3 konu için yeni hazır cevap yazın
  • 2 konu için bot akışına yeni kısa yol ekleyin
  • 1 konu için site içeriği/SSS güncelleyin
• İçerik havuzu için Canlı Destek Blog ve özellikle canlı destek kurulum içerikleri kategorisi iyi bir referans noktasıdır.

Kural ve akış revizyonları

• Proaktif tetikleyiciler fazla chat başlatıp SLA’yı bozuyorsa azaltın.
• Yönlendirme kuralları yanlış uzmanlığa atıyorsa, sinyali değiştirin (sayfa bağlamı > kullanıcı seçimi gibi).
• 30 gün sonunda “v2 ayar seti” çıkarın ve değişiklikleri notlayın. Bu notlar 12–18 ay sonra içerik/operasyon yenilerken hayat kurtarır.