Tedarikçi Sözleşmesi Bitişlerini Takip Eden Bir Web Uygulaması Oluşturun

Bir Sözleşme Bitiş Takipçisinin Çözmesi Gerekenler

Bir sözleşme bitiş takipçisi, “bunu beklemiyorduk” anlarını önlemek için vardır: sürpriz yenilemeler, kaçırılan bildirim pencereleri ve anlaşma PDF'inin birinin gelen kutusunda kalması yüzünden son dakika telaşları.

Çözmesi gereken problemler

Çoğu ekip aynı hatalara düşer:

• Kaçırılan yenilemeler ve bildirim süreleri: Birçok sözleşme yenilemeden 30–90 gün önce iptal bildirimi gerektirir. O tarih geçerse, bağlı kalırsınız.
• Otomatik yenileme maddeleri: Anlaşmalar sessizce başka bir döneme devreder, bazen fiyat artışıyla birlikte.
• Dağınık dosyalar ve belirsiz şartlar: İmzalı versiyon bulunması zor, değişiklikler başka yerde saklanmış ve hangi tarihin bağlayıcı olduğu net değil.

Gerçekte kim kullanır (ve neden)

Kullanışlı bir takipçi, insanları sözleşme uzmanı olmaya zorlamadan farklı rolleri desteklemeli:

• Satınalma (Procurement): Yenileme görünürlüğüne ihtiyaç duyar, erken pazarlık ve tedarikçi gider yönetimi için.
• Hukuk (Legal): En son yürürlüğe giren anlaşmaya, kilit maddelere ve eklere erişim ister.
• Finans: Öngörülebilir nakit planlaması ve ödeme koşullarının teyidine ihtiyaç duyar.
• Departman sahipleri (IT, Pazarlama, İK vb.): Yenileme, yeniden pazarlık veya iptal kararı almak için hatırlatmalara ve bağlama ihtiyaç duyar.

Hedeflenecek çıktılar

Takipçi çalıştığında sağlar:

• Daha az sürpriz (sessiz yenilemeler olmaz).
• Daha iyi pazarlık zamanlaması (bildirim son tarihinden önce görüşmelere başlanır).
• Net sahiplik (her sözleşmenin sorumlu bir kişisi ve yedeği olur).

İlk günden takip edilecek başarı metrikleri

Benimseme ve güvenilirliği gösterecek ölçülebilir sinyaller seçin:

• Sahibi atanmış sözleşmelerin %'si (ve departman)
• Hatırlatma teslim oranı (gönderilen vs. bounce/başarısız) — e-posta ve Slack genelinde
• Zamanında yenileme kararları (kararlar bildirim tarihinden önce kaydedilmiş)
• Ana tarihleri doldurulmuş sözleşmelerin %'si (bitiş, bildirim son tarihi, yenileme dönemi)

Eğer MVP bu sorunları tutarlı biçimde çözebiliyorsa, gelişmiş özellikleri eklemeden önce en maliyetli sözleşme hatalarını önlemiş olursunuz.

MVP Kapsamı ve Özellik Kontrol Listesi

Bir MVP sözleşme bitiş takipçisi şu soruya anında cevap vermeli: “Yakında ne bitiyor, kim sahibi ve sonraki adım ne?” v1'i hızlı teslim edilebilir kadar küçük tutun, sonra gerçek kullanım verilerine göre genişletin.

Hemen tam özel bir altyapı kurmak istemiyorsanız, Koder.ai gibi sohbet tabanlı bir spesifikasyondan çekirdek ekranları ve hatırlatma akışını prototiplemenize yardımcı olabilecek bir vibe-coding platformu kullanarak hızlı ilerleyebilirsiniz — hazırlanıp operasyonel hale geldiğinizde gerçek, dışa aktarılabilir kaynak kodu üretebilir.

Temel MVP özellikleri (mutlaka olmalı)

• Sözleşme listesi: tedarikçi adı, sözleşme adı/ID, başlangıç tarihi, bitiş tarihi ve statü (Aktif/Süresi doldu).
• Sahip alanı: sorumlu kişi ve gerekirse yedek sahibi.
• Bitişe bağlı hatırlatma zamanlaması (ör. 90/60/30/7 gün) ve net “bir sonraki hatırlatma” göstergesi.
• Basit arama ve filtreler: tedarikçi, sahip, “X gün içinde sona eren” ve statü.
• Basit sözleşme detay sayfası: ana tarihler, yenileme türü (otomatik/manuel), notlar ve iliştirilmiş belge bağlantısı.

İyi olur ama v1 sonrası ekleyin

• Madde etiketleme ve yapılandırılmış meta veri (ör. “fesih”, “fiyat artışı”, “veri işleme”).
• E-imza ve kaynak bağlantıları (DocuSign/Dropbox/Drive URL) ile ekiplerin orijinal iş akışına hızlıca atlaması.
• Tedarikçi puan kartları (yenileme riski, performans notları) yenileme kararlarını destekler.

v1 için açıkça kapsam dışı

Projeyi tam bir sözleşme yaşam döngüsü yönetim sistemine dönüştürmemek için şunları v1 dışında tutun:

• Çok adımlı onay ve hukuk inceleme iş akışları
• Pazarlıkta kırmaca araçları
• Basit notlar dışındaki karmaşık yükümlülük yönetimi (teslimatlar, SLA'lar)

Role göre basit kullanıcı hikâyeleri

Sözleşme Sahibi: “Yakında sona erecek sözleşmelerimi görebiliyorum ve pazarlık için yeterince erken hatırlatma alıyorum.”

Satınalma/Yönetici: “Sözleşme ekleyip/düzenleyip sahip atayabiliyorum, böylece hiçbir şey atlanmıyor.”

Finans/Liderlik (yalnızca görüntüleme): “Yaklaşan yenilemeleri görebiliyorum, harcama tahmini yapabiliyorum ve sürpriz otomatik yenilemeleri önleyebiliyorum.”

Bu hikâyeleri temiz ekranlar ve güvenilir hatırlatmalarla sunabiliyorsanız, sağlam bir MVP'niz var demektir.

Veri Modeli: Tedarikçiler, Sözleşmeler, Şartlar ve Tarihler

Bir sözleşme takipçisinin başarısı, yakalanan verilere bağlıdır. Model çok eksikse hatırlatmalar güvenilmez olur; çok karmaşıksa insanlar bilgi girmeyi bırakır. “Çekirdek kayıt + birkaç yapılandırılmış alan” ile vakaların %90'ını kapsayacak bir denge hedefleyin.

Temel varlıklar

Tedarikçi (Vendor), ödediğiniz şirkettir. Arama ve raporlama için saklanacak temel bilgiler: yasal isim, gösterim adı, tedarikçi türü (yazılım, tesis, ajans) ve varsa dahili tedarikçi ID'si.

Sözleşme (Contract), takip ettiğiniz anlaşmadır. Bir tedarikçinin birden fazla sözleşmesi olabilir (ör. lisans ve destek için ayrı anlaşmalar), bu yüzden Sözleşmeyi Tedarikçiye bağlı ayrı bir kayıt olarak tutun.

Sahiplik ve kişiler

Her sözleşmenin net bir sözleşme sahibi (yenileme kararlarından sorumlu kişi) ve tatiller/işten ayrılmalar için bir yedek sahibi olmalı. Bu alanları zorunlu tutun.

Ayrıca kilit kişileri kaydedin:

• Tedarikçi temsilcisi isim/e-posta
• Dahili paydaşlar (isteğe bağlı)

Önemsenecek tarihler ve şartlar

Çoğu uygulama sadece “başlangıç” ve “bitiş” tarihlerini saklar ve sonra neden yenilemelerin kaçırıldığını merak eder. Birkaç tarihi açıkça takip edin:

• Başlangıç tarihi (dönemin başladığı gün)
• Bitiş tarihi (yenilenmezse hizmetin duracağı gün)
• Bildirim son tarihi (iptal/yenilememe bildiriminin son günü)
• Yenileme/sonraki dönem tarihi (bir sonraki dönemin başladığı gün)

Otomatik yenileme ve ay-a-yıl kuralları

Yaygın yenileme desenlerini kapsayacak birkaç yapılandırılmış alan ekleyin:

• Yenileme türü: sabit-dönem, otomatik-yenileme, aylık
• Yenileme periyodu: ör. 12 ay, 1 ay
• Otomatik yenileme etkin: evet/hayır

Aylık devam eden sözleşmelerde “bitiş tarihi” bilinmeyebilir. Bu durumda hatırlatmaları bildirim sonu kuralları üzerinden (ör. “sonraki fatura döngüsünden 30 gün önce bildir”) tetikleyin.

Her Sözleşme için Statü Kuralları ve Yaşam Döngüsü

Statüler sadece etiket değil — panodaki sayıları, hatırlatma zamanlamalarını ve raporlamayı yönlendiren mantıktır. Erken belirleyin, basit tutun ve her tedarikçi anlaşmasında tutarlı olmasına dikkat edin.

Temel statüler (birbirini dışlamalı)

MVP için pratik bir set:

• Aktif: Sözleşme yürürlükte ve “yakında sona erecek” penceresinde değil.
• Yakında Sona Erecek: Sözleşme hâlâ aktif, ama yenileme aksiyonu yaklaşıyor.
• Yenilendi: Yeni dönem yürürlüğe girdi (genellikle yeni bir sözleşme kaydı ya da yeni sürüm ile bağlanır).
• İptal Edildi: Sözleşme doğal bitiş tarihinden önce sonlandırıldı.
• Arşivlendi: Uzun süre sonra ya da yenileme tamamlandıktan sonra hatırlatma üretmemesi gereken tarihsel kayıt.

“Yakında Sona Erecek”i net eşiklerle tanımlayın

Herkesin “yakında”nın ne demek olduğunu anlaması için sabit pencereler seçin. Yaygın seçenekler 30/60/90 gün öncesi. Eşiklerin kuruluş (veya sözleşme türüne) göre yapılandırılabilir olmasını sağlayın.

Bitiş tarihi değişirse ne olacağını da belirleyin: statü otomatik olarak yeniden hesaplanmalı ki eski “Yakında Sona Erecek” bayrakları kalmasın.

Temiz raporlama için sebep kodları

Bir sözleşme İptal Edildi veya Arşivlendi olduğunda bir sebep kodu zorunlu kılın, örn:

• İptal edildi
• Yerine geçti (başka bir anlaşma tarafından ikame edildi)
• Tedarikçi birleşmesi (karşı taraf değişti)
• Yenilememe

Bu kodlar üç aylık raporlama ve tedarikçi risk incelemelerini kolaylaştırır.

Her statü değişikliğini kaydedin (denetime uygun)

Statüyü denetlenebilir bir alan olarak ele alın. Kimin değiştirdiği, ne zaman ve neyin değiştiği (eski statü → yeni statü, sebep kodu ve isteğe bağlı not) kaydedilsin. Bu, neden hatırlatmaların durduğunu veya neden bir yenilemenin kaçırıldığını açıklamada faydalıdır.

Hatırlatma Motoru ve Bildirim Tasarımı

Bir sözleşme takipçisi yalnızca insanlar hatırlatmaya göre hareket ederse işe yarar. Amaç “daha çok bildirim” değil — ekibinizin çalışma şekline uygun, zamanında ve eyleme dönüştürülebilir dürtmeler üretmektir.

Kanalları seçin (basit başlayın)

Önce e-posta ile başlayın: evrensel, denetlenmesi kolay ve ekstra yönetim gerektirmez. İş akışı stabil olunca isteğe bağlı Slack/Teams teslimatı ekleyin.

Kullanıcı ya da departman başına kanal tercihleri tutun, böylece Finans e-postada kalırken Satınalma sohbet içinde çalışabilir.

Sürprizleri önleyecek hatırlatma takvimi

Bitiş tarihine bağlı öngörülebilir bir kadans kullanın:

• Bitişten 90 / 60 / 30 / 7 gün önce

Ayrıca bildirim son tarihi (ör. “iptal için 45 gün öncesi bildirim verilmelidir”) için ayrı ve daha yüksek öncelikli bir uyarı sınıfı ekleyin. Çünkü bunu kaçırmak sizi başka bir döneme kilitleyebilir.

Hatırlatmaları eyleme dönüştürün: onayla ve ertele

Her bildirim iki tek tıklamalı eylem içermeli:

• Onayla: “Gördüm ve ilgileniyorum.” Bu adım için tekrar eden pingleri durdurur.
• Ertele: Küçük, kontrollü bir süreyle erteleme (ör. 3 gün, 1 hafta) ile gürültüyü azaltın ama sorumluluğu kaybettirmeyin.

Eylemleri denetim günlüklerine kaydedin (kim onayladı, ne zaman ve varsa yorum) ki takipler net olsun.

Hiçbir şey yapılmazsa yükseltme

Sözleşme sahibi belirlenen pencerede onay vermezse (örn. 3 iş günü), yedeğe veya yöneticisine yükseltme gönderin. Yükseltmeler sınırlı ve açık olmalı: “Henüz yanıt yok; sahipliği doğrulayın veya yeniden atayın.”

Gürültü kontrolü ve güvenilirlik

Hatırlatmaları çoğaltmayın, sessiz saatlere saygı gösterin ve başarısız denemeleri yeniden deneyin. Mesajlar geç veya iki kez gelirse iyi tasarım bile başarısız olur.

UX Akışı: Gösterge Paneli, Arama ve Sözleşme Detay Sayfaları

Bir sözleşme takipçisi hız üzerine kurulu: doğru anlaşmayı bulup yenileme tarihini onaylamak ve güncellemek bir dakikadan kısa sürmeli. UX'i en sık yapılan işlemler etrafında tasarlayın — sırada ne var kontrolü, arama ve küçük düzenlemeler.

Dahil edilecek temel sayfalar

Gösterge Paneli (Dashboard) soruyu yanıtlamalı: “Yakında ne dikkat gerektiriyor?” Öncelik verilecek: Yaklaşan Yenilemeler (gelecek 30/60/90 gün) ve birkaç KPI (ör. bu ay sona erecekler, yakında otomatik yenilenecekler, eksik belgeler). İki ana görünüm sağlayın:

• Tablo görünümü: tarama ve toplu işlemler için (bitişe, sahip veya tedarikçiye göre sırala)
• Takvim görünümü (“yenileme takvimi”): planlama ve düzenli toplantılar için

Sözleşme Detay sayfası “tek gerçek kaynak” olmalı. En gerekli bilgiler üstte: tedarikçi, statü, bitiş tarihi, yenileme şartları, sahip ve bildirim ayarları. Destekleyici öğeleri altta tutun: notlar, etiketler, bağlı belgeler ve ilişkili kişiler.

Tedarikçi Detay tüm o tedarikçiye bağlı bilgileri toplar: aktif sözleşmeler, geçmiş sözleşmeler, kilit kişiler ve yenileme kalıpları. Kullanıcıların “onlardan başka neler alıyoruz?” sorusuna bu sayfada cevap verilir.

Ayarlar basit kalmalı: bildirim varsayılanları, roller, Slack/e-posta bağlantıları ve standart etiketler/statüler.

Arama, filtreler ve kaydedilmiş görünümler

Aramayı sürekli erişilebilir yapın. Filtreleri destekleyin: tedarikçi, sahip, statü, tarih aralığı ve etiket. Gösterge paneline “hızlı filtreler” ekleyin (örn. “14 gün içinde otomatik yenileme”, “Sahipsiz”, “Taslak”). Tekrarlanan filtreler varsa, “Benim yenilemelerim” veya “Finans onayları” gibi kaydedilmiş görünümler sunun.

Hızlı güncellemeler için tasarım

Çoğu düzenleme küçük olur. Tablo içinde ve sözleşme detay sayfasının üst bölümünde tarih, sahip ve statü için satır içi düzenleme kullanın. Değişiklikleri hafifçe onaylayın ve yanlışlıkla yapılan değişiklikler için “Geri al” seçeneği sunun.

Gezintiyi tutarlı tutun: gösterge paneli → arama sonuçları → sözleşme detay, net geri dönüş yolu ve kalıcı filtreler ile kullanıcıların bağlamı kaybetmemesini sağlayın.

Belge Depolama ve Versiyon Kontrolü

Sözleşme takipçisi, evrak olmadan tamamlanmış sayılmaz. Önemli belgeleri ana tarihler yanında saklamak, yenileme zamanı geldiğinde “imzalanmış kopyayı bulamıyoruz” anlarını önler.

Neleri yüklemeli (ve neden)

İnsanların gerçekten aradığı minimum dosyalarla başlayın:

• İmzalı anlaşma PDF'i (gerçek kaynak)
• Değişiklikler ve ekler (fiyat, süre veya bildirimleri değiştirebilir)
• Yenileme/iptal e-postaları/mektupları (bildirim ve zaman kanıtı)

MVP'de yüklemeyi isteğe bağlı tutun ama “belge eksik” durumunu sözleşme detay sayfasında görünür yapın.

Depolama yaklaşımı: nesne depolama + veritabanı bağlantıları

Çoğu ekip için en basit ve güvenilir yapı:

• Dosyaları nesne depolamada saklayın (S3-uyumlu depolama)
• Veritabanınızda sadece meta veriyi saklayın: dosya URL/anahtarı, orijinal dosya adı, boyut, içerik tipi, checksum, uploaded_by, uploaded_at ve hangi sözleşme/sürüm ile ilişkili olduğu

Bu veritabanınızı küçük ve hızlı tutar; büyük PDF'leri nesne depolama verimli şekilde yönetir.

Versiyonlama: en son vs önceki belgeler

Belgeleri değiştirilemez kayıtlar olarak ele alın. Bir PDF’yi “değiştirmek” yerine yeni bir sürüm yükleyin ve bunu en son olarak işaretleyin.

Pratik model:

• document_group (ör. “Ana Anlaşma”)
• document_version (v1, v2, v3…)

Sözleşme sayfasında varsayılan olarak en son sürümü gösterin; önceki sürümlerin kısa bir geçmişini (kim yükledi, ne zaman, kısa not) sunun.

İndirme, değiştirme ve silme izinleri

Belge erişimi rol bazlı olmalı:

• Görüntüleyiciler: sadece indirilebilir
• Editörler: yeni sürüm yükleyebilir (ve isteğe bağlı not ekleyebilir)
• Adminler: izinleri yönetir; silme yalnızca gerçekten gerekliyse

Silme izni veriyorsanız “soft delete” (UI'dan gizle, ancak depolamada tut) düşünün ve her zaman işlemleri denetim günlüğüne kaydedin. Kontroller hakkında daha fazla için /security-and-audit bölümünü gözden geçirin.

Güvenlik, İzinler ve Denetim Kayıtları

Sözleşme verileri sadece tarihler değil—fiyatlama, pazarlık edilmiş şartlar ve imzalı anlaşmaları içerir. Bu yüzden güvenliği MVP'de bile temel bir özellik olarak ele alın.

Roller ve izin seviyeleri

Gerçek sorumluluklara uyan küçük bir rol setiyle başlayın:

• Admin: kullanıcıları, rolleri, genel ayarları ve entegrasyonları yönetir.
• Editor: tedarikçi/sözleşme oluşturup güncelleyebilir, dosya yükleyebilir ve hatırlatmaları yönetebilir.
• Viewer: sadece okuma erişimi (yenileme takvimi görmek isteyen paydaşlar için)
• Legal-only: hukuk alanlarını ve belgeleri görebilir, finans alanlarını göremez.
• Finance-only: fiyatlama, fatura koşulları ve yenileme maliyetlerini görebilir, iç hukuk notlarını göremez.

Rolleri basit tutun, sonra kayıt düzeyinde istisnalar ile genişletin.

Kayıt düzeyinde erişim (kim neyi görebilir)

Kuralları tedarikçi başına tanımlayın ve ilişkili tüm sözleşmelere miras verin. Yaygın desenler:

• Tedarikçi görünürlüğü Tüm çalışanlar, Belirli ekipler veya Adlandırılmış kullanıcılar olabilir.
• Özellikle hassas anlaşmalar için sözleşme görünürlüğü tedarikçi görünürlüğünü geçersiz kılabilir.
• Dosya indirmeyi hem sözleşmeyi görüntüleyebilen hem de “Dosya indir” izni olan kullanıcılarla sınırlandırın.

Bu, yanlışlıkla açığı önlerken aynı zamanda ekipler arası takip desteği sunar.

Kimlik doğrulama: SSO veya e-posta + MFA

Kuruluşunuzda bir kimlik sağlayıcısı varsa SSO (SAML/OIDC) etkinleştirin ki erişim istihdama bağlı olsun. Yoksa e-posta/parola ile MFA (TOTP veya passkey) kullanın ve güçlü oturum kontrolleri (zaman aşımı, cihaz iptali) uygulayın.

Gerçekten kullanılacak denetim günlükleri

İnceleme ve uyuşmazlıklarda işe yarayacak eylemleri kaydedin:

• Dosya indirme, yükleme ve silme işlemleri
• Sözleşme düzenlemeleri (eski değer → yeni değer), özellikle yenileme tarihleri ve otomatik yenileme maddeleri
• İzin ve rol değişiklikleri

Denetim kayıtlarını tedarikçi/sözleşme bazında aranabilir ve uygun şekilde dışa aktarılabilir yapın; bu "sözleşmeler için denetim izi" güveni kanıta dönüştürür.

Mevcut Sözleşmeleri İçe Aktarma ve Entegrasyonlar

Bir sözleşme takipçisi, içindeki gerçek dünya anlaşmalarını içerdiğinde işe yarar. İki yol planlayın: hızlı “sisteme sok” içe aktarım ki ekip uygulamayı hemen kullanmaya başlasın ve zaman içinde manuel işi azaltacak daha derin entegrasyonlar.

Hızlı başlangıç: CSV içe aktarım

Manuel CSV içe aktarımı, sözleşmeleri tablolarınızdan veya paylaşılan sürücülerden yüklemenin en basit yoludur. İlk versiyonu toleranslı ve hatırlatmaları yönlendiren alanlara odaklı yapın:

• Tedarikçi adı (isteğe bağlı tedarikçi ID)
• Sözleşme adı/türü
• Başlangıç tarihi, bitiş/bitiş tarihi, otomatik yenileme bayrağı
• Yenileme bildirim penceresi (örn. 30/60/90 gün)
• Sahip (kişi veya ekip)

İndirilebilir bir şablon ve sütun eşleme adımı sunun; kullanıcıların sütun adlarını uygulamanızın alanlarıyla eşleştirmesine izin verin. Ayrıca kaydetmeden önce hataları vurgulayan bir önizleme ekranı sağlayın.

Bekleyebileceğiniz veri temizliği

İçe aktarımlar dağınık veriyi ortaya çıkarır. İlk yüklemenin bir destek talebine dönüşmemesi için küçük bir temizleme iş akışı hazırlayın:

• Tedarikçi çoğaltmaları: “Acme Inc.” vs “ACME” vs “Acme, LLC” — birleştirme önerileri sunun ve içe aktarım sırasında mevcut bir tedarikçi kaydını seçme imkânı verin.
• Tutarsız tarih formatları: 01/02/2026 farklı anlamlara gelebilir. Formatları algılayın, kullanıcıdan onay isteyin ve ayrıştırılmış sonucu gösterin.
• Eksik sahipler veya tarihler: İçe aktarımın devam etmesine izin verin, ancak tamamlanmamış satırları “İnceleme Gerekiyor” kuyruğuna taşıyın.

Opsiyonel entegrasyonlar (manuel işi azaltmak için)

Temel işler yoluna girdikten sonra entegrasyonlar tedarikçi ve yenileme bilgisini güncel tutabilir:

• Google Workspace / Microsoft 365 kişi listeleri: tedarikçi iletişimlerini çekerek “Hesap yöneticisi”, fatura e-posta ve telefon doldurma.
• Takvim senkronizasyonu: isteğe bağlı olarak bitiş ve bildirim tarihleri için takvim etkinlikleri oluşturun.

ERP / satınalma sistemi ile eşitleme

Eğer kurumunuzda zaten bir ERP veya satınalma aracı varsa, bunu tedarikçi kayıtları için tek gerçek kaynak olarak değerlendirin. Hafif bir senkronizasyon tedarikçi ve ID'leri gecelik içe aktarabilir; sözleşmeye özel tarihler uygulamanızda yönetilmeye devam edebilir. Çakışmalarda hangi veri kaynakının üstün olduğunu belgeleyin ve kullanıcıya “Son senkronizasyon” zaman damgası gösterin ki veriye güvenilsin.

Otomasyon eklemeyi düşündüğünüzde bunu yönetici alanından görünür yapın (ör. /settings/integrations) ve mühendislik özel süreçlerinin arkasına gizlemeyin.

Zamanlama ve Güvenilirlik için Arka Uç Mantığı

Bir sözleşme takipçisi “basit” görünür ama hatırlatmalar tetiklenmediğinde, iki kez tetiklendiğinde veya yanlış yerel saatte geldiğinde sorunlar baş gösterir. Arka uç, öngörülebilir, hata ayıklanabilir ve güvenle yeniden denenebilir bir zamanlama katmanına ihtiyaç duyar.

Hatırlatmalar ve yükseltmeler için arka plan işleri

Web istekleri içinde hatırlatma mantığı çalıştırmak yerine bir iş kuyruğu kullanın (ör. Sidekiq/Celery/BullMQ). İki iş deseni işe yarar:

• Günlük zamanlayıcı işi: her saat (veya günlük) çalışır ve yakında olan hatırlatmalar için per-sözleşme işleri kuyruğa ekler.
• Sözleşme başına hatırlatma işleri: her sözleşme için her hatırlatma penceresinde (90/60/30/7/1 gün gibi) bir iş ve eylem kaydı yoksa çalışacak yükseltme işleri.

Yükseltmeler açık olmalı: önce “sahibi bildir”, sonra “yöneticiye bildir”, sonra gerekirse “finansa bildir” gibi adımlar arasına gecikmeler koyun ki herkesi spamlemeyin.

Zaman dilimleri ve iş günleri

Tüm zaman damgalarını UTC olarak saklayın, ama “vade tarihlerini” sözleşme sahibinin zaman diliminde (veya kuruluşun varsayılanında) hesaplayın (ör. “bitişten 30 gün önce sabah 09:00 yerel saatte”).

İş günü hesaplaması destekliyorsanız, el yapımı çözümlerden kaçının. Ya bir iş takvimi kütüphanesi kullanın ya da küçük bir “şirket takvimi” tablosu (hafta sonları + tatiller) tutup hatırlatmaları önceki iş gününe kaydırın. Kuralı loglarda ve sözleşme detay sayfasında görünür yapın, böylece kullanıcılar neden hatırlatmanın bir Cuma yerine bir Cuma sabahı geldiğini anlar.

Tekrar eden bildirimleri önleyin (idempotency)

Yeniden denemeler normaldir. Bildirim gönderimini idempotent tasarlayın:

• contract_id + reminder_type + scheduled_for_date + channel gibi benzersiz bir anahtarlık ile bir notification_outbox kaydı oluşturun.
• Bu anahtarda benzersiz kısıtlama uygulayın.
• Ekleme başarılıysa gönderin; zaten varsa güvenle çıkın.

Böylece işler iki kez çalışsa bile uygulamanız “en fazla bir kez” gönderim garantisi verir.

Değişkenlerle metin şablonları

İş kullanıcılarının metni kod değişikliği olmadan ayarlayabilmesi için şablonları merkezileştirin. Desteklenecek değişkenler:

• {{vendor_name}}
• {{contract_title}}
• {{expiration_date}}
• {{days_remaining}}
• {{contract_url}} (örn. /contracts/123 gibi göreli bir bağlantı)

Şablonları sunucu tarafında render edin, son render edilmiş metni denetim ve hata ayıklama için outbox'ta saklayın ve e-posta ile Slack için aynı temel payload'u kullanın.

Test, Pilot Yayılımı ve Canlıya Geçiş Kontrol Listesi

Test etme, sözleşme takipçilerinin sessizce başarısız olduğu yerdir: bir tarih kuralı bir gün hata verir, otomatik yenileme yanlış yorumlanır veya bildirimler gönderilir ama teslim edilmez. Hatırlatma motorunu faturalama mantığı gibi ele alın — yüksek etki, düşük tolerans.

Neleri test etmelisiniz (ve nasıl)

Otomatik testleri “UI parlatmasından” çok “sözleşme gerçeği” etrafında yazın:

• Tarih kuralları: bitiş tarihleri, “geçerli olduğu son tarih” ifadeleri, zaman dilimleri ve dahil-dışlama mantığı (örn. bir sözleşme 2026-03-31 23:59'a kadar geçerli midir?).
• Bildirim son tarihleri: 30/60/90 günlük pencerelerin hesaplandığı durumları test edin; hafta sonu/tatil kaydırmalarını da dahil edin.
• Otomatik yenileme mantığı: “45 gün öncesine kadar iptal edilmediği sürece 1 yıl daha yenilenir” gibi kuralları ve bir sonraki dönemin doğru hesaplanmasını doğrulayın.

Gerçekçi örnek sözleşme demoları oluşturun ve her biri için üretilen hatırlatma takvimini doğrulayan testler yazın.

Bildirim güvenilirliği kontrolleri

Staging ortamında gerçek gelen kutular (Gmail, Outlook) ile e-posta teslim edilebilirliğini test edin ve doğrulayın:

• SPF/DKIM/DMARC uyumu
• Bounce yönetimi ve bastırma davranışı
• Kritik olmayan uyarılar için abonelikten çıkma/iptal davranışı

Slack bildirimleri destekliyorsanız, oran limitlerini, kanal izinlerini ve kanal arşivlendiğinde ne olduğunu doğrulayın.

Pilot yayılımı: küçük, gerçek, ölçülebilir

Satınalma + finans gibi küçük bir grupla gerçek sözleşmeler kullanarak pilot yürütün. Başarı metriklerini tanımlayın: “Kaçırılan yenileme yok”, “%<5 yanlış hatırlatma” ve “Tüm sözleşmeler 10 saniyenin altında aranabilir” gibi. Haftalık geri bildirim toplayın ve kural boşluklarını ölçeği büyütmeden önce düzeltin.

Koder.ai ile ilk versiyonunuzu inşa ediyorsanız, pilot aynı zamanda hatırlatma mantığı ve izin kurallarında anlık görüntü/geri alma kullanarak güvenle yineleme yapmanın doğru zamanıdır.

Canlıya geçiş hazırlık kontrol listesi

Lansmandan önce doğrulayın:

• Her takım için admin rolleri ve erişimler doğru ayarlı
• Yedekleme/geri yükleme testi yapılmış
• Hatırlatma işleri zamanında çalışıyor ve izleniyor
• Destek yolu hazır (başarısız içe aktarımlar veya hatalı tarihler için kimin müdahale edeceği)
• Kısa bir dahili rehber yayınlanmış (örn. /blog/contract-tracker-playbook)

Analitik, Raporlama ve Sürekli Bakım

Bir sözleşme takipçisi, insanlara erken hareket etmelerinde yardımcı olduğunda değer kazanır — sadece anlaşmaları saklamak yetmez. Bu, net raporlama, hafif etkileşim metrikleri ve veriyi güvenilir tutmak için basit bir bakım planı gerektirir.

İnsanların gerçekten kullandığı pratik raporlar

Başlangıç olarak birkaç “her zaman açık” görünüm sunun:

• Aylara göre yaklaşan yenilemeler: önümüzdeki 30/60/90 gün içinde hangi ayda kaç sözleşme var gösteren yenileme takvimi.
• Sahibe göre: kim hangi sözleşmelerden sorumlu, böylece yöneticiler yenileme yükünü dengeleyebilir.
• Tedarikçiye göre: bir tedarikçiye bağlı tüm sözleşmeleri gösterin, konsolidasyon fırsatlarını yakalamak için.

Dışa aktarmalar basit olsun: CSV ve uygulama içinde paylaşılabilir filtrelenmiş bağlantılar.

Etkileşim sinyalleri: onaylar ve kaçırılan bildirimler

“Hatırlatmayı hiç görmedik” durumunu önlemek için birkaç olayı takip edin:

• Onaylar: alıcının “Onayla”ya tıklaması veya “İlerleniyor” olarak işaretlemesi
• Gecikmiş yenilemeler: yenileme karar tarihini geçmiş ama karar kaydı olmayan sözleşmeler
• Kaçırılan bildirimler: teslim edilemeyen (e-posta bounce, Slack hatası) veya hiç onaylanmamış hatırlatmalar

Bu sinyaller cezalandırıcı olmamalı; esas amaç operasyonel netlik: nerede takip gerektiğini ve bildirim ayarlarının çalışıp çalışmadığını görmektir.

Planlanacak sürekli iyileştirmeler

MVP istikrar kazandıktan sonra gerçek değer katan sonraki yükseltmeler:

• Etiketler (örn. “otomatik-yenileme”, “güvenlik incelemesi gerekli”) hızlı filtreleme ve raporlama için
• Şablonlar: standart şartlar ve hatırlatma zaman çizelgeleri için
• Onay iş akışları (hafif): talep eden → onaylayan → kaydedilmiş karar

Veriyi temiz tutacak destek süreçleri

Birkaç basit çalışma prosedürü yazın ve iç yardım sayfasından erişilebilir yapın (örn. /help/admin):

• Veri düzeltmeleri: kim ana tarihleri düzenleyebilir, neden değiştirildiği nasıl belgelenir
• Erişim talepleri: rolleri nasıl verirsiniz ve izinler ne sıklıkla gözden geçirilir
• Yedeklemeler ve geri yüklemeler: yedekleme sıklığı, yedeklerin nerede olduğu ve geri yükleme testlerinin nasıl yapılacağı

Bu temellerle uygulama lansmandan sonra da kullanışlı kalır ve raporlama yenileme planlaması için güvenilir bir kaynak haline gelir.