Ürün kapanış zaman çizelgelerini yönetmek için bir web uygulaması planlayın ve oluşturun: kilometre taşları, onaylar, müşteri bildirimleri, panolar, izinler ve denetim geçmişi.

Ekran tasarlamaya veya bir teknoloji yığını seçmeye başlamadan önce şirketinizde “sunset”in ne anlama geldiğini netleştirin. Bir ürünün kapanış zaman çizelgesi birkaç farklı son noktayı ifade edebilir ve uygulamanız bunları açıkça desteklemeli ki ekipler daha sonra bir tarihin neyi temsil ettiği konusunda tartışmasın.
Çoğu kuruluşun en az üç kilometre taşına ihtiyacı vardır:
Bu kavramları ürün ömrünün sonu (EOL) yönetimi aracınızda birinci sınıf nesneler olarak ele alın. Bu, belirsiz bir “emeklilik tarihi” yerine net sürüm ve destek zaman çizelgeleri sağlar.
Sunset süreci tek bir ekibin işi değildir. Birincil kullanıcılarınızı ve onların hangi kararları vermesi veya onaylaması gerektiğini listeleyin:
Bu liste daha sonra iş akışını ve izinleri yönlendirecek; şimdilik uygulamanın kimin işini kolaylaştırması gerektiğini netleştirir.
Uygulama içinde kolay cevaplanması gereken kararları yazın:
Bu sorulara hızlı cevap veremeyen bir araç, ekipleri tekrar hesap tablolarına döndürecektir.
Gecikmiş kilometre taşlarının azalması, beklenmedik müşteri yükselmelerinin azalması ve her adım için net sahiplik gibi ölçülebilir sonuçları tanımlayın.
Kapsam kısıtlarını erkenden yakalayın (birden fazla ürün, bölgeler, müşteri kademeleri ve sözleşmeler). Bu kısıtlar veri modelinizi ve ürün değişiklikleri için denetim izi gereksiniminizi baştan şekillendirmeli.
Bir sunset zaman çizelgesi uygulaması ancak herkes aynı terimleri aynı şekilde kullanırsa işe yarar. Ürün, Destek, Satış ve Müşteri Başarı ekipleri “deprecated” veya “EOL” dediğinde farklı şeyler kastedebilir. Uygulama içinde (ya da ona bağlı) paylaşılan bir sözlük oluşturun ve bu tanımları kilometre taşları oluşturulurken görünür kılın.
Durumları az ama açık ve karşılıklı olarak anlaşılan şekilde tutun. Pratik bir varsayılan set:
İpucu: her durumda nelerin değiştiğini (satış izni, yenileme izni, destek SLA'sı, güvenlik yamaları) tanımlayın ki durum sadece bir etiket olmasın.
Kilometre taşlarını serbest tarih yerine tiplenmiş olaylar olarak ele alın. Yaygın kilometre taşı türleri arasında duyuru, son yeni satın alma, son yenileme ve destek sonu bulunur. Her türün açık kuralları olmalı (örneğin, “son yenileme” sadece abonelik planları için geçerlidir).
Etkilenenleri paragraf yerine yapılandırılmış tutun. Etkilenen hesaplar, segmentler, planlar, entegrasyonlar ve bölgeler gibi alanları yakalayın. Bu, ekiplerin “kimin bilmesi gerektiğini” filtrelemesini sağlar ve belirli bir entegrasyon ortağı gibi uç vakaları kaçırmayı önler.
Her kilometre taşı türü için küçük bir kontrol listesi zorunlu kılın; örneğin bir SSS, geçiş kılavuzu ve sürüm notları. Bu belgeler kilometre taşına eklendiğinde zaman çizelgeniz sadece bilgilendirici değil, uygulanabilir olur.
Her durum ve kilometre taşı türü için örnekler ve müşteriler açısından ne anlama geldiğini içeren bir sözlük girişi ekleyin. Oluşturma formlarından bir tıklama ile erişilebilir olsun.
Bir sunset uygulaması veri modeline bağlı olarak başarılı olur veya başarısız olur. Model çok inceyse zaman çizelgeleri tekrar tablolar haline gelir; çok karmaşıksa kimse onu sürdürmez. Gerçek dünya istisnalarını ifade edebilecek küçük bir varlık seti hedefleyin.
Bu yapı taşlarıyla başlayın:
Önemli bir tasarım seçimi: Ürün başına birden fazla Sunset Plan'a izin verin. Bu, “AB bölgesi ABD'den daha geç emekliye ayrılıyor”, “Ücretsiz plan önce kapanıyor” veya “Stratejik hesaplara uzatılmış destek” gibi durumları eklentisiz yönetir.
Sunsetler genellikle izole değildir. Ekiplerin etkiyi akıl yürütmesine yardımcı olacak yapılandırılmış alanlar ekleyin:
Destekleyici materyaller için kaynak belge yollarını göreli yollar olarak saklayın (örneğin, /blog/migration-checklist, /docs/support-policy) böylece ortamlar arasında stabil kalır.
“İmkansız” planları önlemek için doğrulamalar kullanın:
Kurallar başarısız olursa net, teknik olmayan mesajlar gösterin (“Kapanış, Destek Sonu'ndan sonra olmalı”) ve düzeltmesi gereken kilometre taşına işaret edin.
Bir sunset planı en sık kimin karar verdiği ve değişikliklerin fikirden müşteri taahhütlerine nasıl geçtiği belirsiz olduğunda başarısız olur. Uygulamanız süreci açık, hafif ve denetlenebilir hale getirmeli.
Çoğu ekip için uygun ve anlaşılması kolay bir varsayılan iş akışı ile başlayın:
Taslak → İnceleme → Onay → Yayınla → Güncelle → Emekliye Ayır
Her kilometre taşı için (duyuru, son sipariş tarihi, satış sonu, destek sonu, kapanış) atayın:
Bu, hesap verebilirliği net tutarken takım çalışmasını da destekler.
Değişiklikleri birincil nesne olarak ele alın. Her değişiklik talebi şunları içermeli:
Onaylandığında, uygulama önceki değerleri geçmişte saklarken zaman çizelgesini otomatik güncellemelidir.
Kilometre taşları için basit, tutarlı durum bayrakları ekleyin:
VIP müşteriler, sözleşme istisnaları ve bölgeye özel gecikmeler gibi durumlar için bir “İstisnalar” katmanı oluşturun. İstisnalar zaman sınırlı, sebebe bağlı ve açık onay gerektiren şekilde bağlanmalı ki özel muamele gizli şekilde yeni varsayılan olmasın.
Uygulamanız tek, sakin bir çalışma alanı gibi hissettirmeli: bir plan bulun, sıradaki işi anlayın ve müdahale edin—sekmeler arasında gezinmek zorunda kalmadan.
Giriş yaptıktan sonra çoğu kişi buraya gelecektir; her ürün sunset planının bir liste görünümüyle başlayın.
Ekiplerin nasıl çalıştığına uygun birkaç yüksek sinyal filtre ekleyin:
Satırları okunaklı tutun: ürün adı, mevcut aşama, sonraki kilometre taşı tarihi, sahip ve “risk altında” göstergesi. Tüm satır tıklanabilir olsun ve planı açsın.
Kilometre taşlarını ve bağımlılıkları görselleştiren bir zaman çizelgesi görünümü ekleyin (örneğin, “Müşteri bildirimi ‘Satış durdurma’dan önce gönderilmeli”). Proje yönetimi jargonundan kaçının.
Açık etiketler ve küçük bir gösterge kullanın. Kullanıcıların ay/çeyrek zoom seviyeleri arasında geçiş yapmasına izin verin ve plan detaylarına hızlı dönüş sağlayın.
Detay sayfası üç soruyu hızlıca cevaplamalı:
Anahtar tarihler kaybolmasın diye yapışkan bir özet başlık düşünün.
Liste sayfasında ve her plan içinde, role göre uyarlanmış bir “Sonraki eylemler” paneli gösterin: inceleme bekleyenler, onay bekleyenler ve gecikmiş öğeler.
Tutarlı fiiller kullanın: Planla, İncele, Onayla, Bildir, Tamamla. Etiketleri kısa tutun, başlıklarda kısaltmalardan kaçının ve “EOL” gibi terimler için sade araç ipuçları sağlayın. Kalıcı bir kırıntı izi ekleyin (örneğin Plans → Product X) ve yardım için öngörülebilir bir yer (örneğin /help) sunun.
Bir sunset planının başarısı iletişime bağlıdır. Uygulama, aynı kilometre taşlarını izleyen iç ekiple ilişkilendirilmiş, net ve tutarlı mesajlar göndermeyi kolaylaştırmalı.
Küçük bir bildirim şablonu kütüphanesiyle başlayın:
Her şablon {product_name}, {end_of_support_date}, {migration_guide_link}, {support_contact} gibi yer tutucuları desteklemeli. Birisi belirli bir sunset için şablonu düzenlediğinde yeni bir içerik sürümü olarak kaydedin ki: “12 Mart'ta müşterilere tam olarak ne söyledik?” sorusuna cevap verilebilsin.
Bir mesaj taslağını birden çok çıktı için işlenebilir hale getirin:
Kanal spesifik alanları minimal tutun (e-posta için konu satırı, uygulama içi için CTA butonu) ve aynı temel metni paylaşın.
Sunsetler nadiren herkesi kapsar. Ekiplerin segment, plan ve bölgeye göre hedeflemesine izin verin ve planlamadan önce tahmini alıcı sayısı önizlemesini gösterin. Bu, yanlış kişileri aşırı bilgilendirmeyi veya kritik bir kohortu kaçırmayı azaltır ve destek ekiplerinin personel planlamasına yardımcı olur.
Zamanlamayı takvime göre değil, kilometre taşlarına göre yapın. Örneğin: destek sonundan 90/60/30 gün önce hatırlatmaları ve yaşam döngüsü sonundan 7 gün önce son bildirimi otomatik sıraya alın. Kilometre taşı tarihi değişirse, sahipleri bağımlı zamanlamaları güncellemesi için uyarın.
Ne zaman, hangi kanalla, hangi kitleye gönderildiğinin aranabilir geçmişini saklayın. Onayları, içerik sürümlerini ve teslim durumunu dahil edin ki iletişimler iç incelemelerde ve müşteri yükselmelerinde savunulabilir olsun.
Sunset zaman çizelgesi uygulaması kısa sürede gerçek kaynak haline gelir; bu yüzden izin hataları müşteri karışıklığına dönüşür. Modelinizi küçük, öngörülebilir ve açıklaması kolay tutun—sonra bunu ekranlar, dışa aktarmalar ve bildirimler arasında tutarlı şekilde uygulayın.
Rolleri iş unvanından ziyade değiştirebilecekleri şeylere göre tanımlayın:
Bu, ürün emeklileştirme sürecinin akmasını sağlar ve her güncellemeyi bir yönetici işine dönüştürmez.
Çoğu ekip için iki kapsam gerekir:
“Yayınla”yı ayrı bir yetenek yapın: Editörler hazırlar; Onaylayanlar sonlandırır.
Yayımlanmış mevcut sunset kilometre takibinin varsayılan salt okunur görünümünü sağlayın. Sayfa “tarih nedir, kim etkilendi, ikame nedir” sorularını yanıtladığında daha az anlık Slack sorusu gelir. Paylaşılabilir dahili bir bağlantı düşünün (örneğin /sunsets).
Özellikle şunlar için ürün değişiklikleriyle ilgili bir denetim izi tutup gösterin:
Kim yaptığını, ne zaman yaptığını ve ne değiştiğini (önce/sonra) yakalayın. Bu, hesap verebilirlik ve müşteri bildirim planlaması için kritik.
SSO ile başlayamıyorsanız güçlü parola doğrulaması (hash'lenmiş parolalar, mümkünse MFA, hız sınırlama, kilitlemeler) kullanın. Kullanıcı modelinizi SSO eklemeyi daha sonra izinleri yeniden kurmadan destekleyecek şekilde tasarlayın (örneğin SSO gruplarını rollere eşleme).
Bir sunset planı müşteri verisine, destek sinyallerine ve dışa yönelik mesajlaşmaya dokunur—bu yüzden entegrasyonlar uygulamanızın bir kaynak olarak benimsenmesini sağlar, tekrar bir tablo olmamasını.
CRM'inizle (Salesforce, HubSpot vb.) başlayarak etkilenen hesapları, fırsatları ve hesap sahiplerini her sunset planına iliştirmeye izin verin.
Temel tasarım seçimi: kayıtları değil, ID'leri senkronize edin. CRM nesne ID'lerini (Account ID, Owner ID) saklayın ve görüntü alanlarını (isim, segment, sahip e-posta) isteğe bağlı veya zamanlı senkron ile alın. Bu, karışık “hesap” tablolarını ve bir müşterinin yeniden adlandırılması ya da sahip değişikliği durumunda sapmayı önler.
Pratik ipucu: manuel geçersiz kılmalara izin verin (örneğin “ayrıca etkilenen: bağlı kuruluş hesabı”) ama kanonik referans CRM ID'si olsun.
Zendesk, Intercom, Jira Service Management gibi sistemlerle bağlanın ki:
Tüm alanlara gerek yok—genelde ticket ID, durum, öncelik ve ticket linki yeterlidir.
Müşteri bildirimleri gönderecekseniz e-posta sağlayıcınızla (SendGrid, SES, Mailgun) entegre olun. Gizli anahtarları ön uçta tutmayın:
Bu sayede iletişimin kanıtı olur, ama içerikleri her yerde saklamazsınız.
İç hatırlatmalar basit olduğunda en etkilidir: “Kilometre taşı 7 gün içinde” ve plana bağlantı. Ekiplerin kanallara ve sıklığa abone olmasına izin verin.
Her entegrasyonu bir eklenti gibi düşünün; açıkça aç/kapa anahtarları olsun. Kurulum için gereken izinler, webhook URL'leri ve test kontrol listesi gibi adım adım kurulum dokümanlarını kısa bir yönetici kılavuzunda (örneğin /docs/integrations) sağlayın.
Sunset çalışması e-posta zincirlerinde veya tablolar halinde dağınık olduğunda karmaşıklaşır. İyi bir raporlama katmanı durumu görünür kılar, denetim geçmişi ise değişiklikleri savunulabilir hale getirir.
Gösterişten uzak, eylem odaklı panolarla başlayın. Faydalı paneller: yaklaşan kilometre taşları (son 30/60/90 gün), gecikmiş öğeler ve planların yaşam döngüsü aşamalarına göre dağılımı (Duyuruldu, Deprecated, EOL, Arşivlenmiş). Ürün, müşteri segmenti, bölge ve sahip için hızlı filtreler ekleyin ki ekipler özel rapor istemeden kendilerine yetebilsin.
Küçük bir “istisnalar” görünümü genelde en değerli olandır: eksik zorunlu kilometre taşları, ikame ürünü eşleştirilmemiş ürünler veya destek politikasıyla çelişen zaman çizelgeleri.
Herkes uygulamaya giriş yapmayacak. CSV (analiz için) ve PDF (paylaşmak için) biçiminde filtreleri ve tarih aralıklarını kaydeden dışa aktarımlar sunun. Tipik ihtiyaçlar: çeyreklik EOL takvimi, belirli bir üründen etkilenen müşteri listesi veya bir iş birimine sınırlandırılmış görünüm.
PDF üretiyorsanız, onları net şekilde etiketleyin (örneğin “Oluşturulma tarihi…”) ve bunları koordinasyon için anlık görüntüler olarak değerlendirin—sözleşmesel taahhütler olarak değil.
Her önemli alan denetlenebilir olmalı: kilometre taşı tarihleri, yaşam döngüsü durumu, ikame ürün, müşteri bildirim durumu ve sahiplik. Saklayın:
Bu, yükselmeler sırasında “ne oldu” sorusuna açıklama sunar ve gereksiz tartışmaları azaltır.
“EOL Duyuruldu”ya geçmek veya müşteri bildirimleri göndermek gibi yüksek etkili adımlar için onayları onaylayan kişinin adı, zaman damgası ve notlarıyla kaydedin. Basit tutun: onaylar sürecinizi desteklemeli, aracı hukuki dile çevirmemeli. Araç kararları ve ilerlemeyi takip etsin; taahhütleri politikalarınız tanımlar.
Sunset zaman çizelgesi uygulaması egzotik teknolojiye ihtiyaç duymaz. Netlik gerekir: öngörülebilir veri, güvenli erişim ve değişiklikleri kolayca gönderebilme.
Zaten ekibinizin bildiği bir web framework, bir veritabanı ve bir kimlik doğrulama yöntemi seçin.
Yaygın, düşük sürtünmeli kombinasyon:
Sıkıcı varsayılanları seçin. İç araçlar için sunucu tarafı render edilen sayfalar çoğu zaman yeterlidir; kullanılabilirliği artıran küçük JavaScript eklemeleri yapılabilir.
Hızlı prototip için Koder.ai gibi bir vibe-coding platformu bu kategori içindeki dahili web uygulamaları için pratik bir seçenek olabilir: iş akışını (planlar, kilometre taşları, onaylar, bildirimler) tarif edersiniz ve çalışır bir React UI ile Go + PostgreSQL arka ucu üretmesine yardımcı olur. Kaynak kodu dışa aktarma, dağıtım/barındırma ve anlık görüntülerle geri alma gibi özellikler EOL yönetimi gereksinimleriyle iyi eşleşir.
Yönetilen bir platform mu yoksa kendi barındırmanızı mı istediğinize erken karar verin.
Her durumda temiz bir dağıtım akışı kurun: main → staging → production, otomatik migrasyonlarla ve tek tık geri alma planıyla.
Sadece web UI yayınlasanız bile küçük bir dahili API sınırı tanımlayın:
/api/v1/sunsets)Bu, mobil istemci, sistem entegrasyonları veya dahili otomasyon eklemeyi kolaylaştırır.
Zaman çizelgesi verisini iş açısından kritik olarak ele alın:
dev, staging ve production ortamlarında nelerin izinli olduğunu belgeleyin: kim deploy edebilir, production verisini kim görebilir ve sırlar nasıl saklanır/döndürülür. Kısa bir /runbook sayfası kazayı önler.
Gerçekçi test yapmadan sunset zaman çizelgesi uygulaması yayınlamak risklidir: kaçırılan tarihler destek krizlerine, erken gönderilmiş e-postalar müşteri karışıklığına yol açar. Test ve yayılımı ürün emeklileştirme sürecinin parçası olarak ele alın.
Kaydetme aşamasında imkansız planları engelleyen koruyucular oluşturun:
Bu doğrulamalar işi yeniden yapmayı azaltır ve aracı sürüm/destek zaman çizelgeleri için güvenilir kılar.
Gerçekçi seed verisi ve örnek sunset şablonları oluşturun:
Kuruluşunuzun arka plan bağlamına ihtiyaç varsa dahili rehberlere bağlayın (örneğin /blog/product-lifecycle-basics).
Müşteri bildirimleri için “zarar verme” modu:
sunset-testing@company).Önce bir ürün hattı ile pilot çalıştırın. Bir zaman çizelgesi oluşturmanın, onayların alınmasının ve yayınlamanın ne kadar sürdüğünü takip edin. Geri bildirimi etiketler, varsayılanlar ve kilometre taşı kuralları için kullanın.
Benimsemeyi kolaylaştırmak için başlangıç: şablon kütüphanesi, kısa eğitim ve “sonraki adım” bağlantısı sağlayın (örneğin, gerekiyorsa /pricing üzerinde göç teklifleri).
Bir sunset zaman çizelgesi uygulaması ancak işe yaradığını kanıtlayıp kullanımı kolay tutarsanız faydalı kalır. Ölçmeyi EOL yönetiminin bir parçası olarak görün—böylece ürün emeklileştirme süreci zamanla daha öngörülebilir olur.
Kaçırılan tarihler, son dakika değişiklikleri ve tutarsız müşteri bildirim planlaması gibi gerçek acıyı yansıtan küçük bir metrik setiyle başlayın.
Mümkünse bunları sonuçlarla ilişkilendirin: kapanışa yakın destek ticket hacmi, geçiş tamamlama oranı ve ikame benimseme—geçiş ve ikame planlaması için ana göstergeler.
Her rolden (PM, Destek, Satış/CS, Hukuk, Mühendislik) kısa geri bildirim toplayın: eksik olan ne, ne kafa karıştırıyor ve hangi işler manuel yapılıyor. Önemli kilometre taşlarından sonra uygulama içinde kısa anketler toplayın ve sonuçları ürün değişiklikleri denetim iziyle birlikte inceleyin; kafa karışıklığı ile geç düzenlemeler korele mi görselleştirin.
Tekrarlayan eylemleri şablon haline getirin: standart sürüm ve destek zaman çizelgeleri, yeniden kullanılabilir e-posta metinleri, ürün türüne göre varsayılan kilometre taşı setleri ve onay için önceden doldurulmuş görevler. Şablonları iyileştirmek genellikle yeni özellik eklemekten daha fazla hatayı azaltır.
Temel işler oturduktan sonra ürünler arası bağımlılıklar, çok bölge kuralları ve product lifecycle yönetimi araçlarıyla API entegrasyonları düşünün. Bu sıralama benimsemeyi yavaşlatmadan karmaşıklığı yönetir.
Aktif ve planlanmış sunsetler için çeyreklik bir inceleme belirleyin: tarihleri onaylayın, iletişimleri doğrulayın ve sahipliği denetleyin. Kısa bir dahili özet yayınlayın (örneğin /blog/sunsets-playbook) ekiplerin hizalanmasını sürdürmek için.