🇬🇧 English: Read this in English →

Geçen hafta, abonelik satan binlerce mağazada rutin bir güncelleme yapıldı. Güncellemeyle birlikte, bir müşterinin aboneliğinde kimin değişiklik yapabileceği değişti.

Çoğu kurumda bunu kimse fark etmedi, çünkü güncellemeler otomatik geçiyor ve kimse sürüm notu okumuyor. Oysa bu, yetki ve kontrol konusu: yani iç denetimin, finansın ve müşteri hizmetlerinin ilgi alanı.

Bu yazı tek bir güncelleme hakkında değil. Abonelik ya da tekrarlayan gelir modeliyle çalışan bir kurumda, yazılım güncellemelerinin neden yönetilmesi gereken bir süreç olduğu hakkında.

Tekrarlayan gelir, sessiz bir değişikliğe en duyarlı yerdir

Tek seferlik satışta bir hata olursa, bir sipariş etkilenir ve genellikle aynı gün fark edilir. Abonelikte durum farklıdır: bir hata, her ay tekrarlayan bir hataya dönüşür ve çoğu zaman müşteri şikâyet edene kadar görünmez.

Bu yüzden abonelik altyapısına dokunan her değişiklik, sıradan bir güncellemeden farklı ele alınmalıdır. Söz konusu güncellemede değişen üç şey, tam olarak bu hassasiyetteki alanlara denk geliyor:

  • Yetkilendirme. Bir aboneliğin içeriğini kimin değiştirebileceği artık ayrı bir izne bağlı. Yani dün abonelik kalemi silebilen bir kullanıcı bugün silemeyebilir, ya da tam tersi. Müşteri hizmetleri ekibiniz bir işlemi yapamıyorsa sebebi bu olabilir.
  • Fiyat farkı hesabı. Müşteri paket değiştirdiğinde aradaki farkın nasıl hesaplanacağı, fiziksel ürün içeren aboneliklerde de devreye alınabiliyor. Bu doğrudan faturalandırmayı etkileyen bir ayar.
  • Müşteriye gönderilen bağlantılar. Aboneliği yönetmek için e-postayla gönderilen bağlantıların güvenlik yapısı değişti. Eski e-postalardaki bağlantılar artık çalışmayabilir.

Son madde en çok destek talebi üreten kalemdir, çünkü müşteri bir şeyin değiştiğini bilmez; sadece bağlantının çalışmadığını görür.

Asıl mesele: güncellemeleri kim yönetiyor

Bu olay tek başına küçük. Ortaya çıkardığı soru değil.

Çoğu kurumda mağaza yazılımı otomatik güncellenir. Bu, güvenlik açısından savunulabilir bir tercihtir; kimse aylarca eski sürümde kalmak istemez. Ama otomatik güncelleme aynı zamanda şu anlama gelir: gelirinizi taşıyan sistemin davranışı, sizin onayınız olmadan değişebilir.

Kurumsal bir yapıda doğru düzen ikisinin ortasıdır:

  • Güvenlik yamaları gecikmeden, otomatik geçer.
  • Davranış değiştiren güncellemeler önce bir test ortamında çalışır, gerçek bir yenileme döngüsüyle denenir, sonra planlı biçimde canlıya alınır.
  • Yılın yoğun döneminde ikinci gruba hiç dokunulmaz.

Bu ayrımı yapmayan kurumlar, güncellemeleri ya hiç yapmayarak güvenlik riskine, ya hepsini otomatik yaparak operasyonel riske girerler. İkisi de gereksiz.

Bu hafta sorulması gerekenler

  1. Mağazamız güncellemeleri nasıl alıyor? Otomatik mi, kontrollü mü, yoksa hiç mi?
  2. Abonelik sistemimizde kim ne yapabiliyor? Müşteri hizmetleri, finans ve ajans için bu liste yazılı mı?
  3. Bir güncelleme sonrası bir şeyin bozulduğunu nasıl anlarız? Cevap “müşteri arayınca” ise, bu bir izleme eksiğidir.
  4. Yoğun sezon için bir dondurma takvimimiz var mı? Kasım ve aralıkta kimin neye dokunabileceği belirlenmiş mi?

Biz bu düzeni kuruyoruz

Kurumsal müşteriler için abonelik ve tekrarlayan gelir sistemleri kuruyoruz. İşin görünmeyen ama en değerli kısmı, güncellemelerin nasıl yönetildiğidir: neyin otomatik geçeceği, neyin test edileceği, yoğun sezonda neye dokunulmayacağı.

Mevcut mağazanızın güncelleme düzenini ve yetki haritasını gözden geçirip bir öneri çıkarabiliriz. Bize ulaşın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Close Search Window
↑