Proaktif Destek: Sorun Çıkmadan Müşteriye Ulaşan AI

Kargo firmasının bir deposunda aksama var. Sipariş 900 müşteriye iki gün geç çıkacak. Kimse bir şey söylemiyor. Ertesi sabah çağrı merkezine 400'ün üzerinde "siparişim nerede" çağrısı düşüyor, ortalama bekleme süresi altı dakikaya çıkıyor, o gün başka hiçbir konuya bakılamıyor.

Bu çağrıların neredeyse tamamı önlenebilirdi. Tek bir bildirim, doğru saatte, doğru cümleyle. Proaktif destek dediğimiz şey bundan ibaret: müşteri sizi aramak zorunda kalmadan önce haber vermek. Kulağa basit geliyor, uygulamada iki yerde tökezliyor — hangi olayın bildirime değdiğine karar vermek, ve bildirimi rahatsızlık haline getirmemek. Aşağıda ikisine de bakıyoruz.

Bu, aslında bir çağrı azaltma projesidir

Proaktif destek genelde "müşteri deneyimi" başlığı altında sunulur. Bütçeyi onaylatmak istiyorsanız operasyon başlığı altında sunun, çünkü ölçülebilir tarafı orada.

Çağrı merkezinize gelen trafiği bir hafta boyunca konu bazında ayırın. Çoğu işletmede ilk üç konu, toplam çağrının yarısından fazlasını oluşturur ve neredeyse tamamı bilgi sorusudur: nerede, ne zaman, ne oldu. Bu çağrılar sorun çözmez; sadece bilgi taşır. Bilgiyi önceden taşırsanız çağrı da gelmez.

Yargı cümlesi: proaktif destek kurmadan önce bu ayrıştırmayı yapmayan ekipler, yanlış olaylara bildirim kurup hem parayı hem müşterinin sabrını harcıyor.

Hangi olay bildirime değer?

Ölçüt basit: müşteri bunu birazdan zaten öğrenecekse ve öğrendiğinde sizi arayacaksa, önce siz söyleyin. Öğrenmeyecekse ve bir aksiyonu yoksa, susun.

Bildirime değen tipik olaylar:

• Söz verilen zamanın kayması. Teslimat, randevu, kurulum, servis. En yüksek getirili bildirim türü budur.

• Ödeme veya işlem başarısızlığı. Otomatik ödeme geçmediğinde müşteri bunu genelde hizmet kesildiğinde öğrenir. Aradaki süre sizin lehinize.

• Planlı kesinti veya bakım. Önceden söylenirse bilgi, sonradan söylenirse mazeret olur.

• Belge veya bilgi eksiği. Başvurusu bekleyen müşteriye "şu evrak eksik" demek, o başvurunun bir ay beklemesini önler.

• Yenileme ve son kullanma tarihleri. Sigorta, abonelik, sözleşme. Hatırlatma burada hem hizmet hem satış.

Bildirime değmeyenler de var ve liste sanılandan uzun: kampanya duyuruları, memnuniyet anketleri, "sizi özledik" mesajları. Bunlar pazarlama işi. Proaktif destek kanalına karıştırırsanız, müşteri bir süre sonra gerçekten önemli bildirimi de açmamaya başlıyor. Bu, en sık yapılan hata.

Bildirimin anatomisi

İyi bir proaktif bildirim üç şey söyler, dördüncüsünü söylemez.

Söyler: ne oldu, sizin için ne anlama geliyor, şimdi ne yapmanız gerekiyor (ya da gerekmediği). Söylemez: mazeret. "Yoğunluk nedeniyle" ile başlayan cümleler müşteriyi sinirlendiriyor, çünkü sorunun kendisinden çok işletmenin savunmasını taşıyor.

Bir de yeni bir tarih vermek meselesi var. Emin değilseniz kesin tarih vermeyin; "en geç Cuma" deyip Cumartesi teslim etmek, hiç tarih vermemekten daha kötü. Verdiğiniz her tarih, ikinci bir bildirim borcu yaratıyor.

Zamanlama, Türkiye şartlarında

Bildirim saatinin kuralı yazılı olmalı. Gece 23:00'te düşen bir "siparişiniz gecikecek" mesajı, sabah 09:00'da düşenle aynı bilgi değil; biri hizmet, diğeri rahatsızlık.

Pratikte işleyen sınırlar: acil olmayan bildirimler mesai saatleri içinde, resmî tatillerde ve bayram arifelerinde ertelenmiş, arka arkaya gelen bildirimler tek mesajda birleştirilmiş. Son maddeyi atlamayın — üç ayrı sistem üç ayrı mesaj gönderdiğinde müşteri üç ayrı sorun olduğunu sanıyor ve doğrudan çağrı merkezini arıyor. Yani proaktif bildirim, kurgusu bozuksa çağrı azaltmıyor, artırıyor.

Bunu önlemek için bildirimlerin tek bir yerden çıkması gerekiyor. Sipariş sistemi, kargo entegrasyonu ve destek tarafı ayrı ayrı mesaj atıyorsa entegrasyon tarafında bir birleştirme katmanı kurmadan bu iş düzelmiyor.

Ters tepen proaktiflik

Sahada gördüğüm üç kaza:

Yanlış müşteriye doğru bildirim. Segment filtresi kayarsa, siparişi zamanında çıkan müşteriye gecikme mesajı gider. O müşteri hem sizi arar hem güvenini kaybeder.

Bildirim var, cevap yeri yok. Mesajı okuyan müşteri "peki ben ne yapacağım" diye yanıt yazar; kimse okumaz. Tek yönlü bildirim kanalı kurmayın. Gelen yanıtın nereye düşeceği, bildirimden önce çözülmeli — sipariş takibi akışlarında bu en çok atlanan adım.

Aşırı bildirim. Her adımda mesaj atan sistem, birkaç hafta içinde okunmaz hale geliyor. Müşteri başına haftalık bildirim üst sınırı koyun; sınırı aşan bildirimler birleştirilsin ya da düşürülsün.

Ölçüm: hangi sayı düşerse işe yaradı

Tek bir sayıya bakacaksanız: bildirim gönderilen konudaki çağrı hacmi. Kargo bildirimini açtınız, "siparişim nerede" çağrıları düşmediyse bildirim ya geç gidiyor ya yanlış şey söylüyor.

Yanında izlenecekler: bildirim sonrası gelen yanıt oranı (yüksekse bildiriminiz eksik bilgi veriyor demektir), kanal engelleme ve abonelikten çıkma sayısı, ilk temasta çözüm oranı. Memnuniyet skoru da bakılır ama geç sinyal verir; operasyonel sayılar daha erken konuşur.

İlk 30 gün

Baştan on olay tanımlamayın. Tek bir olayla başlayın — tercihen çağrı hacminin en büyüğüyle. Bildirim metnini iki farklı şekilde yazın, ikisini de deneyin. Dördüncü haftada o konudaki çağrı sayısına bakın.

İkinci ay ikinci olayı ekleyin. Bu tempoda ilerleyen ekipler, altı ay sonunda çağrı trafiğinin şeklini gerçekten değiştiriyor; hepsini birden açanlar genelde ikinci ayda bildirimleri kapatmak zorunda kalıyor.

AI Agent TR ile kurulan müşteri hizmeti akışlarında da sıra genelde böyle işliyor. Kendi çağrı trafiğinizde hangi konunun bildirime değdiğine birlikte bakalım isterseniz, demo talebi bırakın.

Sıkça Sorulan Sorular

Proaktif bildirim müşteriyi rahatsız eder mi?

İçeriği aksiyon taşıyorsa etmiyor. Rahatsız eden şey bildirimin kendisi değil, pazarlama mesajlarının aynı kanaldan gelmesi ve sıklığın kontrolsüz olması.

Kötü haberi söylemek şikâyeti artırmaz mı?

Kısa vadede birkaç yanıt gelir, evet. Ama aynı bilgiyi müşteri kendi keşfettiğinde gelen tepki daha sert oluyor ve o çağrı merkezinize düşüyor. Erken söylemenin bedeli daha düşük.

Küçük bir ekiple bu kurulur mu?

Kurulur. Tek olayla başlayan bir akış, birkaç günlük iş. Zorluk teknolojide değil, hangi olayın bildirime değdiğine karar vermekte.

Bildirimden sonra müşteri yanıt yazarsa ne olmalı?

Yanıt bir destek kaydına dönüşmeli ve aynı konuşma içinde yanıtlanmalı. Müşteriyi ayrı bir kanala yönlendiren bildirimler, kazandırdığı zamanı geri veriyor.