Çoğu kurumda omnichannel, "web sitesinde de bot var, WhatsApp'ta da var, çağrı merkezinde de var" anlamına geliyor. Kanallar çoğalmış ama her biri kendi hafızasıyla çalışıyor.
Kullanıcı açısından test kolay: WhatsApp'ta yarım kalan bir konuyu telefonda devam ettirmeye çalıştığında baştan anlatmak zorunda kalıyor mu? Kalıyorsa ortada omnichannel bir sistem değil, yan yana duran birkaç ayrı sistem vardır.
Bu farkı kapatan şey yeni bir kanal entegrasyonu değil, dört başlıkta verilen tasarım kararlarıdır.
Önce kimlik: aynı kişi olduğunu nereden biliyorsunuz
Kanal başına farklı bir tanımlayıcı vardır. Web'de çerez ya da oturum kimliği, mobilde uygulama kullanıcı kimliği, WhatsApp'ta telefon numarası, çağrı merkezinde arayan numara. Bağlamı taşımak için önce bunların aynı kişiye ait olduğunu bilmek gerekir.
Burada iki yöntem kullanılıyor. Kesin eşleştirme, doğrulanmış bir bilgiye dayanır: kullanıcı giriş yapmıştır, numarası hesabında kayıtlıdır, doğrulama kodu girmiştir. Olasılıklı eşleştirme ise sinyallerden tahmin yürütür: aynı cihaz, aynı IP, yakın zaman aralığı.
Olasılıklı eşleştirmeyi müşteri hizmetleri akışlarında kullanmamak gerekiyor ve nedeni pazarlama tarafındakinden farklı. Reklam hedeflemede yanlış eşleştirmenin bedeli isabetsiz bir reklamdır. Destek akışında ise yanlış eşleştirme, bir kullanıcıya başkasının sipariş bilgisini göstermek anlamına gelir. Bu, KVKK açısından bir veri ihlalidir.
Bu nedenle önerimiz net: bağlam taşıma yalnızca doğrulanmış kimlik üzerinden yapılsın. Doğrulama yoksa asistan genel bilgi verir, kişiye özel bilgi vermez.
Kanal güven seviyesi kavramı
Sık yapılan bir hata da doğrulama durumunun kanallar arasında taşınmasıdır. Kullanıcı mobil uygulamada oturum açmış olabilir; bu, aynı kişinin telefonda doğrulanmış sayılması için yeterli değildir. Telefon numarası taklit edilebilir, cihaz başkasının elinde olabilir.
İşleyen kurulumlarda her kanala bir güven seviyesi atanır ve hangi işlemin hangi seviyede yapılabileceği önceden tanımlanır. Sipariş durumu sorgulamak düşük seviyede mümkün olabilir, adres değiştirmek ya da bakiye görüntülemek ek doğrulama ister.
Bu tabloyu çıkarmak yarım günlük bir çalışmadır ve sonradan yaşanacak birçok tartışmayı bitirir.
Bağlamda neyin taşınacağı bir karardır
"Konuşma geçmişini taşıyalım" yaklaşımı pratikte iyi çalışmıyor. Uzun geçmişler modeli yanlış yönlendiriyor, gereksiz bilgi taşıyor ve gizlilik açısından da fazla veri içeriyor.
Taşınması gerekenler oldukça sınırlı:
- Kullanıcının doğrulanmış kimliği ve yetki seviyesi
- Son niyet ve o niyete ait açık işlem (varsa talep numarası, sipariş numarası)
- Konuşmanın kısa özeti (birkaç cümle)
- Denenmiş ve sonuç vermemiş adımlar
Taşınmaması gerekenler de en az bunlar kadar önemli: ham konuşma dökümünün tamamı, kanala özgü teknik detaylar ve diğer kanalda alınmış doğrulama durumu.
Bağlamın bir son kullanma tarihi olmalı
Üç gün önceki bir konuşmayı bugünkü mesaja bağlamak, yardımcı olmaktan çok karışıklık üretiyor. Kullanıcı bu kez tamamen farklı bir konuda yazmış olabilir ve asistan eski konuya dönmeye çalışıyor.
Pratikte iyi çalışan yapı, bağlamı iki katmana ayırmak. Aktif konuşma bağlamı kısa ömürlüdür, birkaç saat içinde düşer. Açık işlem bağlamı ise işlem kapanana kadar durur; bir kargo takibi ya da açık bir destek kaydı haftalarca anlamlıdır.
Bu ayrım yapılmadığında iki tipik şikayet ortaya çıkar: "beni hatırlamıyor" ya da "eski konuyu açıp duruyor".
Kanalların kendi kuralları var, akış kopyalanamaz
Aynı senaryoyu her kanala aynen taşımak çalışmıyor, çünkü kanallar teknik ve düzenleyici olarak farklı.
WhatsApp Business Platform'da kullanıcının gönderdiği mesaj 24 saatlik bir müşteri hizmetleri penceresi açar. Bu pencere içinde serbest biçimli mesaj gönderilebilir; pencere kapandıktan sonra yalnızca önceden onaylanmış şablon mesajlar kullanılabilir (Meta geliştirici dokümantasyonu). Yani bir destek akışının "yarın sizi bilgilendireceğim" adımı, kanal kurallarına göre baştan tasarlanmak zorundadır.
Sesli kanalda görsel yoktur; seçenek listesi okunamaz, bağlantı gönderilemez. Web'de dosya yüklenebilir, WhatsApp'ta fotoğraf gelir, telefonda hiçbiri gelmez. Bunlar akışın içeriğini değiştirir, sadece arayüzünü değil.
Değişmemesi gereken tek şey, cevabın kaynağıdır. Kanal başına ayrı bilgi tabanı tutan kurumlarda içerik kaçınılmaz olarak birbirinden ayrışıyor ve aynı soruya kanal başına farklı cevap veriliyor. Tek bilgi tabanı, kanal başına farklı sunum; işleyen model bu.
Devir, otomasyonun kazancının kaybedildiği yerdir
Asistan çözemediğinde temsilciye aktarılan şey çoğu kurulumda ham sohbet geçmişidir. Temsilci bunu okumaz, kullanıcıya "size nasıl yardımcı olabilirim" diye sorar ve kullanıcı her şeyi baştan anlatır.
Bu tek adımda, otomasyondan elde edilen kazanç sıfırlanır ve müşteri deneyimi otomasyonsuz haline göre daha kötü olur, çünkü kullanıcı iki kez anlatmıştır.
Devir paketinin içeriği şu olmalı: kullanıcının doğrulanmış kimliği, talebin tek cümlelik özeti, ilgili kayıt numaraları, asistanın baktığı kaynaklar, denenmiş adımlar ve neden devredildiği. Temsilci ekranında bu paket konuşma geçmişinin üstünde görünmelidir.
Bunun çalışıp çalışmadığını ölçmek de kolay: devir sonrası temsilcinin ilk mesajında bilgi tekrarı isteme oranı. Bu oran yüzde onların üstündeyse devir tasarımı çalışmıyordur.
Kanal karşılaştırmasının en büyük tuzağı
Panolarda kanal bazlı çözüm oranı yan yana gösterilir ve genellikle telefon en kötü performansı sergiliyor gibi görünür. Buradan "sesli kanalı kapatalım" sonucuna varmak yanlış olur.
Nedeni seçim yanlılığı: karmaşık, acil ve duygusal konularda kullanıcılar telefonu tercih eder. Basit sipariş takibi web'de halledilir. Yani kanallar aynı soru dağılımını görmez; performansları da doğrudan karşılaştırılamaz.
Anlamlı karşılaştırma için konu bazında normalize etmek gerekir. Aynı konu türünde kanal başına çözüm oranı karşılaştırıldığında tablo genellikle tersine döner.
İzlenmesi önerilen metrikler:
- Kanal geçişi yaşayan oturumların oranı
- Kanal geçişinde kullanıcının kendini tekrar etme oranı
- Devir sonrası ek bilgi isteme oranı
- Konu bazında normalize edilmiş kanal çözüm oranı
- Kanal başına doğrulama başarısızlığı oranı
Şeffaflık her kanalda geçerli
AB'de faaliyet gösteren kurumlar için Yapay Zeka Tüzüğü'nün 50. maddesi, insanlarla doğrudan etkileşen yapay zeka sistemlerinin bunu bildirmesini zorunlu kılıyor ve bildirimin en geç ilk etkileşimde yapılması gerekiyor. Madde 2 Ağustos 2026'da uygulanmaya başladı (artificialintelligenceact.eu).
Çok kanallı kurulumlarda bunun pratik anlamı, bildirimin her kanalda ayrı ayrı tasarlanması. Web widget'ında bir satır yazı yeterli olabilirken, sesli kanalda görüşmenin ilk cümlesine yerleşmesi gerekir.
Kurulum öncesi kontrol listesi
- Kimlik eşleştirme yalnızca doğrulanmış bilgiye mi dayanıyor
- Her kanalın güven seviyesi ve o seviyede yapılabilecek işlemler tanımlı mı
- Bağlamda hangi alanların taşınacağı yazılı mı
- Aktif konuşma bağlamı ile açık işlem bağlamı ayrı ömürlere sahip mi
- Kanal kısıtları (şablon mesaj, medya, görsel) akışa yansıtıldı mı
- Bilgi tabanı tek mi, kanal başına mı
- Devir paketi tanımlı mı, temsilci ekranında görünüyor mu
- Kanal karşılaştırmaları konu bazında normalize ediliyor mu
Kanalları tek bir zeka katmanında birleştiren mimariyi Omnichannel Asistanlar sayfasında, destek tarafındaki akışları ise Helpdesk Çözümleri sayfasında bulabilirsiniz.
Kaynaklar
- Meta for Developers, WhatsApp Cloud API, mesaj gönderme ve müşteri hizmetleri penceresi. developers.facebook.com
- EU AI Act, Article 50: Transparency Obligations. artificialintelligenceact.eu
- Kişisel Verileri Koruma Kurumu. kvkk.gov.tr