Bu rehberi okuduğunuzda, destek sisteminize giren verinin nasıl gireceğini, ne kadar kalacağını ve nasıl çıkacağını bir kural setine bağlayabileceksiniz. Destek verisi, çoğu şirkette elde tutulan en hassas müşteri verisidir: müşteri sorununu anlatırken kimlik bilgisi, sağlık durumu, finansal detay veya sözleşme içeriği paylaşır ve bunu genellikle serbest metin olarak yapar. Bu yüzden veri yönetimi bir bakım işi değil, bir sorumluluk alanıdır. Aşağıdaki kararlar hukuk danışmanınızla birlikte netleştirilmelidir; bu rehber teknik ve operasyonel tarafı kurmanıza yardımcı olur, hukuki görüş yerine geçmez.
Destek Verisi Neden Farklıdır
CRM'de veri yapılandırılmıştır: alanlar bellidir, hangi bilginin nerede durduğu tanımlıdır. Destek sisteminde ise verinin büyük kısmı serbest metindir. Müşteri e-postasına kimlik numarasını yazar, ekran görüntüsünde başka bir müşterinin bilgisi görünür, temsilci iç notta hassas bir detay paylaşır.
Bunun iki sonucu vardır. Birincisi, hangi hassas verinin nerede olduğunu alan bazında bilemezsiniz. İkincisi, bir silme talebi geldiğinde yalnızca kayıt alanlarını değil, yazışma gövdesini ve ekleri de düşünmek zorundasınızdır.
İçe Aktarma: Tek Seferlik Ama Geri Dönüşü Zor
Başka bir sistemden geçiş yapıyorsanız, içe aktarma kurulumun en riskli adımıdır. Yanlış aktarılan veri sonradan temizlenmez; üzerine iş yapılmaya başlandığı anda kalıcı hale gelir.
Neyi taşımayacağınıza önce karar verin
Taşınan her kayıt, saklama yükümlülüğü ve gürültü getirir.
Kapanmış ve iki yıldan eski taleplerin çoğu yeni sisteme taşınmaz; gerekiyorsa arşiv olarak ayrı tutulur. "Her ihtimale karşı hepsini alalım" kararı, ilk günden kirli bir sistem üretir.
Kişi ve hesapları taleplerden önce aktarın
Bağlantısı kurulamayan talep, sahipsiz veri olarak kalır.
Sıra şudur: hesaplar, kişiler, ürünler, sonra talepler. Ters sırada aktarım, ilişkileri elle düzeltmeyi gerektirir.
Küçük bir örneklemle deneyin
Elli kayıtta görülen hata, elli bin kayıtta felakettir.
Önce sınırlı sayıda kayıt aktarılır, ekranda ve raporda kontrol edilir. Karakter kodlaması, tarih biçimi ve Türkçe karakterler bu aşamada test edilir.
Aktarım öncesi ve sonrası sayıları karşılaştırın
Sessizce düşen kayıtlar en tehlikeli olanlardır.
Kaynak sistemdeki kayıt sayısı ile hedefteki sayı birebir tutmalıdır. Fark varsa sebebi bulunmadan devam edilmez.
İçe aktarma sırasında iş akışı kurallarının ve bildirimlerin devre dışı bırakılıp bırakılmayacağına karar verin. Aksi halde beş yıl önce kapanmış talepler için müşterilere toplu bildirim gidebilir. Bu, geri alınamaz bir hatadır.
Dışa Aktarma ve Yedekleme
Bulut sistemlerde yaygın bir yanılgı vardır: "veri sağlayıcıda, yedek de onlarda". Sağlayıcının altyapı yedeği, sizin veri yedeğiniz değildir. Altyapı yedeği felaket senaryosunu karşılar; sizin ihtiyacınız olan ise kendi kontrolünüzde, okunabilir bir kopyadır.
- Düzenli yedek alın. Sıklık, veri kaybının kabul edilebilir süresine göre belirlenir. Aylık yedek, bir ayı kaybetmeyi göze aldığınız anlamına gelir.
- Yedeği açıp bakın. Test edilmemiş yedek, yedek değildir. Yılda en az bir kez dosya açılır ve içeriğinin okunabilir olduğu doğrulanır.
- Ekleri unutmayın. Talep gövdeleri yedeklenirken ekler kapsam dışında kalabilir. Destek verisinde ekler çoğu zaman içerikten değerlidir.
- Yedeği güvenli tutun. İndirilen yedek dosyası, sistemdeki veriden daha korumasızdır. Erişimi sınırlı ve şifreli bir yerde saklanmalıdır.
- Kim indirebilir, kayıt altına alın. Toplu dışa aktarma yetkisi, veri sızıntısının en kısa yoludur; sınırlı sayıda kişide olmalı ve her indirme izlenmelidir.
Saklama Süresi: Silinmeyen Veri Bir Yükümlülüktür
Şirketlerin çoğunda veri saklama politikası yoktur ve varsayılan davranış "hiçbir şeyi silme" biçimindedir. Bu yaklaşım güvenli görünür ama tersi doğrudur: elinizde tuttuğunuz her kişisel veri, korumakla yükümlü olduğunuz bir varlıktır. Gereksiz veri, gereksiz risktir.
Saklama süresi kararı üç girdiye dayanır ve bu girdilerden en az biri hukuki olduğu için hukuk danışmanınızla birlikte belirlenmelidir.
| Girdi | Ne sorar | Tipik sonuç |
|---|---|---|
| Yasal zorunluluk | Bu kaydı saklamak zorunda mıyız, ne kadar süre | Fatura ve sözleşme ilişkili kayıtlar için belirli bir süre |
| Operasyonel ihtiyaç | Bu geçmişe fiilen bakıyor muyuz | Destek geçmişine genellikle son bir iki yıl içinde bakılır |
| Risk | Bu veri sızarsa ne olur | Hassas içerik taşıyan kayıtlarda süre kısalır |
Politikayı yazdıktan sonra uygulanabilir hale getirmek gerekir. Yazılıp uygulanmayan bir saklama politikası, denetim durumunda yokluğundan daha kötü bir tablo oluşturur; çünkü kuralı bilip uygulamadığınızı gösterir.
Silme ve Bilgi Talepleri
Kişisel Verilerin Korunması Kanunu kapsamında bir kişi, kendisiyle ilgili verilere erişme, düzeltme ve belirli koşullarda silinmesini isteme hakkına sahiptir. Bu talep geldiğinde süre işlemeye başlar ve yanıt vermek zorunludur. Hazırlıksız yakalanmamak için üç şeyin önceden kurulmuş olması gerekir.
Talebin nereye geleceği belli olsun
Sıradan bir destek talebi gibi kuyruğa düşen bir hak talebi, sürede gecikmeye yol açar.
Bu tür talepler için ayrı bir kategori ve ayrı bir yönlendirme kurulur. Talep geldiği anda sorumlu kişi bilgilendirilir.
Kimlik doğrulaması adımı olsun
Doğrulamadan yapılan paylaşım, korumaya çalıştığınız veriyi başkasına vermek demektir.
Talebi yapanın gerçekten veri sahibi olduğu teyit edilmeden hiçbir bilgi paylaşılmaz ve hiçbir silme yapılmaz.
Verinin nerelerde olduğu haritalanmış olsun
Silme talebi yalnızca kişi kaydını değil, geçmişi ve ekleri de kapsar.
Talep gövdeleri, ekler, dışa aktarılmış yedekler, entegre sistemler ve pazarlama listeleri ayrı ayrı düşünülür. Bir yerde kalan kopya, silme işlemini eksik bırakır.
Silme mi anonimleştirme mi olduğuna karar verin
Kaydın tamamen silinmesi, geçmiş raporları da değiştirir.
Yasal saklama yükümlülüğü olan durumlarda tam silme mümkün olmayabilir. Kişiyi tanımlayan bilgilerin kaldırılıp istatistiksel kaydın korunması sık kullanılan yoldur; bu tercihin hukuki uygunluğu ayrıca değerlendirilmelidir.
Yurt dışı veri aktarımı, bulut hizmetlerinde otomatik olarak gündeme gelen bir konudur ve mevzuatı son yıllarda değişmiştir. Hangi verinin nerede işlendiği ve aktarımın hangi hukuki zeminde yapıldığı, sözleşme aşamasında hukuk danışmanınızla netleştirilmelidir. Bu rehber bu konuda görüş içermez.
Erişim İzi ve İç Kontrol
Veri güvenliğindeki en yaygın olay dış saldırı değil, iç erişimdir: yetkisi olan bir kullanıcının ihtiyacı olmayan veriye bakması. Buna karşı üç katman kurulur.
Önleme
Erişim kapsamının dar tutulması. Bir temsilcinin ilgilenmediği departmanın taleplerine erişmemesi. Bu, en etkili katmandır çünkü olay hiç oluşmaz.
Tespit
Kim ne zaman neye baktı, ne değiştirdi, ne indirdi. Denetim kaydı düzenli olarak gözden geçirilmiyorsa yalnızca olay sonrası işe yarar.
- Toplu dışa aktarma yetkisini ayırın. Talep okuma yetkisi ile toplu indirme yetkisi aynı şey değildir.
- Ayrılan çalışanın erişimini aynı gün kapatın. Bu adım için bir kontrol listesi olmalı ve insan kaynakları süreciyle bağlanmalıdır.
- Yönetici hesaplarını sayın. Tam yetkili kullanıcı sayısı, gördüğümüz kurulumların çoğunda olması gerekenin üzerindedir.
- İki adımlı doğrulamayı zorunlu tutun. Destek sistemine erişim, e-posta kutusuna erişimle eşdeğer hassasiyettedir.
Değişiklik Yönetimi ve Test Ortamı
Canlı sistemde yapılan yapılandırma değişiklikleri, veri kadar risklidir. Yanlış kurulan bir kural, bir gecede yüzlerce talebe yanlış bildirim gönderebilir veya alan içeriğini toplu olarak değiştirebilir.
En üst sürümle gelen sandbox, değişikliği canlıya almadan denemenizi sağlar. Sandbox yoksa disiplin şu şekilde kurulur.
Yaz
Değişiklik neyi, neden değiştiriyor. Tek satır bile olsa yazılır.
Daralt
Önce tek bir kategori veya tek bir departmanda açılır. Etki alanı sınırlı tutulur.
İzle
İlk 24 saat sonucu kontrol edilir. Beklenmeyen bildirim veya alan değişikliği aranır.
Genişlet
Sorun yoksa kapsam açılır. Sorun varsa geri alınır ve gerekçe kayda geçer.
Rutine Bağlayın
Veri yönetimi, bir kez yapılıp bitirilen bir iş değildir. Aşağıdaki rutin, gördüğümüz operasyonlarda sürdürülebilir olanıdır.
- Aylık: mükerrer kişi ve hesap temizliği, yedeğin alındığının doğrulanması, yönetici hesap listesinin gözden geçirilmesi.
- Çeyreklik: erişim yetkilerinin gözden geçirilmesi, kullanılmayan alan ve kuralların temizlenmesi, denetim kaydına bakılması.
- Yıllık: yedeğin açılıp okunabilirliğinin test edilmesi, saklama politikasının gözden geçirilmesi, süresi dolan verinin işlenmesi.
Veri düzeni kurulduktan sonra geriye tek bir yapısal karar kalır: Desk'in diğer sistemlerle sınırının nerede çizileceği. Bu, CRM Sınırı, Entegrasyonlar ve Genişletme rehberinin konusudur.
