Tedarikçi sözleşmesi bitişlerini takip eden bir web uygulamasını planlamayı, inşa etmeyi ve yayına almayı; belgeleri saklamayı ve zamanında yenileme hatırlatmaları göndermeyi öğrenin.
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ı.
Çoğu ekip aynı hatalara düşer:
Kullanışlı bir takipçi, insanları sözleşme uzmanı olmaya zorlamadan farklı rolleri desteklemeli:
Takipçi çalıştığında sağlar:
Benimseme ve güvenilirliği gösterecek ölçülebilir sinyaller seçin:
Eğer MVP bu sorunları tutarlı biçimde çözebiliyorsa, gelişmiş özellikleri eklemeden önce en maliyetli sözleşme hatalarını önlemiş olursunuz.
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.
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:
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.
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.
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.
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:
Ç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:
Yaygın yenileme desenlerini kapsayacak birkaç yapılandırılmış alan ekleyin:
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.
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.
MVP için pratik bir set:
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.
Bir sözleşme İptal Edildi veya Arşivlendi olduğunda bir sebep kodu zorunlu kılın, örn:
Bu kodlar üç aylık raporlama ve tedarikçi risk incelemelerini kolaylaştırır.
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.
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.
Ö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.
Bitiş tarihine bağlı öngörülebilir bir kadans kullanın:
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.
Her bildirim iki tek tıklamalı eylem içermeli:
Eylemleri denetim günlüklerine kaydedin (kim onayladı, ne zaman ve varsa yorum) ki takipler net olsun.
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.”
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.
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.
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:
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.
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.
Ç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.
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.
İnsanların gerçekten aradığı minimum dosyalarla başlayın:
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.
Çoğu ekip için en basit ve güvenilir yapı:
Bu veritabanınızı küçük ve hızlı tutar; büyük PDF'leri nesne depolama verimli şekilde yönetir.
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.
Belge erişimi rol bazlı olmalı:
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.
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.
Gerçek sorumluluklara uyan küçük bir rol setiyle başlayın:
Rolleri basit tutun, sonra kayıt düzeyinde istisnalar ile genişletin.
Kuralları tedarikçi başına tanımlayın ve ilişkili tüm sözleşmelere miras verin. Yaygın desenler:
Bu, yanlışlıkla açığı önlerken aynı zamanda ekipler arası takip desteği sunar.
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.
İnceleme ve uyuşmazlıklarda işe yarayacak eylemleri kaydedin:
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.
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.
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:
İ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.
İç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:
Temel işler yoluna girdikten sonra entegrasyonlar tedarikçi ve yenileme bilgisini güncel tutabilir:
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.
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.
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:
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.
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.
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.Böylece işler iki kez çalışsa bile uygulamanız “en fazla bir kez” gönderim garantisi verir.
İş 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 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.
Otomatik testleri “UI parlatmasından” çok “sözleşme gerçeği” etrafında yazı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.
Staging ortamında gerçek gelen kutular (Gmail, Outlook) ile e-posta teslim edilebilirliğini test edin ve doğrulayın:
Slack bildirimleri destekliyorsanız, oran limitlerini, kanal izinlerini ve kanal arşivlendiğinde ne olduğunu doğrulayın.
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.
Lansmandan önce doğrulayın:
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.
Başlangıç olarak birkaç “her zaman açık” görünüm sunun:
Dışa aktarmalar basit olsun: CSV ve uygulama içinde paylaşılabilir filtrelenmiş bağlantılar.
“Hatırlatmayı hiç görmedik” durumunu önlemek için birkaç olayı takip edin:
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.
MVP istikrar kazandıktan sonra gerçek değer katan sonraki yükseltmeler:
Birkaç basit çalışma prosedürü yazın ve iç yardım sayfasından erişilebilir yapın (örn. /help/admin):
Bu temellerle uygulama lansmandan sonra da kullanışlı kalır ve raporlama yenileme planlaması için güvenilir bir kaynak haline gelir.
Üç yaygın hatayı önlemelidir:
Eğer güvenilir şekilde “ne yakında bitiyor, kim sorumlu ve sırada ne var?” sorularına cevap veriyorsa, amacını gerçekleştiriyor demektir.
Küçük ve sevk edilebilir bir kapsamla başlayın:
İleri düzey özellikleri (madde etiketleme, puan kartları, entegrasyonlar) yalnızca hatırlatmalar güvenli çalıştıktan sonra ekleyin.
Hatırlatmaların doğru çalışması için tarihleri ayrı ayrı saklayın:
Çoğu kaçırılan yenileme, ekiplerin sadece başlangıç/bitiş tarihlerini saklayıp bildirim penceresini göz ardı etmesinden kaynaklanır.
Birkaç yapılandırılmış alan kullanın:
Ay bazında devam eden sözleşmelerde “bitiş tarihi” belirsizse, uyarıları bir bitiş tarihinden ziyade (ör. “sonraki fatura döneminden 30 gün önce bildir”) üzerinden tetikleyin.
Statüleri birbirini dışlayacak ve mantığı tetikleyecek şekilde basit tutun:
Tarihler değiştiğinde statüyü otomatik yeniden hesaplayın ve kim/ ne zaman/ neden değiştirdi kaydını tutun.
Pratik bir varsayılan zamanlaması:
Her bildirimde iki tek tıklamalı eylem bulunmalı:
E-posta evrenseldir ve denetlenmesi kolay olduğundan varsayılan olarak en iyi seçenektir. Süreç istikrarlı olduktan sonra Slack/Teams ekleyin.
Gürültüyü azaltmak için:
Ayrıca teslim sonuçlarını (gönderildi/bounce/başarısız) takip edin ki sisteme güven duyulsun.
Basit ve ölçeklenebilir bir yaklaşım:
Belgeleri değiştirirken eski belgeleri silmeyin; yeni bir sürüm yükleyin ve varsayılan olarak en son sürümü gösterin. Böylece geçmiş versiyonlar erişilebilir kalır.
Başlangıç için küçük bir rol setiyle başlayın (Admin, Editör, Görüntüleyici) ve gerekirse Legal-only veya Finance-only gibi sınırlı rolleri ekleyin.
Erişim kontrolü:
Önemli denetim olaylarını kaydedin: sözleşme düzenlemeleri (özellikle tarihler/yenileme maddeleri), izin değişiklikleri ve dosya yükleme/indirme/silme.
Kullanıcıların uygulamayı hızlıca kullanmaya başlaması için esnek bir CSV içe aktarım aracı yeterlidir. Sağlayın:
Temizlik ihtiyacı bekleyin: tedarikçi çoğaltmaları, karışık tarih formatları, eksik sahipler/tarihler. Eksik satırları kaydetmeye izin verin ama bunları “İnceleme Gerekiyor” kuyruğuna taşıyın ki hatırlatmalar sessizce başarısız olmasın.
Eğer onay gelmezse, tanımlı pencereden sonra yedek sahibine veya yöneticisine yükseltme yapın.