SaaS uygulamaları için müşteri offboarding oyun planı: adım adım

İyi bir offboarding nasıl görünür

Müşteri offboarding, bir müşterinin SaaS uygulamanızla ilişkisinin kontrollü bir şekilde sona erdirilmesidir. Basitçe söylemek gerekirse, doğru sırada üç şey olur: müşteri verisini alır, erişimi kapatılır ve ödemeleri durur. İyi bir offboarding ayrıca her iki tarafın da “Evet, bu tamamlandı.” diyebilmesi için bir kağıt izi bırakır.

İşte SaaS için bir müşteri offboarding oyun planının değer kazandığı yer: offboarding kolayca bozulur. En yaygın nedenler belirsiz sahiplik (her adımı kimin yapacağı), aceleyle yapılan zamanlama (bugün iptal edildi, export dün gerekiyordu) ve eksik envanter (kimse ek API anahtarını, ikinci çalışma alanını veya farklı e-postaya bağlı faturayı hatırlamıyor) olur.

Temiz bir offboarding, açıklaması kolay ve kanıtlanması basit sonuçlara ulaşmayı hedefler:

• Veriler kullanılabilir bir formatta dışa aktarılır ve doğru kişiye teslim edilir.
• Tüm erişimler kaldırılır (kullanıcılar, roller, API anahtarları, servis hesapları, entegrasyonlar).
• Abonelikler iptal edilir ve varsa son faturalar veya iadeler kapatılır.
• Silinmesi istenen veriler, kararlaştırılan zaman çizelgesinde tamamlanır.
• Sorular çıkarsa diye zaman damgaları, kimlikler ve onaylar gibi kanıtlar kaydedilir.

Kısa bir örnek: bir müşteri ay sonunda ayrılmak ister. İyi bir süreç, önce kimin export isteyebileceğini, “tüm veriler”in neyi kapsadığını ve silme mi yoksa sadece hesabın kapatılması mı gerektiğini doğrular. Bundan sonra her seferinde aynı kontrol listesini uygularsınız ve ilerledikçe her onayı kaydedersiniz.

Bunların tutarlı kalmasını istiyorsanız, offboarding'i diğer iş akışları gibi ele alın: bir sahip atayın, teslim tarihleri belirleyin ve tamamlanmayı tek bir yerde takip edin (bazı ekipler dahili bir offboarding takipçisi oluşturmak için no-code araçlar kullanır; örneğin AppMaster).

Başlamadan önce: kapsamı ve sahipleri doğrulayın

Offboarding, tek bir net soruyla başlamalı: bunu kim istedi ve kim onaylayabilir? Talepler bir müşteri yöneticisinden, satın alma ekibinden, hukuktan veya bir destek ajanının ilettiği bir mesajdan gelebilir. Hesabı kapatma ve veri exportunu kabul etme yetkisine sahip isimlendirilmiş bir onaylayıcınız olduğundan emin olun.

Sonra kapsamı sade bir dille kaydedin. SaaS hesapları genellikle birden fazla çalışma alanına, organizasyona, ekibe ve ortama (production, staging, sandbox) yayılır. Birini kaçırırsanız, müşteri yok olduğunu varsaydığı erişim veya verilerle karşılaşabilir.

Eli dokunmadan önce dört şeyi yazın:

• İsteyen ve onaylayıcı: isimler, roller ve onayın nasıl doğrulanacağı
• Kapsam: hangi org/çalışma alanları/ekipler ve hangi ortamların dahil olduğu
• Ana tarihler: export penceresi, son fatura tarihi ve kapanış tarihi
• Veri kuralları: ne silinecek, ne saklanacak ve neden (örneğin vergi için faturalar)

Saklama ile silme arasındaki farkı açıkça belirtin. Birçok ekip muhasebe, dolandırıcılık önleme veya denetim kayıtları için sınırlı kayıtlar tutar. Bu olabilir, ancak yalnızca bunu önceden belirtir ve basitçe açıklarsanız (hangi veri, ne kadar süre, kim erişebilir) sorun olmaz.

Kısa bir örnek: bir müşteri “Lütfen hesabımızı kapatın.” der. Siz kısa bir onayla yanıt verirsiniz: “Workspace A ve Workspace B'nin Production verilerini dışa aktaracağız. Cuma günü tüm kullanıcı erişimlerini ve API anahtarlarını iptal edeceğiz. Faturalama bir sonraki fatura tarihinde sona erecek. Export teslim edildikten sonra uygulama verilerini sileceğiz, ancak faturaları 7 yıl saklayacağız.” Bu netlik çoğu anlaşmazlığı önler ve offboarding sürecinizi sakin ve öngörülebilir kılar.

Bir offboarding envanteri oluşturun (veri, erişim, faturalama, entegrasyonlar)

Offboarding, önce gerçekte kapatacağınız şeyleri yazdığınızda sorunsuz ilerler. Bunu SaaS için müşteri offboarding oyun planınızın haritası olarak düşünün: verinin bulunduğu her yer, birinin hâlâ erişebileceği her yol ve sizi faturalandırmaya devam edebilecek her sistem.

Veri konumlarıyla başlayın. Ana veritabanınız yalnızca bir parça olabilir. Müşteri bilgileri genellikle dosyalara, loglara ve sonradan eklenen araçlara yayılır.

Müşteri verisinin olabileceği yaygın yerler:

• Uygulama veritabanı tabloları ve yedekleri
• Dosya depolama (yüklemeler, exportlar, faturalar, ekler)
• Loglar ve izleme (istek logları, hata raporları)
• Analitik ve ürün araçları (event'ler, session replay)
• Destek sistemleri (ticket'lar, sohbet kayıtları, e-posta dizileri)

Sonra her erişim yolunu envanterleyin. Sadece kullanıcı hesaplarında durmayın. İnsan tıklaması gerektirmeden kimlik doğrulama yapabilen her şeyi dahil edin: token'lar ve servis hesapları gibi.

Bu erişim öğelerini tek bir yerde toplayın:

• SSO bağlantıları (SAML/OIDC), parola hesapları, yönetici rolleri
• API anahtarları, kişisel erişim token'ları, webhook gizli anahtarları
• OAuth uygulamaları ve refresh token'lar (Google, Microsoft, Slack vb.)
• Entegrasyonlar veya otomasyonlar tarafından kullanılan servis hesapları
• Müşteri için oluşturulmuş paylaşılan posta kutuları veya “entegrasyon kullanıcıları”

Son olarak entegrasyonları ve faturalama temas noktalarını listeleyin: webhook'lar, Slack/Teams bildirimleri, e-posta gönderimleri, ödeme sağlayıcıları ve herhangi bir harici veri senkronizasyonu. Saklama kuralları, denetim izleri veya hukuki tutuklar için bir uyumluluk notu ekleyin, böylece saklamak zorunda olduğunuz verileri silmezsiniz.

Örnek: bir müşteri uygulamanızı destek masası ve analitik aracıyla birlikte kullanıyordu. Envanteriniz, exportların nereden çekildiğini, Zapier benzeri otomasyonları çalıştıran token'ların hangileri olduğunu ve sonraki ay faturalanmayı durdurmak için hangi abonelik öğesinin iptal edilmesi gerektiğini göstermelidir.

Adım 1: Müşteri verisini sürpriz olmadan dışa aktarın

Bir SaaS için müşteri offboarding oyun planının ilk kuralı basittir: müşterinin almayı beklediği şeyi, gerçekten kullanabileceği bir formatta dışa aktarın. Başlamadan önce bir kısa soru sorun: “Bu verileri bir sonraki aşamada hangi sisteme aktaracaksınız?” Bu yanıt genellikle CSV, JSON veya her ikisinin de gerekli olup olmadığını belirler.

Veri tipine uygun formatları seçin. Kullanıcılar, faturalar ve ticket'lar gibi tablolar genellikle CSV ile iyi çalışır. İş akışları, ayarlar veya event loglar gibi iç içe geçmiş veriler JSON olarak daha net olur. Finansal geçmiş için birçok ekip ayrıca müşterinin saklayabileceği PDF makbuzlar veya fatura PDF'leri ekler.

Exportu sadece “görünür” değil, kullanışlı yapın. Daha sonra bağlamı yeniden kurmaya yardımcı olacak ek alanları dahil edin: sabit ID'ler, oluşturulma/güncellenme zaman damgaları, durum alanları ve ilişki anahtarları (örneğin siparişlerde customer_id). Bunlar olmazsa veri, tekrar bağlanamayan satırlardan oluşan bir yığın haline gelir.

Daha büyük hesaplar için tek bir dosyaya veya isteğe sığmayan exportlar planlayın:

• Büyük veri setlerini tarih aralığına veya tabloya göre bölün (chunking)
• Öngörülebilir dosya adlandırma şeması kullanın (örneğin tickets_2025-01.csv)
• Zaman aşımından kaçınmak için exportları arka plan işleri olarak çalıştırın
• Eksik parçaları fark etmek için dosya başına satır sayılarını kaydedin

Her şeyi teslim etmeden önce, içinde nelerin olduğu ve neyin olmadığını söyleyen kısa bir “export manifesti” hazırlayın. İyi bir manifest genellikle şunları listeler:

• Dışa aktarılan veri setleri (tablolar, loglar, ekler)
• Kapsanan zaman aralığı
• Veri seti başına toplam kayıt sayısı
• Herhangi bir kırpma veya sansürleme (örneğin hashlenmiş gizli alanlar)
• Tamamlığın nasıl doğrulanacağı (sayım ve seçme kontrolleri)

Örnek: bir müşteri “tüm destek verilerini” isterse, bunun ekleri, dahili notlar ve otomasyon kurallarını içerip içermediğini netleştirin. SaaS'iniz AppMaster gibi bir platform üzerinde kurulmuşsa, bunun için CSV (inceleme için) ve JSON (yeniden içe aktarma için) çıktısı veren ve manifesti otomatik oluşturan bir export işi sunabilirsiniz.

Adım 2: Exportu teslim edin ve kanıt kaydedin

Export hazır olduğunda, teslimatı küçük bir sürüm gibi ele alın: devri planlayın, son dakika değişikliklerini azaltın ve ne teslim ettiğinizi kanıtlamayı kolaylaştırın. İyi bir müşteri offboarding oyun planı genellikle müşterinin paketlenirken kayıtları düzenlememesi için kısa bir salt-okunur pencere içerir.

Eğer bir dondurma (freeze) gerekiyorsa, zamanını, ne kadar süreceğini ve “salt-okunur”un ne anlama geldiğini (yeni ticket yok, yükleme yok, API yazma yok) kararlaştırın. Dondurma mümkün değilse, kesin zaman damgasını belgeleyin ve manifestte bu zamanın neyi temsil ettiğini belirtin.

Ekler ve kullanıcı tarafından oluşturulan dosyalar konusunda dikkatli olun. Veritabanı exportları genellikle nesnelerde saklı dosyaları (objekt depolama, CDN, e-posta logları, çağrı kayıtları) kaçırır. Bunları ayrı bir klasör veya arşiv olarak teslim edin ve kayıtlarla açık bir eşleme verin (örneğin dosya adı kayıt ID'si içerir) ki müşteri tam resmi yeniden kurabilsin.

Müşterinin politikasına uyan güvenli bir teslim yöntemi seçin. Yaygın seçenekler arasında parola ile şifrelenmiş arşiv ve parolanın kanal dışı paylaşılması, süreli güvenli indirme linki veya müşterinin kontrol ettiği bir hedefin (örneğin storage bucket veya SFTP) sağlanması vardır.

Her şeyi göndermeden önce içsel olarak saklayabileceğiniz küçük bir “kanıt paketi” oluşturun:

• Export zaman damgası ve ortam (prod/sandbox)
• Ana tablo veya nesne türü başına kayıt sayıları
• Ekler için dosya sayıları ve toplam boyut
• Her arşiv için checksum'lar (veya en azından hash)
• Exportun tamamlandığını gösteren sistem logları veya iş ID'leri

Teslimattan sonra açık bir alındı onayı alın. “Alındı ve başarılı şekilde açıldı” gibi basit bir yanıt döngüyü kapatır ve müşteri daha sonra exportun eksik veya bozuk olduğunu iddia ederse anlaşmazlıkları önler.

Adım 3: Erişimi tamamen iptal edin (kullanıcılar, token'lar, entegrasyonlar)

Buradaki hedef basit: müşteri artık oturum açmamalı veya API'lerinizi kullanmamalı, aynı zamanda bağlı araçlar da erişmemeli. Bir SaaS için müşteri offboarding oyun planı genellikle kullanıcıları sadece devre dışı bırakmakla yetinildiğinde başarısız olur; token'lar, servis hesapları veya unutulmuş entegrasyonlar unutulabilir.

Yeni oturumları engelleyerek başlayın. O kiracının ya da çalışma alanının SSO girişini devre dışı bırakın, parola sıfırlamalarını durdurun ve hâlâ hesap oluşturabilecek davet linklerini kaldırın. Birden fazla kimlik doğrulama yöntemi (SSO ve e-posta/şifre gibi) destekliyorsanız, sadece en sık kullanılanı kapatmakla yetinmeyin; tüm giriş yollarını kapatın.

Sonra mevcut erişimi kesin. Aktif oturumlar saatler veya günler boyunca çalışmaya devam ettiği için birçok olay ortaya çıkar. Tüm kullanıcıları zorla oturum kapatın ve refresh token'ları iptal ederek tarayıcı ve mobil oturumların hızla sonlanmasını sağlayın.

Erişim kapatma kontrol listesi

Bunları ilerlemeden önce hızlıca tarayın:

• Giriş yollarını devre dışı bırakın: SSO, parola sıfırlama, magic link'ler ve davetler
• Müşteri hesabındaki tüm kullanıcılar için aktif oturumları ve refresh token'ları iptal edin
• API anahtarlarını, OAuth token'larını ve webhook imza gizli anahtarlarını iptal edin veya döndürün
• Servis hesaplarını ve konektörler için oluşturulmuş “entegrasyon kullanıcılarını” devre dışı bırakın
• Hesaba bağlı planlı işlevleri (zamanlanmış işler, exportlar, bildirimler) duraklatın

Entegrasyonlar özel dikkat gerektirir çünkü genellikle UI'nız dışında dururlar. Örneğin müşteri bir Slack veya e-posta/SMS konektörüyle hâlâ event çekiyor olabilir veya bir ödeme/analitik aracı hâlâ webhook alıyor olabilir. Eskimiş endpointlerin istekleri doğrulayamaması için webhook gizli anahtarlarını döndürün ve bir yöneticinin yeniden etkinleştirebileceği entegrasyon ayarlarını devre dışı bırakın.

Ürününüz AppMaster gibi bir platform üzerinde kurulmuşsa, görsel mantık ve modülleri de aynı şekilde ele alın: sadece insan hesaplarını değil, ödeme, mesajlaşma ve üçüncü taraf modüllerinin kullandığı kimlik bilgilerini ve servis kullanıcılarını kapatın.

Adım 4: Abonelikleri ve faturalamayı düzgün kapatın

Faturalama, offboarding'in gerilimli hale gelebileceği yerdir. Hedef basit: gelecekteki ücretleri kararlaştırılmış zamanda durdurun, zaten borçlu olanı kapatın ve her iki tarafın da uzlaştırabileceği bir kağıt izi bırakın.

İptal etkili tarihini yazılı olarak onaylayarak başlayın. Bazı müşteriler hemen iptal ister; bazıları export ve devri tamamlamak için ödediği dönem sonuna kadar hizmet istiyor. Eğer offboarding için bir “varsayılan”ınız olacaksa, bunun “müşteri daha erken istemedikçe dönemin sonunda iptal et” olması güvenlidir.

Prorasyon, kredi ve iade için tutarlı bir kural kullanın. İstisnaları kim onaylayabilir belirleyin ve kararı o gün ticket'a cevap veren kişiye göre değil, sözleşmeye ve kullanıma göre bağlayın.

"İptal" düğmesine basmadan önce kontrol listesi:

• Planı, ek öğeleri, kullanıcı sayısını ve kesin iptal geçerlilik tarihini onaylayın
• Süreç boyunca müşterinin tekrar ücretlendirilmemesi için yükseltmeleri dondurun
• Politikalarınıza göre açık faturaları tahsil edin veya iptal edin
• Prorasyon, kredi veya iade kararlarını kısa bir notla belgeleyin
• Vergi veya ücretlerin özel işlem gerektirip gerekmediğini doğrulayın

Ödeme yöntemlerini saklıyorsanız, izin verilen ve uygun olduğunda bunları kaldırın. Birçok kurulumda (özellikle Stripe gibi işlemciler kullanıldığında) ödeme yöntemini müşteri kaydından ayırırken işlem geçmişini muhafaza edebilirsiniz. Kaldıramıyorsanız, nedenini kaydedin ve faturalama verilerine erişimi sınırlayın.

Müşterinin kendi kayıtlarıyla eşleştirebileceği son bir fatura özeti gönderin:

• Son fatura(lar) ve ödeme durumu
• Herhangi bir kredi, iade veya prorasyon hesaplaması
• İptal geçerlilik tarihi ve o tarihe kadar hangi erişimin devam edeceği
• Gelecekteki faturalamanın durdurulduğu onayı

Örnek: bir müşteri ay ortasında iptal eder ama geçişi tamamlamak için aya kadar erişim ister. İptali döngünün son gününe planlarsınız, eklenti satın alımlarını engellersiniz ve “yenileme yok” ibaresiyle tek bir özet gönderirsiniz; açık fatura ise ödenmesi gereken veya feragat edilmiş olarak net şekilde işaretlenir.

Adım 5: Verileri silin ve kaldırılanları belgeleyin

Silme, güvenin kazanıldığı veya kaybedildiği noktadır. Hiçbir şeyi tıklamadan önce isteği yazılı olarak onaylayın ve takip edeceğiniz net bir son tarih belirleyin (örneğin, “Silme işlemini Cuma 17:00 UTC'ye kadar tamamlayacağız”). Müşterinin tam hesap silme mi, bir çalışma alanını silme mi yoksa belirli kullanıcıları veya kayıtları kaldırma mı istediğini netleştirin.

Sonra ürününüz için “silme”nin ne anlama geldiğini tanımlayın. Bir SaaS offboarding oyun planında bu tanım tutarlı ve kolay açıklanabilir olmalıdır.

İşte önceden karar vermeniz gerekenler:

• Uygulama verileri: veritabanı satırları, müşteri profilleri, ticket'lar, notlar, özel alanlar
• Dosyalar: sisteminizde saklanan yüklemeler, ekler, exportlar
• Erişim logları ve denetim günlükleri: neyi sakladığınız, neyi sildiğiniz
• Türetilmiş veriler: indeksler, analitik event'ler, arama önbellekleri, ML özellikleri
• Yedekler: verinin hemen mi silineceği yoksa belirli bir zaman çizelgesine göre mi süresi dolacağı

Silme adımlarını sabit bir sırayla çalıştırın ki “yapışık” veri bırakmayın. Örneğin önce dosyaları silin (böylece referans verilemezler), sonra ana kayıtları, sonra türetilmiş verileri ve önbellekleri, ardından kontrolünüz altındaki entegrasyon tarafı kopyalarını silin.

Silme işlemini ödeme belgesi gibi belgeleyin: kısa, net ve kanıtlı. Kimin ne zaman ne yaptığını cevaplayan tek bir offboarding kaydı tutun.

En az şunları içermelidir:

• Uyguladığınız silme kapsamı (hesap, çalışma alanı veya belirli veri kümesi)
• Silmenin başladığı ve bittiği kesin zaman
• Her adımı gerçekleştiren operatör (kişi veya otomatik iş)
• Kısa bir sonuç notu (başarılı, kısmi, tekrarlandı) ve varsa olay ID'leri
• Ne kaldı ve neden (saklama, yasal, güvenlik veya ihtilaf yönetimi)

Eğer saklama gereksinimleri nedeniyle bir şey kalmak zorundaysa, bunu açıkça söyleyin ve belirsiz ifadelerden kaçının. Örnek: “Fatura kayıtları vergi uyumu için 7 yıl saklanacaktır. Bugün tüm uygulama içerikleri ve dosyalar silindi. Yedekler dönecek ve 30 gün içinde yaşlanarak silinecektir.”

Adım 6: Kısa kontrollerle offboardingi doğrulayın

Doğrulama, müşteri offboarding oyun planınızın sonradan destek zincirine dönüşmesini engelleyen güvenlik adımıdır. Hedef basit: hesabın söylediğiniz şekilde kapatıldığını kanıtlayın ve bunu net bir kayıtla saklayın.

Ayrıca “hala kullanılabiliyor mu?” sorusuna kısa kontrollerle başlayın. Bunu ayrı bir test kullanıcısı veya özel tarayıcı penceresinden yapın ki eski oturumlara aldanmayın.

• Bilinen bir kullanıcı ile giriş yapmayı deneyin: başarısız olmalı veya hesap kapalı mesajı göstermeli.
• Eski bir token ile birkaç ana API endpoint'ini çağırın: yetkilendirme hatası bekleyin.
• Bir webhook event'i tetikleyin (veya simule edin): hiçbir şey teslim edilmemeli.
• Entegrasyonlar sayfasını açın: bağlı uygulamalar bağlantısız veya devre dışı görünmeli.
• Yönetici erişimini kontrol edin: eski yöneticilerin geri dönme yolu olmamalı.

Sonra para ve yenileme riskinin gerçekten gittiğini doğrulayın. Aktif bir plan olmadığını, gelecek bir yenileme tarihinin olmadığını ve otomatik tahsilat yapabilecek ödenmemiş fatura olmadığını kontrol edin. Birden fazla fatura sistemi destekliyorsanız (örneğin uygulama içi + Stripe), her iki yeri de kontrol edin. Bir kontrol panelindeki “iptal edildi” rozeti, başka bir sistem halen aktif gösteriyorsa yeterli değildir.

Son olarak veri sonucu konusunda verdiğiniz sözle karşılaştırma yapın. Tam silme talep edildiyse, ilgili müşteri kayıt sayılarınızın sıfır olması gerekir. Hukuki veya denetim sebepleriyle sınırlı kayıtlar tutuluyorsa, yalnızca onların kaldığını doğrulayın. Önceden teslim ettiğiniz export toplamlarını silmeden önceki sayılarla karşılaştırın ki herhangi bir farkı açıklayabilesiniz.

Kanıtı taze iken yakalayın. Basit bir iç not genellikle yeterlidir:

• Plan durumu ve erişim devre dışı ekranlarının ekran görüntüleri
• Silme zaman damgası ve kim onayladığını gösteren log girişi
• Silinenlerle saklananların kısa özeti
• Teslim ettiğiniz export paketinin konumu veya ID'si

Örnek: bir müşteri “API anahtarımız hâlâ veri erişebiliyor mu?” diye sorarsa, başarısız test çağrısının tarihini ve anahtarın iptal edildiğini gösteren kaydı tek bir mesajla yanıtlayabilirsiniz.

Yaygın hatalar ve nasıl kaçınılır

Çoğu offboarding sorunu iki şeyden kaynaklanır: belirsiz tanımlar (tam olarak neyin “silindiği” veya “offboard” sayıldığı) veya erişim ve verinin saklı köşeleri.

Sık yapılan bir hata arka kapıyı açık bırakmaktır. Ekipler ana yönetici kullanıcılarını siler ama eski API anahtarlarını, kişisel erişim token'larını, paylaşılan posta kutularını veya hâlâ izinleri olan bir entegrasyon hesabını unuturlar. Bunu düzeltmek için erişimi tek bir anahtar gibi görmek yerine envanter olarak ele alın. Şüphe varsa, sadece insan hesaplarını değil, gizli anahtarları döndürün ve entegrasyon kullanıcılarını devre dışı bırakın.

Diğer bir sorun, “çoğu” verileni dışa aktarıp daha sonra ekleri, denetim geçmişini, yorumları veya özel alanları dışarıda bıraktığınızı fark etmektir. Exportlar genellikle kolay sorgulanabilenleri varsayılan olarak alır, müşterinin beklediğini değil. Sürprizleri önlemek için export içeriği üzerinde önceden anlaşın ve küçük bir test exportu yapın.

Faturalama da kaosa yol açabilir. Çok erken iptal ederseniz, hesap anında düşürülebilir ve exportları engelleyebilir veya destek erişimi işin bitmeden kaybolabilir. Çok geç iptal ederseniz istenmeyen bir yenileme riskine girersiniz. Güvenli yaklaşım export tamamlanmasını teyit etmek, sonra net bir geçerlilik tarihiyle iptali planlamak ve son faturayı kontrol etmektir.

Son olarak, kanıtlayamayacağınız silme iddiaları vermeyin. “Her şeyi sildik” farklı şeyler anlamına gelebilir; yedeklemeler, loglar ve yasal saklamalar hesaba katılmalıdır. Ne silindiğini, neyin anonimleştirildiğini, neyin saklandığını ve nedenini yazın ve kanıtları (zaman damgaları, iş ID'leri, ekran görüntüleri) saklayın.

Basit bir SaaS offboarding oyun planı şu hızlı korumaları içermelidir:

• Her erişim yolunu listeleyin: kullanıcılar, token'lar, SSO, servis hesapları, entegrasyonlar.
• Export kapsamını tanımlayın: veri tabloları, dosyalar, geçmiş ve tarih aralıkları.
• Faturalamaya dokunmadan önce yenileme tarihini yazılı olarak kilitleyin.
• Yedekler ve saklama kuralları dahil olmak üzere bir silme tanımı kullanın.
• Kanıtı tek bir yerde saklayın ki herkes sonradan soruları cevaplayabilsin.

Örnek senaryo: 30 günlük sakin bir offboarding

Orta ölçekli bir müşteri 1 Mayıs'ta e-posta atar: “Ay sonunda ayrılıyoruz. Tam bir export ve verilerimizin silindiğine dair onay istiyoruz.” Aynı gün sahipler atanır ki hiçbir şey sürüklenip unutulmasın.

Roller basit tutulur: müşteri yöneticisi “ne dahil edileceğini” yanıtlar, destek lideri kontrol listesini ve iletişimi yürütür, finans fatura ve iptal koşullarını ele alır, mühendislik/on-call erişim kenar durumları ve silme işleri için hazır bekler.

Panikten uzak bir 30 günlük zaman çizelgesi şöyledir:

• Gün 1: Talebi kabul edin, kapsamı doğrulayın (çalışma alanları, tarih aralığı, ekler, denetim logları) ve hedef tarihleri belirleyin.
• Gün 5: Exportu ve bir export manifestini hazırlayın (nelerin dahil olduğu, formatlar, kayıt sayıları).
• Gün 7: Exportu teslim edin, alındı alın ve iç kanıtları saklayın.
• Gün 10: Erişimi iptal edin (kullanıcılar, SSO, API anahtarları, webhook'lar, entegrasyonlar) ve bir iptal logu yakalayın.
• Gün 30: Faturalamayı kapatın, silmeyi çalıştırın ve silme onay notunu gönderin.

Export teslim edildikten sonra kanıtlayabileceklerinizi yazın. Basit bir kağıt izi “aldık” veya “sildiniz” tartışmalarını engeller.

Tüm belgeleri tek bir dahili ticket'ta toplayın:

• Export manifesti (dosyalar, checksum varsa, satır sayıları)
• Teslimat kaydı (zaman damgası, yöntem, alıcı)
• İptal logu (devre dışı bırakılan hesaplar, döndürülen token'lar, kaldırılan entegrasyonlar)
• Fatura kapanış notu (son fatura, prorasyon kararı)
• Silme onay notu (ne silindi, ne zaman ve ne saklandı ve neden)

Müşteri Gün 28'de “bir export daha” veya uzatma isterse iki seçenek sunun: Gün 7'den bu yana değişiklikleri içeren hızlı bir delta exportu ile yeni bir son tarih, veya kısa bir uzatma ve yazılı faturalama şartları. Ürününüz bir iş akışı aracı ya da AppMaster gibi bir platformda çalışıyorsa, onaylar ve zaman damgalarını formalize etmek için kısa bir Business Process oluşturmak iyi bir fikirdir; böylece sonraki offboarding yine aynı istikrarla yürür.

Sonraki adımlar: tekrarlanabilir hale getirin (ve işe yararsa otomatikleştirin)

Bir SaaS için müşteri offboarding oyun planı, yoğun bir haftada bile aynı şekilde çalışıyorsa işe yarar. Yaptıklarınızı tekrar kullanılabilir bir kontrol listesine dönüştürün ve her adıma bir isim bağlayın. “Birisi halleder” demek exportların kaçırılmasına ve erişimin açık kalmasına yol açar.

Basit başlayın: tek bir kontrol listesi, tek bir yer, net sahipler ve her adım için bir bitiş tanımı. Bu tanım beklenen kanıtı da içermeli (örneğin: export oluşturuldu, erişim iptal edildi, abonelik iptal edildi, silme tamamlandı, doğrulama kontrolleri geçti).

Tekrar kullanılabilir bir kontrol listesi yapısı örneği:

• Her faz için bir sahip (veri, erişim, faturalama, silme, doğrulama)
• Her faz için teslim tarihi ve nihai offboarding son tarihi
• Eklenecek gereken kanıtlar (ekran görüntüleri, loglar, export ID'leri, ticket notları)
• Her kilometre taşı için standart müşteri mesaj şablonu
• Kısa bir “istisnalar” notu (hukuki bekletme, ödenmemiş fatura veya kısmi silme durumunda ne yapılacağı)

Sonra sıkıcı kısımları otomatikleştirin. Otomasyon, gösterişli iş akışlarından çok unutulabilecek manuel tıklamaları ortadan kaldırmakla ilgilidir. Örneğin exportları zamanlayın, API anahtarlarını toplu iptal edin, SSO oturumlarını devre dışı bırakın ve zaman damgası ile nedeni kaydeden bir yönlendirme akışı kullanın.

Bir SaaS inşa ediyorsanız, offboarding'i tutarlı kılacak dahili yönetim araçları da kurabilirsiniz. AppMaster gibi bir no-code platformu kullanarak bir offboarding konsolu (export üreteci, token iptal aracı, silme çalıştırıcı ve doğrulama panosu) oluşturabilirsiniz; böylece destek ve operasyon aynı adımları her defasında uygular.

Her offboarding sonrası bir iyileştirme seçin. Yaygın kazanımlar: logları sıkılaştırmak (kimin ne zaman ne yaptığını kaydetmek), entegrasyon sahipliğini netleştirmek ve son “neredeyse kaçırılan” problemi yakalayacak ekstra bir doğrulama kontrolü eklemek.