İhbarlar ve onaylar için sözleşme yenileme takipçisi spesifikasyonu

Yenileme takipçisinin çözmesi gerekenler

Bir sözleşme yenileme takipçisi, aynı sorunlar tekrarlandığında var olur: yenileme tarihleri kaçırılıyor, sahibin kim olduğu belirsizleşiyor ve önemli ayrıntılar e-posta dizilerinde, elektronik tablolarda ve paylaşılan sürücülerde dağınık kalıyor. Birisi nihayet yenilemeyi fark ettiğinde genellikle pazarlık yapmak, iptal etmek veya bütçelemek için çok geç oluyor.

Takipçi saniyeler içinde temel soruları yanıtlamalıdır:

• Ne yenileniyor (tedarikçi/müşteri, sözleşme, hizmet)
• Ne zaman yenileniyor (ihbar tarihi, bitiş tarihi, otomatik yenileme tarihi)
• Kimin işlem yapması gerekiyor (iş sahibi, hukuk, finans, satınalma)
• Sonraki adım ne (inceleme, onay, imza, ödeme)
• Ne değişti (notlar, kararlar ve kim onayladı)

Amaç sürprizsiz ve son dakika çabası olmadan tutarlı yenilemelerdir. Bu, güvenilir tarihler, net bir hesap verilebilir sahip ve gerçeği yansıtan bir durum gerektirir. Bir sözleşme “Under review” (incelemede) olarak işaretlendiyse, insanlar ne engel olduğunu ve bir sonraki eylemin kimin sorumluluğunda olduğunu görebilmelidir.

Kapsamı pratik tutun: yeterince erken tetiklenen hatırlatmalar, doğru kişilere ulaşan onaylar, paydaşların planlama yapabilmesi için görünürlük ve temiz bir geçmiş gösteren denetim notları. Doküman depolama ekler kadar basit olabilir ya da imzalı kopyanın nerede olduğunu gösteren bir referans; anahtar terimler ve son tarihler her zaman kolayca bulunabilir olmalıdır.

Paydaşlar ve sorumluluklar

Bir yenileme takipçisi ancak sahiplik açık olduğunda işe yarar. Herkes “sorumlu”ysa, kimse sorumlu değildir.

Çoğu ekip birkaç role indirger:

• Contract owner: yenilemeyi yürütür, ihtiyaçları doğrular, şartları pazarlık eder ve tarihleri doğru tutar.
• Requester: hizmeti kullanan kişi veya ekip; yenileme, küçültme veya iptal konusunda karar verir.
• Finance: bütçeyi, ödeme şartlarını, tedarikçi kurulumu ve maliyet değişikliklerini kontrol eder.
• Legal: şartları inceler, redline yapar ve risk maddelerini gözden geçirir; hangi şablon veya madde setinin uygulanacağını teyit eder.
• Department head: harcama veya kapsam bir eşik aşıyorsa nihai onay veren iş yöneticisi.

Onaylayıcıları sadece bilgilendirilenlerden ayırın. Onaylayıcılar sonucu değiştirebilir (onayla, reddet, değişiklik iste), bilgilendirilen paydaşlar ise akışı engellemez; sadece güncellemeler alırlar.

Sahipliği iki alanla temsil edin: primary owner ve backup owner. Yedek kişi tatiller, iş değişiklikleri ve acil yenilemeler sırasında önemlidir. Basit bir kural iyi çalışır: birincil sahip belirli süre içinde işlem yapmazsa, yedeğe bildirim gönderin ve devralmasına izin verin.

Tedarikçi tarafını göz ardı etmeyin. Farklı konuları farklı kişiler ele aldığı için tedarikçi kişilerini tek bir e-posta yerine role göre saklayın. Çoğu ekip için en azından bir satış teması (ticari şartlar), bir fatura teması (faturalar ve ödemeler) ve destek teması (hizmet sorunları ve yükseltmeler) gerekir.

Örnek: Pazarlama ekibi bir analitik aracın yenilenmesini talep eder. Sözleşme sahibi kullanım ve önerilen katmanı onaylar, Finance harcamayı onaylar, Legal şartları onaylar ve departman başkanı yalnızca yıllık toplam eşiklerin üzerindeyse onay verir. Diğer herkes bilgilendirilir, böylece yenilemeler tıkanmaz.

Varlık modeli: gerçekten hangi tablolar lazım

Bir yenileme takipçisi, uzun ömürlü sözleşme kaydını her yenileme döngüsünden ayırdığınızda en iyi çalışır. Bu, geçmişi temiz tutar ve hatırlatmaları öngörülebilir kılar.

Temel tablolar

Küçük bir tablo setiyle başlayın ve alanları pratik tutun:

• Vendors: yasal ad, kayıt bilgileri, adres, risk seviyesi, aktif bayrağı.
• Contracts: vendor_id, hizmet adı, başlangıç tarihi, bitiş tarihi, yenileme şartları (otomatik yenileme, ihbar süresi), sözleşme değeri, para birimi, sahip.
• Contacts: iç ve tedarikçi kişileri, tür (vendor/internal), rol (hukuk, finans, hizmet sahibi), tercih edilen kanal (email/SMS/Telegram), is_primary.
• Documents: dosya meta verisi artı tür (orijinal, ek, yenileme teklifi, not) ve kısa açıklama.
• RenewalCases: contract_id, döngü başlangıç/bitiş, hedef karar tarihi, mevcut aşama/durum, neden (yenile, yeniden pazarlık, feshet).

Pratikte, Contracts yavaş değişir. RenewalCases bu defa neler olduğunu yakalar: kim onayladı, hangi teklif geldi ve karar ne zaman verildi.

Dağınık veriyi önleyen ilişkiler

“Kimi bildirmeliyiz?” ve “geçen sefer ne karar verdik?” sorularını şansa bırakmayacak şekilde ilişkileri modelleyin:

• Vendors 1-to-many Contracts, Contracts 1-to-many RenewalCases
• Contracts many-to-many Contacts (ContractContacts gibi bir join tablosu aracılığıyla ve rol belirtilerek)
• RenewalCases 1-to-many Documents (teklifler ve notlar döngüye bağlanır)

Örnek: 60 günlük ihbar süresi olan bir SaaS sözleşmesi için bir Contract kaydı olmalı, ama her yıl için yeni bir RenewalCase. 2025 vakası teklifi, onayları ve karar tarihini 2024'ü üzerine yazmadan saklar.

Yenilemeleri yöneten tarihler, şartlar ve durumlar

Bir yenileme takipçisi ancak tarihler ve durumlar kesin olduğunda işe yarar. Tarihleri gerçeğin kaynağı sayın ve her durum takımın bir sonraki ne yapacağını göstermeli.

Başlangıç için birkaç zorunlu tarih belirleyin:

• Başlangıç tarihi ve mevcut dönem bitiş tarihi
• İhbar son tarihi (bitiş tarihi eksi ihbar süresi)
• İptal son tarihi (bazen ihbarla aynı, bazen değil)
• Bir sonraki otomatik yenileme tarihi (sadece AutoRenew etkinse)
• Son yenilenme tarihi

AutoRenew'u basit bir boolean olarak tutun (AutoRenew = true/false) ve bunu net şartlarla destekleyin: yenileme süresi (örneğin 12 ay), yenileme periyodu (aylık, yıllık, çok yıllık) ve yenileme tarihinin bitiş tarihinden mi yoksa fatura tarihinden mi hesaplandığı.

Bir sonraki yenileme tarihini hesaplarken her sözleşme için tek bir kural kullanın (aylık ise 1 ay ekle, yıllık 12 ay ekle, çok yıllık ise N yıl ekle). Yenileme erken olursa yeni bitiş tarihinin nasıl hesaplanacağına bir kez karar verin: ya eski bitiş + dönem ya da yenileme tarihi + dönem. Bu seçimi saklayın ki sonra değişmesin.

Durumlar gerçek iş adımlarıyla uyuşmalı ve her zaman bir sonraki eylem sahibini ima etmelidir. Basit bir set genellikle yeterlidir: upcoming (tarihe bağlı), in review, waiting approval, approved, renewed, canceled.

Köşe durumları açıkça ele alın:

• Unknown end date: kaydı “date missing” olarak işaretleyin ve düzeltilene kadar hatırlatmaları engelleyin.
• Evergreen contracts: bitiş tarihi yok, ama periyodik inceleme tarihleri ekleyin.
• One-time purchases: yenileme yok, ama harcama geçmişi için saklayın.

Örnek: 12 aylık otomatik yenilemeli ve 60 günlük ihbar süresi olan bir sözleşme, bitiş tarihideksi 90 günde “upcoming” olabilir, sonra ihbar son tarihi karar verilmeden geçerse yükseltilebilir.

Onaylar: aşamalar ve yönlendirme kuralları

Onaylar, yenileme takipçisinin ya zaman kazandırdığı ya da karmaşa yarattığı yerdir. Aşamaları basit tutun ve yüksek riskli veya yüksek tutarlı yenilemelerin gözden kaçmasını önleyecek kadar katı yönlendirme kuralları koyun.

Yaygın bir aşama seti:

• Owner review
• Manager approval
• Finance approval
• Legal approval
• Security or Procurement approval (gerektiğinde)

Yönlendirme manuel değil kural tabanlı olmalı. Sözleşme değeri, tedarikçi risk seviyesi ve sözleşme türü çoğu durumu kapsar. Örneğin düşük riskli ve düşük değerli yenilemeler yalnızca Manager ve Finance gerektirebilir. Daha yüksek değerli, yüksek riskli veya veri işleyen yenilemeler Legal ve Security eklemelidir.

Onayların ne zaman başlayacağını net tetikleyicilerle tanımlayın. Tipik tetikleyiciler: yenileme vakası oluşturulduğunda, teklif alındığında veya fiyat değiştiğinde. Fiyat veya ana madde değişikliklerini onayları sıfırlayan bir durum olarak kabul edin. Teklif onaylar başladıktan sonra değişirse, gerekli aşamaları yeniden açın ki nihai onay mevcut şartlara karşılık gelsin.

Onay eylemleri net olmalı: approve, reject veya request changes. "Request changes" akışı durdurmalı ve görevi gerekli yorumlarla sahibine geri göndermelidir. Reddetme bir gerekçe ve bir sonraki adım (yeniden pazarlık, iptal, tedarikçi değişikliği) gerektirmelidir.

Örnek: 30.000$ değerinde yüksek riskli bir SaaS yenilemesi Owner -> Manager -> Finance -> Legal -> Security yolunu takip edebilir.

Hatırlatma ve yükseltme kuralları

Hatırlatma sistemi, insanların güveneceği bir takipçi ile göz ardı edilen bir takipçi arasındaki farktır. Doğru kilometre taşında hatırlatın, doğru zamanda mesaj atın ve iş yapılır yapılmaz durdurun.

Kilometre taşlarını ayırın. Çoğu yenilemenin iki önemli tarihi vardır: ihbar son tarihi (iptal veya yeniden pazarlık için son gün) ve yenileme tarihi (sözleşmenin yenilenmesi). Hatırlatmaları önce ihbar son tarihine bağlayın; çünkü onu kaçırmak genellikle maliyetlidir.

Her kilometre taşı için basit bir takvim:

• 90 gün önce
• 60 gün önce
• 30 gün önce
• 14 gün önce
• 7 gün önce

Yükseltme zamanla değil, işlem eksikliğine göre tetiklenmelidir. İşlem tanımı olarak sahip onayı, karar seçimi (yenile, iptal, yeniden pazarlık) veya onay isteği gönderilmesi gibi eylemleri kabul edin.

Pratik bir yükseltme zinciri:

• Bir hatırlatmadan sonra 3 iş günü içinde işlem yoksa yedek sahibi bilgilendir.
• Ardından 5 iş günü daha içinde hâlâ işlem yoksa sahibin yöneticisine bildirim gönder.
• İhbar son tarihi 7 gün içindeyse ve hâlâ karar yoksa hukuk/satınalma ortak posta kutusunu bilgilendir.
• Yüksek değerli yenilemeler için Finance'a 30 gün kala da bildirim gönderin.

Mesajları sahibin saat diliminde mesai saatlerinde gönderin (örneğin Pazartesi-Cuma 09:00–17:00). Sahip saat dilimi eksikse sözleşmenin iş birimi saat dilimine başvurun.

Durdurma koşulları katı olmalı. Bir yenileme vakası Approved, Renewed, Canceled veya Replaced olarak işaretlendiğinde, o vaka için tüm gelecekteki hatırlatmalar derhal durmalıdır. Sahip 60 gün kala "Renegotiate" seçerse, ihbar hatırlatmalarını duraklatın ve pazarlık ve onay takiplerine geçin.

Bildirim içerik kuralları ve şablonlar

Doğru kişilerin doğru mesajı doğru zamanda alması bildirimlerin işe yaramasını sağlar. E-posta, uygulama içi ve sohbet arasında içeriği tutarlı tutun ki kimse mesajın neyle ilgili olduğunu sormak zorunda kalmasın.

Adım bazında tipik alıcılar:

• Sözleşme sahibi: her kilometre taşı için hep
• Mevcut onaylayıcı(lar): sadece işlem gerektiğinde
• İzleyiciler (hukuk, satınalma, hesap ekibi): durum değişiklikleri ve onay tamamlandığında
• Finance: PO gerektiğinde veya harcama eşik aşıldığında
• Yükseltme yöneticisi: sadece gecikmiş tarihler veya takılı onaylar sonrası

Zorunlu mesaj alanları

Her bildirim aynı çekirdek alanları içermeli ki aranabilir ve kolayca triage edilebilir olsun:

• Sözleşme adı ve tedarikçi
• Yenileme son tarihi (ve kalan gün sayısı)
• Mevcut durum ve aşama sahibi
• Sonraki eylem (onayla, teklifi incele, PO doğrula, pazarlık yap)
• Nerede işlem yapılacağı (ekran adı veya kayıt ID)

Karar vermeyi kolaylaştıran bağlamı ekleyin: son yenileme sonucu, mevcut fiyat ve teklifin eklenip eklenmediği.

Şablonlar

İki versiyon kullanın: mobil dostu özet ve e-posta veya uygulama içi için detaylı versiyon.

SHORT (chat/push)
[Renewal due in {days_left} days] {contract_name} - {vendor}
Status: {status}. Next: {next_action}.
Record: {contract_id}

DETAILED (email/in-app)
Subject: Action needed: {contract_name} renewal by {due_date}

Vendor: {vendor}
Due date: {due_date} ({days_left} days)
Current status: {status}
Next action: {next_action}
Owner: {owner_name}
Approver(s): {approver_list}
Price: {current_price} ({currency})
Last renewal: {last_outcome} on {last_renewal_date}
Quote: {quote_available}
Notes: {key_notes}
Record: {contract_id}

Güvenlik kuralı: bildirimleri bir uyarı olarak ele alın, veri dökümü olarak değil. Kanal güvenli değilse (örneğin paylaşılan bir sohbet), banka bilgileri, tam sözleşme metni veya özel fiyatlandırma gibi hassas alanlardan kaçının. Alıcıyı uygulama içindeki kayda yönlendirerek izinler ve denetim kayıtlarının uygulanmasını sağlayın.

Adım adım: iş akışlarını uygulamak

Temelle başlayın: güvenilir bir veri modeli ve net sahiplik.

1) Önce varlıkları inşa edin

Temel tabloları oluşturun ve sıkı bağlayın: Contracts, Vendors, iç Paydaşlar (kullanıcılar veya ekipler) ve RenewalCases. Contracts bir Vendor ve bir Owner referanslamalı. RenewalCases bir Contract'a referans vermeli, mevcut yenileme durumunu taşımalı ve hatırlatmalarda kullanılacak ana tarihleri saklamalı.

Pratik kural: bir Contract zaman içinde birçok RenewalCase'e sahip olabilir, ama aynı anda yalnızca bir aktif vaka olsun.

2) Durumları ve doğrulama kurallarını tanımlayın

Hangi durumların olduğunu ve her aşamada nelerin doldurulması gerektiğini kararlaştırın. Katı olun. Taslak yenileme şartları ve ilgili doküman eklenmeden "Legal review"e izin vermeyin. Onay tarihi, onaylayan ve nihai şart tarihleri ayarlanmadan "Approved"a izin vermeyin.

3) Durum iş akışlarını oluşturun

Şunları uygulayan süreçler oluşturun:

• Bir sözleşme yenileme penceresine girdiğinde otomatik olarak bir RenewalCase oluşturma
• Vakayı aşamalar arasında taşıma (Draft, Review, Approved, Sent, Closed)
• Görevleri vendor, sözleşme türü, değer, risk seviyesi veya departmana göre yönlendirme
• Her durum değişikliğini denetim olayı olarak kaydetme
• Yenileme sonuçlanınca vakayı kapatma ve Contract'ı güncelleme

Örnek: Bir sözleşme Operations tarafından sahiplenilmiş ve yıllık değeri eşiklerin üzerindeyse Legal incelemesi Finance onayından önce zorunlu olsun.

4) Planlı hatırlatma ve yükseltme kontrolleri ekleyin

Günlük çalışan bir iş (scheduled job) çalıştırın; ihbar son tarihi yaklaşan, işlem gecikmiş veya bir aşama çok uzun süredir takılı vakaları bulsun. Hatırlatma olayları ve yükseltmeler (yedek sahibi bilgilendirme veya yöneticiyi izleyici ekleme gibi) oluşturun.

5) Kanalları bağlayın ve teslim kayıtlarını tutun

İnsanların gerçekten okuduğu kanallar üzerinden bildirim gönderin (e-posta, SMS, Telegram). Her teslim denemesini zaman damgası, kanal, alıcı ve sonuç ile kaydedin ki hatırlatmaların gönderildiğini ispatlayabilesiniz ve kaçırmaları hata ayıklayabilesiniz.

Günlük kullanılacak ekranlar ve raporlar

Takipçiyi güncel tutmanın yolu günlük ekranların bir soruyu hızlı yanıtlamasıdır: benim sıradaki ne? Bir büyük panodan ziyade gerçek alışkanlıklara uyan birkaç görünüm oluşturun.

Yenileme takvimi (ekip görünümü)

Takvim görünümü son tarihlere odaklandığında en iyisidir, her sözleşme detayına değil. Bu haftaya ve gelecek aya düşen yenilemeleri net durum etiketleriyle gösterin. Her öğe en önemli tarihi (çoğunlukla ihbar son tarihi) göstermeli. Mayıs 1'inde yenilenecek bir sözleşme Mart 1 ihbar tarihine kadar "güvende" olabilir; takvim bunu vurgulamalı.

Sahip gelen kutusu (benim yenilemelerim)

Çoğu kullanıcı için burası ana ekrandır. Önce ihbar tarihine göre, sonra risk seviyesine göre sıralayın. Eylem odaklı tutun: onay için gönder, hukuk incelemesi iste, yenileme bildirimi gönder, tedarikçiyle takip et.

Kısa bir alan seti yeterlidir:

• Sözleşme adı + tedarikçi
• İhbar son tarihi + yenileme tarihi
• Durum + sonraki adım
• Risk seviyesi + tahmini aylık maliyet

Onay kuyruğu (benim onaylarım)

Onaylayıcılar çok fazla tıklama yapmak istemez. Her satır tedarikçi, sözleşme değeri, dönem uzunluğu, yenileme türü (otomatik vs manuel), önerilen değişiklikler (fiyat artışı, kapsam değişikliği) ve onay için son tarih gibi bağlam içermeli. Kuyruğa düşme sebebi de açık olmalı: "Finance onayı gerekiyor çünkü yıllık harcama eşik aşılıyor." gibi.

Tedarikçi görünümü (bir tedarikçi, ona bağlı her şey)

Bir tedarikçi aradığında kişiler tüm resmi görmek ister: sözleşmeler, yenileme tarihleri, risk seviyesi, açık eylemler ve mevcut onaylayıcı. Bu görünüm aynı zamanda çakışan sözleşmeleri önlemeye ve yoğunlaşma riskini görmeye yardımcı olur.

İnsanların gerçekten okuyacağı günlük raporlar

Raporları basit ve zamanlanabilir tutun: aylara göre yaklaşan harcamalar, riskteki yenilemeler (ihbar son tarihi X gün içinde), ve sahip bazlı gecikmiş eylemler.

İzinler ve denetim izi temelleri

Bir yenileme takipçisi ancak insanlar ona güvendiğinde işe yarar. Bu iki şeye bağlıdır: doğru kişiler doğru detayları görebilmeli ve her önemli değişiklik kayda geçirilmelidir.

Rol tabanlı erişim (kim neyi görebilir ve yapabilir)

Küçük bir rol setiyle başlayın ve gerekirse genişletin:

• Viewer: temel detayları ve tarihleri okur, ama fiyatlama veya ekleri göremez.
• Contract Owner: kendi sözleşmelerini düzenler, doküman yükler, onay ister.
• Approver (Legal/Finance/Procurement): onaylar veya reddeder, yorum ekler, sözleşme değerlerini ve ana maddeleri görür.
• Admin: rolleri yönetir, yönlendirme kurallarını değiştirir, arşivleri yönetir.

Hassas alanları genel alanlardan ayrı tutun. Tipik kısıtlı öğeler: sözleşme değeri, rate kartları, banka bilgileri ve imzalı PDF'ler. Bir belge genişçe paylaşılacaksa, ayrı bir kırpılmış/redakte versiyon saklayın.

Denetim izi (neler kaydedilmeli)

Durum değişikliklerini, onayları ve belge güncellemelerini denetlenebilir olaylar olarak ele alın. En azından şunları yakalayın:

• Changed by (kullanıcı), changed at (zaman damgası)
• Alan veya eylem (durum, sahip, yenileme tarihi, dönem, doküman yükleme)
• Eski değer ve yeni değer
• Yorum (reddetme, iptal veya tarih değişikliği için zorunlu)
• Kaynak (UI, otomasyon, import), mevcutsa

Belgeler için sürümleri saklayın ve bir dosyayı current signed copy olarak işaretleyin. Üzerine yazmayın. Dosya adı, sürüm numarası, kim tarafından/ne zaman yüklendi ve isteğe bağlı etiket (örneğin "Signed v3") tutun.

Silme yerine arşivi tercih edin; arşivlenen sözleşmeler raporlama ve yenileme geçmişi için aranabilir kalmalı.

Bir sözleşmenin ilerlemesine izin vermeden önce bazı temel kontrolleri zorunlu kılın: vendor, owner, backup owner, başlangıç/bitiş tarihleri (veya evergreen bayrağı), yenileme türü (otomatik veya manuel), ihbar süresi ve yenileme dönemi.

Yaygın hatalar ve kaçınma yolları

Bir yenileme takipçisine güveni hızlıca kırmanın en kolay yolu, takip edildiğini sandığınız bir tarihi kaçırmaktır.

Yaygın bir hata tek bir "yenileme tarihi" alanı kullanıp işin bittiğini varsaymaktır. Gerçek yenilemeler ihbar pencerelerine bağlıdır (örneğin "60 gün önceden ihbar vermezseniz yıllık olarak otomatik yenilenir"). Bu durumu düzeltmek için en az şunları izleyin: efektif tarih, dönem bitiş tarihi, otomatik yenileme bayrağı, ihbar son tarihi ve hatırlatmaları yönlendiren hesaplanmış bir sonraki eylem tarihi.

Başka bir sorun da hatırlatmaların iniş yeri olmaması. Sahip yoksa mesajlar dağılır ve kimse işlem yapmaz. Her sözleşmede sahip ve yedek sahibi zorunlu kılın ve "Active" durumuna bunlar olmadan izin vermeyin.

Onaylar, gerçek eşikleri göz ardı ettiğinde başarısız olur. Tek bir iş akışı küçük yenilemeler için işe yarayabilir, ama yüksek riskli veya yüksek değerli sözleşmeler geldiğinde çöker. Yönlendirme kuralları birkaç basit faktörü kapsamalı: değer bantları, risk seviyesi veya veri duyarlılığı, sözleşme türü, standart dışı maddeler ve departman veya maliyet merkezi.

Bildirimler, insanlara sonraki adımı söylemediğinde göz ardı edilir. Her hatırlatma bir sonraki eylem, bir son tarih ve sonucu (otomatik yenileme, fiyat artışı, hizmet kesintisi) içermelidir.

Ekipler ayrıca sonuçları kaydetmeyi unutuyor; böylece her döngü yeniden başlıyor. Her döngüde sonucu (renewed, terminated, renegotiated), yeni dönem detaylarını ve kısa bir "ne değişti" notunu yakalayın.

Hızlı kontroller ve sonraki adımlar

Tamam demeden önce, gerçek hayata benzeyen birkaç kontrol çalıştırın. Yenileme takipçileri genellikle kenar durumlarda başarısız olur: ihbar süreleri, eksik sahipler ve kağıt üzerinde iyi görünen ama ilerlemeyen onaylar.

Hızlı kontroller (3 test sözleşmesi kullanın)

Farklı terimlere sahip üç örnek sözleşme kurun:

• Bir otomatik yenilenen sözleşme; ihbar tarihlerinin doğru izlendiğini doğrulamak için.
• Bir manuel yenileme sözleşmesi; kimse onaylamadan ilerlememeli.
• Uzun dönemli bir sözleşme; uzun aralıklarda hatırlatmaların çalıştığını doğrulamak için.

Her sözleşme için hatırlatmaların önce ihbar son tarihi sonra yenileme/bitiş tarihine göre tetiklendiğini doğrulayın. Sahip olarak hiçbir şey yapmayın ve yükseltmenin yedek sahibine ulaştığını ve birisi işlem yapana kadar devam ettiğini teyit edin.

Ardından onayları uçtan uca test edin. Bir sözleşmeyi onay yolundan, bir diğerini reddetme yolundan geçirin. Denetim izi kimin, ne zaman ve neden karar verdiğini yakalamalı. Kayıtlar 10 saniyede "ne oldu?" sorusunu cevaplamıyorsa, sıkışık tarihlerde yardımcı olmayacaktır.

Sonraki adımlar

Küçük başlayın, sonra yalnızca temel işler sıkıcı hissettirdiğinde genişletin:

• Minimal bir sürümle başlayın: temel varlıklar, net durumlar ve iki hatırlatma (örneğin ilk ihbar ve son ihbar).
• Hatırlatmalar güvenilir olana kadar onayları eklemeyin.
• Sahipliği zorunlu kılın: her sözleşmede owner ve backup owner gerektirin.
• Bir ekip ile iki haftalık pilot yapın, sonra hatırlatma zamanlamalarını ve yükseltme rollerini ayarlayın.

Kod yazmadan dahili operasyonel bir uygulama inşa etmek isterseniz, AppMaster (appmaster.io) veriyi modelleme, onay iş akışları oluşturma ve çoklu kanallarda bildirim gönderme için bir seçenek olabilir.

Bu kontroller geçtikten sonra yenileme takipçiniz gerçek sözleşmeler için hazır olur; sadece iyi senaryo demoları için değil.