रिमाइंडर और अनुमोदन के लिए अनुबंध नवीनीकरण ट्रैकर विनिर्देश

नवीनीकरण ट्रैकर को किन समस्याओं का हल करना चाहिए

एक अनुबंध नवीनीकरण ट्रैकर इसलिए बनता है क्योंकि वही समस्याएँ बार-बार आती रहती हैं: नवीनीकरण तिथियाँ छूट जाती हैं, मालिक अस्पष्ट होता है, और महत्वपूर्ण विवरण ईमेल थ्रेड, स्प्रेडशीट और साझा ड्राइव्स में बिखर जाते हैं। जब कोई अंततः नवीनीकरण पर ध्यान देता है, अक्सर नेगोशिएट, रद्द करने या बजट करने के लिए देर हो चुकी होती है।

ट्रैकर को कुछ बेसिक्स सेकंडों में बताने चाहिए:

• क्या नवीनीकरण हो रहा है (vendor/customer, अनुबंध, सेवा)
• कब नवीनीकरण है (नोटिस डेडलाइन, समाप्ति तिथि, ऑटो-रिन्यू तिथि)
• किसे कार्रवाई करनी है (बिजनेस ओनर, लीगल, फाइनेंस, प्रोक्योरमेंट)
• आगे क्या होगा (रिव्यू, अनुमोदन, हस्ताक्षर, भुगतान)
• क्या बदला (नोट्स, निर्णय, और किसने उन्हें मंज़ूर किया)

लक्ष्य है आश्चर्य और आखिरी पल के काम के बिना संगत नवीनीकरण। इसके लिए भरोसेमंद तिथियाँ, स्पष्ट जिम्मेदार मालिक और एक स्थिति चाहिए जो वास्तविकता को दर्शाए। अगर कोई अनुबंध "Under review" पर चिह्नित है, तो लोगों को यह दिखना चाहिए कि क्या अवरुद्ध कर रहा है और अगला कार्य किसका है।

स्कोप को व्यावहारिक रखें: रिमाइंडर जो समय पर चलें, अनुमोदन जो सही लोगों तक पहुंचें, स्टेकहोल्डर्स के लिए दृश्यता ताकि वे योजना बना सकें, और ऑडिट नोट्स जो साफ़ इतिहास दिखाएँ। दस्तावेज़ भंडारण सरल अटैचमेंट या साइन की गयी कॉपी के संदर्भ के रूप में हो सकता है, लेकिन मुख्य शर्तें और डेडलाइन्स हमेशा आसानी से मिलनी चाहिए।

स्टेकहोल्डर्स और जिम्मेदारियाँ

एक नवीनीकरण ट्रैकर तभी काम करता है जब स्वामित्व स्पष्ट हो। अगर हर कोई "ज़िम्मेदार" है, तो कोई भी नहीं होगा।

अधिकांश टीमों के लिए भूमिकाओं का एक छोटा सेट काम करता है:

• Contract owner: नवीनीकरण चलाता है, ज़रूरतें पुष्टि करता है, शर्तों पर नेगोशिएट करता है, और तारीखें सटीक रखता है।
• Requester: वह व्यक्ति या टीम जो सेवा का उपयोग कर रही है; पुष्टि करती है कि नवीनीकरण करना है, घटाना है, या रद्द करना है।
• Finance: बजट, भुगतान शर्तें, विक्रेता सेटअप और लागत परिवर्तनों की जांच करता है।
• Legal: शर्तों की समीक्षा, रेडलाइन, और जोखिम आइटम; पुष्टि करता है कौन सा टेम्पलेट या क्लॉज़ सेट लागू होता है।
• Department head: जब खर्च या स्कोप किसी थ्रेशहोल्ड को पार करता है तो अंतिम बिजनेस अनुमोदक।

प्रत्येक को सूचित (informed) रखने वालों को approvers से अलग रखें। अप्रूवर्स परिणाम बदल सकते हैं (approve, reject, request changes)। जिनको सिर्फ़ सूचित किया जाता है, वे वर्कफ़्लो को ब्लॉक नहीं करते।

स्वामित्व को दो फ़ील्ड से दर्शाएँ: primary owner और backup owner। बैकअप अवकाश, नौकरी परिवर्तन और तात्कालिक नवीनीकरण के दौरान महत्वपूर्ण होता है। एक साधारण नियम काम करता है: यदि primary owner ने एक निर्धारित समय में कार्रवाई नहीं की, तो backup को नोटिफाई करें और उन्हें लेने की अनुमति दें।

विक्रेता पक्ष की उपेक्षा न करें। एक ही ईमेल के बजाय рол के अनुसार विक्रेता संपर्क स्टोर करें, क्योंकि अलग-अलग लोग अलग मुद्दों को संभालते हैं। अधिकांश टीमों को कम से कम एक sales संपर्क (कमर्शियल शर्तें), एक billing संपर्क (इनवॉइस और भुगतान), और एक support संपर्क (सेवा मुद्दे और एस्केलेशन) चाहिए।

उदाहरण: एक मार्केटिंग टीम एनालिटिक्स टूल का नवीनीकरण अनुरोध करती है। contract owner उपयोग और प्रस्तावित टियर की पुष्टि करता है, Finance खर्च को मंज़ूर करता है, Legal शर्तों को मंज़ूर करता है, और department head केवल तभी मंज़ूर करता है जब नया वार्षिक कुल आपके थ्रेशहोल्ड से ऊपर हो। बाकी सभी सूचित रहते हैं, ताकि नवीनीकरण अटकें नहीं।

Entity model: वास्तविक तालिकाएँ जो आपको चाहिए

एक नवीनीकरण ट्रैकर सबसे अच्छा तब काम करता है जब आप लंबे समय तक रहने वाले अनुबंध रिकॉर्ड को प्रत्येक नवीनीकरण चक्र से अलग करते हैं। इससे इतिहास साफ़ रहता है और रिमाइंडर अनुमानित रहते हैं।

कोर तालिकाएँ

एक छोटे सेट से शुरू करें और फ़ील्ड को व्यावहारिक रखें:

• Vendors: कानूनी नाम, पंजीकरण विवरण, पता, रिस्क टियर, सक्रिय फ़्लैग।
• Contracts: vendor_id, सेवा का नाम, शुरूआत तिथि, समाप्ति तिथि, नवीनीकरण शर्तें (ऑटो-रिन्यू, नोटिस अवधि), अनुबंध मूल्य, मुद्रा, मालिक।
• Contacts: आंतरिक और विक्रेता संपर्क टाइप (vendor/internal), रोल (legal, finance, service owner), पसंदीदा_CHANNEL (email/SMS/Telegram), is_primary।
• Documents: फ़ाइल मेटाडेटा साथ में प्रकार (original, amendment, renewal quote, note) और एक संक्षिप्त विवरण।
• RenewalCases: contract_id, साइकिल की शुरू/अंत तिथि, लक्ष्य निर्णय तिथि, वर्तमान चरण/स्थिति, कारण (renew, renegotiate, terminate)।

व्यवहार में, Contracts धीरे-धीरे बदलते हैं। RenewalCases इस बार क्या हुआ यह पकड़ते हैं: किसने मंज़ूरी दी, किस कोट आया, और निर्णय कब लिया गया।

अव्यवस्था रोकने के लिए रिश्ते

रिलेशनशिप मॉडल करें ताकि आप बिना अनुमान के पूछ सकें "किसे सूचित करना है?" और "पिछली बार क्या निर्णय हुआ था?":

• Vendors 1-to-many Contracts, Contracts 1-to-many RenewalCases
• Contracts many-to-many Contacts (जॉइन टेबल जैसे ContractContacts के माध्यम से भूमिका सहित)
• RenewalCases 1-to-many Documents (कोट्स और नोट्स साइकिल से जुड़ते हैं)

उदाहरण: 60-दिन की नोटिस अवधि वाले एक SaaS अनुबंध के लिए एक Contract रिकॉर्ड होना चाहिए, लेकिन हर वर्ष एक नया RenewalCase। 2025 का केस कोट, अनुमोदन और निर्णय तिथि संग्रहीत करता है बिना 2024 को ओवरराइट किए।

नवीनीकरण को संचालित करने वाली तिथियाँ, शर्तें और स्टेटस

नवीनीकरण ट्रैकर तभी काम करता है जब तिथियाँ और स्टेटस स्पष्ट हों। तिथियों को स्रोत सच्चाई मानें, और हर स्थिति को यह बताना चाहिए कि टीम को अगला क्या करना है।

शुरूआत करें कुछ आवश्यक तिथियों से:

• Start date और current term end date
• Notice deadline (end date से notice period घटाकर)
• Cancellation deadline (कभी-कभी नोटिस डेडलाइन के समान, कभी नहीं)
• Next auto-renew date (यदि AutoRenew सक्षम है तभी)
• Last renewed on

AutoRenew को साधारण boolean रखें (AutoRenew = true/false), और इसे स्पष्ट शर्तों के साथ सपोर्ट करें: renewal term length (उदाहरण के लिए, 12 महीने), renewal cadence (monthly, annual, multi-year), और क्या renewal date end date से निकलेगी या invoice date से।

जब आप अगली नवीनीकरण तिथि की गणना करें, तो प्रति अनुबंध एक नियम उपयोग करें (monthly में 1 महीना जोड़ें, annual में 12 महीने जोड़ें, multi-year में N वर्ष जोड़ें)। अगर नवीनीकरण जल्दी होता है, तो एक बार तय करें कि नई end date कैसे गणना होगी: या तो पुरानी end date में term जोड़कर, या नवीनीकरण तिथि से term जोड़कर। वह विकल्प स्टोर करें ताकि बाद में न बदले।

स्टेटस वास्तविक कार्य चरणों से मेल खाने चाहिए और हमेशा अगले कार्य के मालिक का संकेत दें। एक साधारण सेट अक्सर पर्याप्त है: upcoming (तिथि-आधारित), in review, waiting approval, approved, renewed, canceled।

एज केस स्पष्ट रूप से हैंडल करें:

• Unknown end date: इसे "date missing" के रूप में मार्क करें और फिक्स होने तक रिमाइंडर ब्लॉक करें।
• Evergreen contracts: कोई end date नहीं, पर périodic review dates जोड़ें।
• One-time purchases: नवीनीकरण नहीं, पर खर्च इतिहास के लिए रखें।

उदाहरण: 12-महिने का ऑटो-रिन्यू अनुबंध जिसकी नोटिस अवधि 60 दिन है, वह end date minus 90 दिनों पर "upcoming" में बदल सकता है, और अगर नोटिस डेडलाइन के बिना निर्णय पास हो जाए तो एस्केलेट कर दें।

अनुमोदन: चरण और रूटिंग नियम

अनुमोदन वह जगह है जहाँ नवीनीकरण ट्रैकर समय बचाता है या अराजकता पैदा करता है। चरणों को सरल रखें और रूटिंग नियम इतने सख़्त रखें कि उच्च-जोखिम या उच्च-मूल्य नवीनीकरण गलती से निकल न जाएँ।

एक सामान्य चरण सेट:

• Owner review
• Manager approval
• Finance approval
• Legal approval
• Security या Procurement approval (जब ज़रूरी हो)

रूटिंग नियम rule-based होने चाहिए, मैन्युअल नहीं। कॉन्ट्रैक्ट मूल्य, विक्रेता रिस्क टियर, और कॉन्ट्रैक्ट टाइप अधिकतर मामलों को कवर करते हैं। उदाहरण के लिए, छोटे थ्रेशहोल्ड के नीचे कम-रिस्क नवीनीकरणों को केवल Manager और Finance की जरूरत हो सकती है। उच्च-मूल्य, उच्च-रिस्क, या डेटा-संभालने वाले नवीनीकरणों में Legal और Security जोड़ें।

यह तय करें कि अनुमोदन कब शुरू होते हैं। सामान्य ट्रिगर हैं: renewal case बनना, कोट मिलना, या मूल्य परिवर्तन। मूल्य या मुख्य-शर्त परिवर्तनों को अनुमोदन रिसेट के रूप में मानें। अगर कोट अनुमोदन शुरू होने के बाद बदलती है, तो आवश्यक चरणों को फिर से खोल दें ताकि अंतिम साइन-ऑफ वर्तमान शर्तों से मेल खाए।

अनुमोदन क्रियाएँ स्पष्ट होनी चाहिए: approve, reject, या request changes। "Request changes" फ्लो को रोक देनी चाहिए और आवश्यक टिप्पणियों के साथ कार्य को owner को वापस भेज देनी चाहिए। रिजेक्शन में कारण और अगला कदम (renegotiate, cancel, switch vendor) चाहिए।

उदाहरण: $30k SaaS नवीनीकरण उच्च रिस्क टियर के साथ Owner -> Manager -> Finance -> Legal -> Security पर रूट होगा।

रिमाइंडर और एस्केलेशन नियम

एक रिमाइंडर सिस्टम भरोसेमंद ट्रैकर और जिसे लोग अनदेखा कर दें, इन दोनों के बीच का अंतर है। सही माइलस्टोन पर याद दिलाएँ, सही समय पर संदेश भेजें, और जैसे ही काम पूरा हो जाए बंद कर दें।

माइलस्टोन्स को अलग करें। अधिकांश नवीनीकरणों में दो प्रमुख तिथियाँ होती हैं: नोटिस डेडलाइन (रद्द या नेगोशिएट करने का आखिरी दिन) और नवीनीकरण तिथि (जब अनुबंध रिन्यू होता है)। नोटिस डेडलाइन को पहले बाँधें, क्योंकि इसे मिस करना आमतौर पर महंगा भूल होती है।

प्रत्येक माइलस्टोन के लिए एक साधारण शेड्यूल:

• 90 दिन पहले
• 60 दिन पहले
• 30 दिन पहले
• 14 दिन पहले
• 7 दिन पहले

एस्केलेशन को केवल समय के आधार पर नहीं बल्कि कार्रवाई की कमी पर ट्रिगर करें। कार्रवाई की परिभाषा तय करें, जैसे owner की पुष्टि, निर्णय चुनना (renew, cancel, renegotiate), या अनुमोदन अनुरोध सबमिट करना।

व्यावहारिक एस्केलेशन चेन:

• रिमाइंडर के 3 कार्यदिवस के भीतर कोई कार्रवाई न होने पर, बैकअप ओनर को सूचित करें।
• अगले 5 कार्यदिवसों में भी कोई कार्रवाई न होने पर, ओनर के मैनेजर को सूचित करें।
• अगर नोटिस डेडलाइन 7 दिनों के अंदर है और अभी भी निर्णय नहीं हुआ, तो लीगल/प्रोक्योरमेंट समूह मेलबॉक्स को सूचित करें।
• उच्च-मूल्य नवीनीकरणों के लिए, 30 दिन पहले Finance को भी नोटिफाई करें।

संदेश मालिक के टाइमज़ोन में व्यापारिक घंटों के दौरान भेजें (उदाहरण: सोमवार से शुक्रवार 9:00 से 17:00)। अगर मालिक का टाइमज़ोन गायब है, तो कॉन्ट्रैक्ट के बिजनेस यूनिट टाइमज़ोन पर fallback करें।

स्टॉप कंडीशंस सख़्त होने चाहिए। एक बार renewal case को Approved, Renewed, Canceled, या Replaced चिह्नित करने पर उस केस के सभी भविष्य के रिमाइंडर तुरंत बंद हो जाने चाहिए। अगर मालिक ने नोटिस डेडलाइन से 60 दिन पहले "Renegotiate" चुना, तो नोटिस रिमाइंडर रोक दें और नेगोशिएशन और अनुमोदन फॉलो-अप पर स्विच कर दें।

नोटिफिकेशन सामग्री नियम और टेम्पलेट

जब सही लोगों को सही समय पर सही संदेश मिले तो नोटिफिकेशन काम करते हैं। ईमेल, इन-एप और चैट में सामग्री सुसंगत रखें ताकि किसी को भी यह पूछना न पड़े कि संदेश किस बारे में है।

प्रत्येक कदम के लिए सामान्य ऑडियन्स:

• Contract owner: हर माइलस्टोन के लिए हमेशा
• Current approver(s): केवल जब कार्रवाई आवश्यक हो
• Watchers (legal, procurement, account team): स्थिति परिवर्तनों और अनुमोदनों पर
• Finance: जब PO की ज़रूरत हो या खर्च थ्रेशहोल्ड पार करे
• Escalation manager: केवल मिस्ड ड्यू डेट्स या अटकी अनुमोदनों के बाद

आवश्यक संदेश फ़ील्ड

हर नोटिफिकेशन में वही कोर फ़ील्ड होने चाहिए ताकि उसे सर्च और ट्राइएज करना आसान हो:

• Contract name और vendor
• Renewal due date (और शेष दिन)
• Current status और stage owner
• Next action (approve, review quote, confirm PO, negotiate)
• कहाँ कार्रवाई करनी है (screen name या record ID)

केवल वही संदर्भ जोड़ें जो निर्णयों में मदद करे: पिछला नवीनीकरण परिणाम, वर्तमान कीमत, और क्या कोट अटैच है।

टेम्पलेट

दो संस्करण रखें: मोबाइल-फ्रेंडली सारांश और ईमेल/इन-एप के लिए विस्तृत वर्शन।

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}

सुरक्षा नियम: नोटिफिकेशन को हेड्स-अप समझें, डेटा डंप नहीं। अगर चैनल सुरक्षित नहीं है (जैसे साझा चैट), तो संवेदनशील फ़ील्ड (बैंक विवरण, पूरी अनुबंध प्रति, विशेष प्राइसिंग) बताने से बचें। प्राप्तकर्ता को रिकॉर्ड ऐप के अंदर खोलने के लिए प्रेरित करें, जहाँ अनुमतियाँ और ऑडिट लॉग लागू होते हैं।

चरण-दर-चरण: वर्कफ़्लो लागू करें

बुनियाद से शुरू करें: भरोसेमंद डेटा मॉडल और स्पष्ट स्वामित्व।

1) पहले एंटिटीज़ बनाएं

कोर तालिकाएँ बनाएं और उन्हें कसकर लिंक करें: Contracts, Vendors, आंतरिक Stakeholders (users या teams), और RenewalCases। Contracts में Vendor और Owner का संदर्भ होना चाहिए। RenewalCases को Contract संदर्भित करना चाहिए, वर्तमान नवीनीकरण स्थिति लेनी चाहिए, और वे मुख्य तिथियाँ स्टोर करें जो रिमाइंडर के लिए उपयोग होंगी।

एक व्यावहारिक नियम: एक Contract के पास समय के साथ कई RenewalCases हो सकते हैं, पर एक समय में केवल एक सक्रिय केस।

2) स्टेटस और वैलिडेशन नियम परिभाषित करें

निर्धारित करें कि कौन-कौन सी स्थितियाँ मौजूद हैं और हर चरण में क्या भरना आवश्यक है। सख़्त रहें। "Legal review" तब तक न दें जब तक ड्राफ्ट रिन्यू शर्तें और संबंधित दस्तावेज़ संलग्न न हों। "Approved" तब तक न दें जब तक approver, approval date, और अंतिम टर्म तिथियाँ सेट न हों।

3) स्टेटस वर्कफ़्लो बनाएं

ऐसे प्रोसेस लागू करें जो:

• जब कोई अनुबंध नवीनीकरण विंडो में आए तो स्वतः RenewalCase बनाएं
• केस को चरणों से आगे बढ़ाएँ (Draft, Review, Approved, Sent, Closed)
• vendor, contract type, value, risk tier, या department के आधार पर रूट करें
• हर स्टेटस परिवर्तन को एक ऑडिट इवेंट के रूप में रिकॉर्ड करें
• केस बंद करें और जब नवीनीकरण फाइनल हो तो Contract अपडेट करें

उदाहरण: अगर एक अनुबंध Operations का है और वार्षिक मूल्य आपके थ्रेशहोल्ड से ऊपर है, तो Finance अनुमोदन से पहले Legal समीक्षा आवश्यक करें।

4) शेड्यूल्ड रिमाइंडर और एस्केलेशन चेक जोड़ें

एक डेली शेड्यूल्ड जॉब चलाएँ जो उन केसों को ढूंढे जहाँ नोटिस डेडलाइन नज़दीक है, कार्रवाई ओवरड्यू है, या कोई चरण बहुत लंबे समय से अटका हुआ है। रिमाइंडर इवेंट और एस्केलेशन बनाएँ (जैसे बैकअप ओनर को नोटिफाई करना या मैनेजर को वॉचर जोड़ना)।

5) चैनल कनेक्ट करें और डिलीवरी लॉग रखें

उन चैनलों के माध्यम से नोटिफाइ करें जिन्हें लोग वास्तव में पढ़ते हैं (email, SMS, Telegram)। हर डिलीवरी प्रयास को टाइमस्टैम्प, चैनल, प्राप्तकर्ता और परिणाम के साथ लॉग करें ताकि आप साबित कर सकें कि रिमाइंडर भेजे गए और मिस होने पर डिबग कर सकें।

रोज़ इस्तेमाल होने वाले स्क्रीन और रिपोर्ट

लोग ट्रैकर तब अपडेट रखते हैं जब दैनिक स्क्रीन एक सवाल का तेज़ जवाब देती है: मुझे अगली क्या करनी है? कुछ ऐसे व्यू बनाएं जो वास्तविक आदतों से मेल खाते हों।

Renewal calendar (टीम व्यू)

कैलेंडर व्यू सबसे अच्छा तब काम करता है जब वह डेडलाइन पर फोकस करे, न कि हर अनुबंध विवरण पर। इस सप्ताह और अगले महीने की नवीनीकरण दिखाएँ स्पष्ट स्टेटस टैग के साथ। हर आइटम वो तारीख दिखाए जो सबसे ज़्यादा मायने रखती है, आमतौर पर नोटिस डेडलाइन। एक अनुबंध जो 1 मई को नवीनीकरण हो रहा है, वह मार्च 1 की नोटिस तिथि तक "safe" माना जा सकता है—यही कैलेंडर को हाईलाइट करना चाहिए।

Owner inbox (my renewals)

यह अधिकांश उपयोगकर्ताओं के लिए होम स्क्रीन है। नोटिस डेडलाइन के अनुसार सॉर्ट करें, फिर रिस्क टियर। यह एक्शन-ओरिएंटेड होना चाहिए: submit for approval, request legal review, send renewal notice, vendor को follow up करें।

एक छोटा सेट फ़ील्ड पर्याप्त है:

• Contract name + vendor
• Notice deadline + renewal date
• Status + next step
• Risk tier + अनुमानित मासिक लागत

Approval queue (my approvals)

अप्रूवर्स को बिना कई स्क्रीन खोलें संदर्भ चाहिए। हर रो में vendor, contract value, term length, renewal type (auto vs manual), प्रस्तावित परिवर्तन (price increase, scope change), और अनुमोदन करने की डेडलाइन शामिल करें। यह भी स्पष्ट कारण दिखाएँ कि यह कतार में क्यों है, जैसे "Finance approval required because annual spend exceeds threshold."

Vendor view (एक विक्रेता, सब कुछ)

जब कोई विक्रेता कॉल करे, लोगों को पूरा चित्र चाहिए: अनुबंध, नवीनीकरण तिथियाँ, रिस्क टियर, खुले कार्य और वर्तमान approver। यह दृश्य डुप्लिकेट अनुबंध रोकता है और सांद्रता जोखिम (concentration risk) दिखाने में मदद करता है।

रोज़ाना रिपोर्ट जो लोग पढ़ते हैं

रिपोर्ट सरल और शेड्यूल कर सकने योग्य रखें: प्रति माह आने वाला अनुमानित खर्च, जोखिम पर नवीनीकरण (नोटिस डेडलाइन X दिनों के भीतर), और ओवरड्यू कार्रवाइयाँ मालिक के अनुसार।

परमिशन्स और ऑडिट ट्रेल बेसिक्स

लोग ट्रैकर पर तभी भरोसा करते हैं जब सही लोग सही विवरण देख सकें और हर महत्वपूर्ण बदलाव रिकॉर्ड हो।

रोल-आधारित एक्सेस (लोग क्या देख और कर सकते हैं)

छोटे रोल सेट से शुरू करें और ज़रूरत पर ही बढ़ाएँ:

• Viewer: बुनियादी विवरण और तिथियाँ पढ़ता है, पर मूल्य या अटैचमेंट नहीं देखता।
• Contract Owner: अपने अनुबंध संपादित कर सकता है, दस्तावेज़ अपलोड कर सकता है, अनुमोदन अनुरोध कर सकता है।
• Approver (Legal/Finance/Procurement): approve या reject कर सकते हैं, टिप्पणियाँ जोड़ सकते हैं, अनुबंध मान और मुख्य क्लॉज़ देख सकते हैं।
• Admin: रोल मैनेज करता है, रूटिंग नियम बदलता है, आर्काइव संभालता है।

संवेदनशील फ़ील्ड सामान्य फ़ील्ड से अलग रखें। सामान्य तौर पर प्रतिबंधित आइटम में अनुबंध मूल्य, रेट कार्ड, बैंक विवरण और साइन किए गए PDFs शामिल हैं। यदि किसी दस्तावेज़ को व्यापक रूप से साझा करना है, तो एक रेडैक्टेड वर्शन अलग फ़ाइल के रूप में रखें।

ऑडिट ट्रेल (क्या लॉग होना चाहिए)

स्टेटस परिवर्तन, अनुमोदन और दस्तावेज़ अपडेट्स को ऑडिटेबल घटनाओं के रूप में ट्रिट करें। न्यूनतम रूप से कैप्चर करें:

• Changed by (user), changed at (timestamp)
• Field or action (status, owner, renewal date, term, document upload)
• Old value और new value
• Comment (reject, terminate, या renewal date change पर आवश्यक)
• Source (UI, automation, import), अगर उपलब्ध हो

दस्तावेजों के लिए, वर्ज़न रखें और एक फ़ाइल को current signed copy के रूप में चिह्नित करें। ओवरराइट न करें। फ़ाइल नाम, वर्ज़न नंबर, किसने/कब अपलोड किया और एक वैकल्पिक लेबल जैसे "Signed v3" रखें।

हटाने के बजाय आर्काइव को प्राथमिकता दें ताकि रिपोर्टिंग और नवीनीकरण इतिहास के लिए रिकॉर्ड्स उपलब्ध रहें।

किसी अनुबंध को आगे बढ़ाने से पहले कुछ बुनियादी जाँचों को अनिवार्य करें: vendor, owner, backup owner, start/end dates (या evergreen फ़्लैग), renewal type (auto या manual), notice period, और renewal term।

सामान्य गलतियाँ और उन्हें कैसे टाला जाए

एक नवीनीकरण ट्रैकर में भरोसा जल्दी टूटता है जब आप एक डेडलाइन मिस कर देते हैं जो आप सोचते हैं कि आप ट्रैक कर रहे हैं।

एक आम गलती एक ही "renewal date" फ़ील्ड का उपयोग करना और उसे पर्याप्त मान लेना है। वास्तविक नवीनीकरण नोटिस अवधि पर टिका होता है (उदाहरण: "60 दिन पहले नोटिस दें वरना ऑटो-रिन्यू" )। इसे ठीक करने के लिए कम से कम ये ट्रैक करें: effective date, term end date, auto-renew flag, notice deadline, और एक गणितीय next action date जो रिमाइंडरों को ड्राइव करे।

एक और समस्या रिमाइंडर का होना पर कहीं उतरने का स्थान न होना है। अगर मालिक बाहर है, संदेश इधर-उधर हो जाते हैं और कुछ भी नहीं होता। हर अनुबंध पर एक मालिक और एक बैकअप मालिक अनिवार्य करें, और बिना उनके "Active" स्थिति ब्लॉक करें।

अनुमोदन तब फेल होते हैं जब वे वास्तविक थ्रेशहोल्ड्स को अनदेखा करते हैं। एक ही वर्कफ़्लो छोटे नवीनीकरणों के लिए काम कर सकता है, लेकिन उच्च-जोखिम या उच्च-मूल्य अनुबंध आने पर टूट सकता है। रूटिंग नियम कुछ सरल फैक्टर्स को कवर करें: value bands, रिस्क लेवल या डेटा संवेदनशीलता, contract type, नॉन-स्टैंडर्ड क्लॉज़, और विभाग या खर्च केंद्र।

नोटिफिकेशन तब अनदेखे हो जाते हैं जब वे नहीं बताते कि अगले कदम क्या है। हर रिमाइंडर में एक अगला कार्य होना चाहिए (review, approve, renegotiate, cancel), एक देय तिथि, और परिणाम (auto-renew, price increase, service interruption)।

टीमें परिणाम रिकॉर्ड करना भूल जाती हैं, इसलिए हर साइकिल फिर से खाली से शुरू होती है। नतीजा कैप्चर करें (renewed, terminated, renegotiated), नई शर्तों का विवरण, और एक छोटा "क्या बदला" नोट।

त्वरित जाँच और अगले कदम

डोन कहने से पहले कुछ जाँच चलाएँ जो वास्तविक जीवन का अनुकरण करें। नवीनीकरण ट्रैकर अक्सर किनारों पर फेल होते हैं: नोटिस पीरियड, गायब मालिक, और अनुमोदन जो कागज़ पर ठीक दिखते हैं पर कभी आगे नहीं बढ़ते।

त्वरित जाँच (3 टेस्ट कॉन्ट्रैक्ट का उपयोग करें)

तीन नमूना अनुबंध सेट करें जिनकी शर्तें अलग हों:

• एक ऑटो-रिन्यू करने वाला अनुबंध जिसमें नोटिस डेडलाइन हो ताकि आप नोटिस तिथियों को ट्रैक कर रहे हैं, सिर्फ़ end dates नहीं।
• एक मैनुअल नवीनीकरण अनुबंध जहाँ कुछ नहीं होता जब तक किसी का अनुमोदन और साइन-ऑफ न हो।
• एक बहु-वर्षीय अनुबंध जिसमें मध्य-कालिक समीक्षा तिथि हो ताकि यह पुष्टि हो सके कि लंबे अंतराल रिमाइंडरों को नहीं तोड़ते।

प्रत्येक अनुबंध के लिए पुष्टि करें कि रिमाइंडर पहले नोटिस डेडलाइन के लिए फायर होते हैं, फिर नवीनीकरण/समाप्ति तिथि के लिए दूसरे। एक अनुबंध चुनें और मालिक की तरह कुछ न करके देखें कि एस्केलेशन बैकअप ओनर तक पहुँचता है और तब तक चलता है जब तक कोई कार्रवाई न करे।

फिर अनुमोदनों को end-to-end टेस्ट करें। एक अनुबंध को अनुमोदन पथ से और दूसरे को रिजेक्शन पथ से चलाएँ। पुष्टि करें कि ऑडिट ट्रेल रिकॉर्ड करता है किसने, कब और क्यों निर्णय लिया। अगर आपके लॉग 10 सेकंड में "क्या हुआ?" का जवाब नहीं दे पाते, तो वे तंग डेडलाइनों पर मदद नहीं करेंगे।

अगले कदम

छोटे से शुरू करें, और केवल तभी बढ़ाएँ जब बेसिक्स बोरिंग लगने लगें:

• पहले एक न्यूनतम वर्शन बनाएं: कोर एंटिटीज, स्पष्ट स्टेटस, और दो रिमाइंडर (उदा., फर्स्ट नोटिस और फाइनल नोटिस)।
• रिमाइंडर भरोसेमंद होने के बाद ही अनुमोदन जोड़ें।
• स्वामित्व को अनिवार्य रखें: हर अनुबंध पर एक मालिक और बैकअप मालिक चाहिए।
• एक टीम के साथ दो सप्ताह के लिए पायलट करें, फिर रिमाइंडर समय और एस्केलेशन रोल समायोजित करें।

अगर आप इसे बिना कोड लिखे एक आंतरिक ऑपरेशनल ऐप के रूप में बनाना चाहते हैं, तो AppMaster (appmaster.io) एक विकल्प है मॉडलिंग, अनुमोदन वर्कफ़्लोज़ बनाने, और कई चैनलों पर नोटिफिकेशन भेजने के लिए।

इन जाँचों के पास होने के बाद, आपका नवीनीकरण ट्रैकर असली अनुबंधों के लिए तैयार है, सिर्फ़ हैप्पी-पाथ डेमो के लिए नहीं।