Açık rıza almak, çoğu acentede üzerinde düşünülmüş bir süreçtir: metin hazırlanır, ekrana onay seçeneği eklenir, kayıt tutulur. Rızanın geri alınması ise genellikle planlanmamış bir durumdur. Müşteri bir gün "artık bu amaçla verilerimin kullanılmasını istemiyorum" dediğinde, acentenin bu talebi hangi kayıtlara, hangi süreçlere ve hangi ekiplere yansıtacağı belli değildir. Oysa açık rızanın geri alınabilir olması, onu diğer işleme şartlarından ayıran temel özelliklerden biridir. Bu yazıda, açık rıza geri alındığında acentede nelerin değişmesi gerektiğini ve bu değişikliğin yazılım tarafında nasıl uygulanabileceğini ele alıyoruz.
Geri alma neden ayrı bir süreç gerektirir?
Açık rıza, ilgili kişinin özgür iradesiyle verdiği bir izindir ve aynı iradeyle her zaman geri alınabilir. Geri alma, rızaya dayanılarak yapılan işlemenin ileriye dönük olarak sona ermesi sonucunu doğurur. Geri alma öncesinde rızaya dayanılarak yapılmış işlemler bu nedenle hukuka aykırı hale gelmez; ancak geri almadan sonra aynı amaçla işlemeye devam edilmesi bir sorun yaratır.
Buradaki zorluk, rızanın genellikle tek bir noktada alınması ama etkisinin birden fazla süreçte görülmesidir. Örneğin kampanya analizleri için alınmış bir rıza; segmentasyon raporlarında, pazarlama listelerinde ve belki de bir iş ortağıyla yapılan paylaşımlarda kullanılıyor olabilir. Geri alma, bu süreçlerin hepsine ulaşmalıdır.
Önce kapsamı belirlemek
Geri alma talebi geldiğinde ilk soru, hangi rızanın geri alındığıdır. Acente farklı amaçlar için ayrı ayrı rıza almışsa, müşteri bunlardan yalnızca birini geri almak isteyebilir. Talebin kapsamı belirsizse müşteriye sormak, gereğinden fazla ya da eksik işlem yapmayı önler.
Bu noktada sık yapılan bir hata, rızanın geri alınmasını tüm ilişkinin sona ermesi gibi yorumlamaktır. Müşteri pazarlama amaçlı rızasını geri aldığında, mevcut poliçesine ilişkin bilgilendirmeler, tahsilat süreçleri ve yenileme işlemleri, rızadan farklı hukuki sebeplere dayanıyorsa devam edebilir. Geri alma, yalnızca rızaya dayanan işlemleri etkiler.
Geri alındığında değişmesi gerekenler
Bir rıza geri alındığında acentede şu başlıkların gözden geçirilmesi gerekir:
- Müşteri kaydındaki rıza durumu: Rızanın geri alındığı tarih, kanal ve kapsamı kaydedilmelidir.
- Pazarlama ve segmentasyon listeleri: Müşteri, rızaya dayanan listelerden çıkarılmalıdır.
- Planlanmış iletişimler: Henüz gönderilmemiş ama planlanmış kampanya iletileri durdurulmalıdır.
- Üçüncü taraf paylaşımları: Rızaya dayanılarak veri paylaşılan taraflar varsa, durum değerlendirilmeli ve gerekirse bilgilendirilmelidir.
- Dışa aktarılmış dosyalar: Daha önce oluşturulmuş pazarlama listelerinin kopyaları kontrol edilmelidir.
- Rızaya bağlı olarak tutulan veriler: Yalnızca rızaya dayanılarak toplanmış ve başka bir işleme sebebi bulunmayan veriler için silme veya anonimleştirme değerlendirilmelidir.
Rıza ile ticari ileti onayını karıştırmamak
Müşteri "bana mesaj atmayın" dediğinde, bu talep hem KVKK kapsamındaki bir rızanın geri alınması hem de ticari elektronik ileti onayının reddi anlamına gelebilir. İki süreç farklı mevzuata tabidir ve ayrı ayrı işlenmelidir. Ticari ileti onayının reddi, İleti Yönetim Sistemi üzerinden de takip edilir ve mevzuatta belirli bir süre içinde gönderimlerin durdurulması öngörülür. Rızanın geri alınması ise pazarlama analizleri gibi farklı işleme faaliyetlerini etkileyebilir. Müşterinin talebini doğru sınıflandırmak, her iki sürecin de eksiksiz yürütülmesini sağlar.
Geri almayı kolaylaştırmak
Rızanın geri alınması, rızanın verilmesi kadar kolay olmalıdır. Rıza bir onay kutusuyla birkaç saniyede verilmişse, geri almak için müşterinin dilekçe yazması ya da şubeye gelmesi beklenmemelidir. Pratik yollar şunlar olabilir:
- Telefonda iletilen geri alma talebini çalışanın doğrudan kayda işleyebilmesi.
- Gönderilen her tanıtım iletisinde basit bir vazgeçme yolu bulunması.
- Web sitesi veya müşteri iletişim kanallarında tercihlerin güncellenebileceği bir yol sunulması.
- Geri alma talebinin hangi kanaldan gelirse gelsin aynı müşteri kaydına yansıması.
Kayıt tutmanın önemi
Rızanın verildiği tarih kadar geri alındığı tarih de önemlidir. Olası bir şikâyette acentenin, belirli bir tarihteki işlemenin o tarihte geçerli bir rızaya dayandığını gösterebilmesi gerekir. Bu nedenle rıza kaydının üzerine yazılarak güncellenmesi yerine, rıza geçmişinin tutulması önerilir: verildiği tarih, hangi metin sürümüyle verildiği, geri alındığı tarih ve kanal. Bu geçmiş, bir ilgili kişi başvurusunda da müşteriye verilecek yanıtın temelini oluşturur.
Ekiplere nasıl yansır?
Rıza geri alındığında en çok etkilenen ekip satış ve pazarlama ekibidir. Bir temsilcinin elindeki kişisel listede geri alma bilgisi bulunmaz; bu yüzden kampanya çalışmalarının yalnızca güncel rıza durumuna göre filtrelenen listelerle yapılması kritik önemdedir. Satış ekibine bu kuralın gerekçesini anlatmak, kişisel listelerin kullanımını azaltmanın da etkili bir yoludur.
Şubeli acentelerde ise geri alma talebi bir şubeye ulaşırken, kampanya merkezden yürütülüyor olabilir. Bu durumda geri alma bilgisinin merkezi müşteri kaydında tutulması ve tüm şubelerin aynı kaydı görmesi gerekir.
Yazılımdan beklenenler
Rıza yönetimini destekleyen bir acente CRM yapısında; amaç bazında rıza durumunun tutulması, rıza geçmişinin saklanması, listelerin rıza durumuna göre filtrelenebilmesi ve geri alma işleminin tüm ilgili ekranlara yansıması beklenir. Ayrıca rıza durumunun mobil uygulama tarafında da görünür olması, sahadaki temsilcinin müşteriyle konuşurken güncel durumu bilmesini sağlar. Bu özelliklerin kullandığınız sigorta acentesi yazılımında nasıl karşılandığını değerlendirirken, demo sırasında bir test kaydında rızayı verip geri alarak listelerin nasıl değiştiğini gözlemlemek iyi bir yöntemdir.
Sonuç
Açık rızanın değeri, geri alınabilir olmasından gelir. Geri alma talebinin kapsamını doğru belirlemek, rızaya dayanan tüm süreçlere yansıtmak, ticari ileti onayından ayırmak ve rıza geçmişini kayıt altında tutmak, acentenin bu talebi güvenle karşılamasını sağlar. Bu yazı genel bilgilendirme amacı taşır; rıza süreçlerinizi hukuk danışmanınızla birlikte değerlendirmenizi öneririz.