ਵਿਕਰੇਤਾ ਠੇਕਿਆਂ ਦੀ ਮਿਆਦ ਟ੍ਰੈਕ ਕਰਨ ਲਈ ਵੈੱਬ ਐਪ ਬਣਾਓ

ਇੱਕ Contract Expiration Tracker ਨੂੰ ਕੀ ਹੱਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਇਕ contract expiration tracker "ਅਚਾਨਕ ਨਵੀਨੀਕਰਨ" ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ, ਨੋਟੀਸ ਵਿਂਡੋ ਗੁਆਉਣਾਂ ਅਤੇ ਆਖ਼ਰੀ ਪਲ ਦੇ ਹੰਗਾਮਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਹੁੰਦਾ ਹੈ—ਜਦੋਂ ਇਨਸਾਈਟ ਜਾਂ signed PDF ਕਿਸੇ ਦੇ ਇਨਬੌਕਸ ਵਿੱਚ ਚੁੱਕੀ ਹੋਵੇ।

ਉਹ ਸਮੱਸਿਆਵਾਂ ਜੋ ਇਸਨੂੰ ਦੂਰ ਕਰਨੀ ਚਾਹੀਦੀਆਂ ਹਨ

ਜ਼ਿਆਦातर ਟੀਮਾਂ ਉਹੀ ਫੇਲਯੋਰ ਮੋਡਾਂ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ:

• ਨਵੀਨੀਕਰਨ ਅਤੇ ਨੋਟੀਸ ਪੀਰੀਅਡ ਗੁਆਉਣਾ: ਕਈ contracts 30–90 ਦਿਨ ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ। ਜੇ ਉਹ ਤਾਰੀਖ ਲੰਘ ਜਾਵੇ, ਤੁਸੀਂ ਫਸ ਜਾਂਦੇ ਹੋ।
• ਆਟੋ‑ਰੀਨਿਊ ਧਾਰਾਵਾਂ: ਸੌਂਪੀਆਂ ਗਈਆਂ ਸੰਮਤੀਆਂ ਅਗਲੇ ਟਰਮ ਲਈ ਚੁੱਪਚਾਪ ਰੀਨਿਊ ਹੋ ਜਾਦੀਆਂ ਹਨ, ਕਦੇ‑ਕਦੇ ਕੀਮਤ ਵਾਧੇ ਨਾਲ।
• ਫਾਇਲਾਂ ਫੈਲੀ ਹੋਈਆਂ ਅਤੇ ਅਸਪਸ਼ਟ ਸ਼ਰਤਾਂ: signed ਪ੍ਰਤੀ ਲੱਭਣ ਵਿੱਚ ਮੁਸ਼ਕਲ, ंਆਮੀਨਡਮੈਂਟ ਵੱਖਰੇ ਸਥਾਨ 'ਤੇ, ਅਤੇ ਕੋਈ ਪਤਾ ਨਹੀਂ ਕਿ ਕਿਹੜੀਆਂ ਤਾਰਿਖਾਂ ਬਿੰਧਕ ਹਨ।

ਇਹ ਕੌਣ ਵਰਤੇਗਾ (ਅਤੇ ਕਿਉਂ)

ਇੱਕ ਯੂਜ਼ਫੁਲ ਟ੍ਰੈਕਰ ਵੱਖ‑ਵੱਖ ਭੂਮਿਕਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ contract ਵਿਸ਼ੇਸ਼ਜ ਓ ਬਣਾਉਣ ਦੀ ਸ਼ਰਤ ਰੱਖੇ:

• Procurement ਨੂੰ ਨਵੀਨੀਕਰਨ ਦਰਸ਼ਤਾ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਮਦਦ ਤੇਸ਼ਦੀ ਨਾਲ ਮोल‑ਤੋਲ ਕਰ ਸਕੇ ਅਤੇ vendor ਖ਼ਰਚ ਨੂੰ ਮੈਨੇਜ ਕਰ ਸਕੇ।
• Legal ਨੂੰ تازਾ executed agreement, ਮੁੱਖ ਧਾਰਾਵਾਂ ਅਤੇ amendments ਤੱਕ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ।
• Finance ਨੂੰ ਪੇਸ਼ਗੀ ਭਵਿੱਖਬਾਣੀ ਅਤੇ ਭੁਗਤਾਨ ਸ਼ਰਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਚਾਹੀਦੀ ਹੈ।
• Department owners (IT, Marketing, HR ਆਦਿ) ਨੂੰ ਰਿਮਾਈਂਡਰ ਅਤੇ ਸੰਦਰਭ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਉਹ ਫ਼ੈਸਲਾ ਕਰ ਸਕਣ: ਨਵੀਨੀਕਰਨ, ਮੁੜਚਰਚਾ, ਜਾਂ ਰੱਦ।

ਹਾਸਲ ਕਰਨ ਵਾਲੇ ਨਤੀਜੇ

ਜਦੋਂ ਟ੍ਰੈਕਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਬਣਾਉਂਦਾ ਹੈ:

• ਘੱਟ ਅਚਾਨਕ ਘਟਨਾਵਾਂ (ਚੁਪਚਾਪ ਨਵੀਨੀਕਰਨ ਨਹੀਂ)
• ਵਧੀਆ ਮੋਲ‑ਤੋਲ ਸਮਾਂ (ਨੋਟੀਸ ਡੇਡਲਾਈਨ ਤੋਂ ਪਹਿਲਾਂ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰੋ)
• ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ (ਹਰ contract ਦਾ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਅਤੇ ਬੈਕਅੱਪ ਹੋਵੇ)

ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਟਰੈਕ ਕਰਨ ਯੋਗ ਸਫਲਤਾ ਮੈਟ੍ਰਿਕਸ

ਉਪਯੋਗਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦਿਖਾਉਣ ਵਾਲੇ ਮਾਪ ਯੋਜਨਾ ਕਰੋ:

• % contracts ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਨਿਯੁਕਤ ਮਾਲਕ ਦਿੱਤਾ ਹੋਇਆ ਹੈ (ਅਤੇ ਵਿਭਾਗ)
• ਰਿਮਾਈਂਡਰ ਡਿਲਿਵਰੀ ਰੇਟ (ਭੇਜੇ ਗਏ ਵਿਰੁੱਧ bounced/failed) ਈਮੇਲ ਅਤੇ Slack 'ਤੇ
• ਸਮੇਂ 'ਤੇ ਨਵੀਨੀਕਰਨ ਫੈਸਲੇ (ਫੈਸਲੇ ਨੋਟੀਸ ਤਾਰੀਖ ਤੋਂ ਪਹਿਲਾਂ ਲੌਗ ਕੀਤੇ)
• % contracts ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮੁੱਖ ਤਾਰਿਖਾਂ ਭਰੀਆਂ ਗਈਆਂ (end date, notice date, renewal term)

ਜੇ ਤੁਹਾਡਾ MVP ਇਹ ਲਗਾਤਾਰ ਹੱਲ ਕਰ ਸਕੇ ਤਾਂ ਤੁਸੀਂ ਸਭ ਤੋਂ ਮਹਿੰਗੀਆਂ ਠੇਕਿਆਂ ਦੀਆਂ ਗਲਤੀਆਂ ਰੋਕ ਲੈਵੋਗੇ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਹੋਰ ਉन्नਤ ਫੀਚਰ ਜੋੜੋ।

MVP ਦਾ ਦਾਇਰਾ ਅਤੇ ਫੀਚਰ ਚੈੱਕਲਿਸਟ

ਇੱਕ MVP contract expiration tracker ਨੂੰ ਇੱਕ لحظه ਵਿੱਚ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: “ਕੀ ਜਲਦੀ ਖਤਮ ਹੋ ਰਿਹਾ ਹੈ, ਇਸਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ?” v1 ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਜਾਰੀ ਕੀਤਾ ਜਾ ਸਕੇ, ਫਿਰ ਅਸਲੀ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵਧਾਓ।

ਜੇ ਤੁਸੀਂ ਪਹਿਲੇ ਦਿਨ ਪੂਰਾ ਕਸਟਮ ਸਟੈਕ ਬਣਾਉਣ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ vibe‑coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਚੈਟ‑ਆਧਾਰਿਤ spec ਤੋਂ ਮੁੱਖ ਸਕਰੀਨਾਂ ਅਤੇ ਰਿਮਾਈਂਡਰ ਫਲੋ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਅਤੇ ਜਦੋਂ ਤੂੰ operationalize ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਵੋਗੇ, ਤਦ ਵਾਸਤਵਿਕ, ਨਿਰਯਾਤਯੋਗ ਸਰੋਤ ਕੋਡ ਵੀ ਉਤਪੰਨ ਕਰੇਗਾ।

ਮੁੱਖ MVP ਫੀਚਰ (ਜਰੂਰੀ)

• Contract ਸੂਚੀ: vendor ਨਾਮ, contract ਨਾਮ/ID, ਸ਼ੁਰੂ ਤਾਰੀਖ, ਅੰਤ ਤਾਰੀਖ, ਅਤੇ ਸਥਿਤੀ (Active/Expired)
• Owner ਫੀਲਡ (ਜਿੰਨ੍ਹਾਂ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ), ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਬੈਕਅੱਪ ਮਾਲਕ
• ਰਿਮਾਈਂਡਰ ਸ਼ੈਡਿਊਲ ਜੋ expiration date ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ (ਉਦਾਹਰਨ: 90/60/30/7 ਦਿਨ), ਇੱਕ ਸਪੱਸ਼ਟ “ਅਗਲਾ ਰਿਮਾਈਂਡਰ” ਦਰਸਾਉਣ ਵਾਲਾ ਇੰਡਿਕੇਟਰ
• ਸਾਦਾ search ਅਤੇ filters: vendor, ਮਾਲਕ, “X ਦਿਨਾਂ ਵਿੱਚ ਖਤਮ ਹੋ ਰਿਹਾ”, ਅਤੇ ਸਥਿਤੀ
• ਸਧਾਰਨ contract ਵਿਸਥਾਰ ਪੰਨਾ: ਮੁੱਖ ਤਾਰਿਖਾਂ, renewal ਕਿਸਮ (auto/manual), ਨੋਟ, ਅਤੇ ਲੱਗੇ ਦਸਤਾਵੇਜ਼ ਲਈ ਲਿੰਕ

ਵਧੀਆ ਹੋਣ ਵਾਲੀਆਂ ਫੀਚਰਾਂ (v1 ਤੋਂ ਬਾਅਦ ਜੋੜੋ)

• ਧਾਰਾ tagging ਅਤੇ ਸੰਰਚਿਤ ਮੈਟਾ‑ਡੇਟਾ (ਉਦਾਹਰਨ: “termination”, “price increase”, “data processing”)
• E-signature ਅਤੇ ਸੋర్స ਲਿੰਕ (DocuSign/Dropbox/Drive URL) ਤਾਂ ਜੋ ਟੀਮਾਂ ਅਸਾਨੀ ਨਾਲ ਮੂਲ ਵਰਕਫਲੋ ਤੇ ਜਾ ਸਕਣ
• Vendor scorecards (renewal risk, performance notes) ਨਵੀਨੀਕਰਨ ਫੈਸਲਿਆਂ ਨੂੰ ਸਹਾਇਤਾ ਦੇਣ ਲਈ

v1 ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਬਾਹਰਨੂੰ ਰੱਖਿਆ ਗਿਆ

ਪਰੋਜੈਕਟ ਨੂੰ ਪੂਰੇ contract lifecycle management ਸਿਸਟਮ ਵਿੱਚ ਤਬਦੀਲ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਇਹਨਾਂ ਨੂੰ v1 'ਚ ਨਾ ਜੋੜੋ:

• ਬਹੁ‑ਕਦਮੀ approvals ਅਤੇ legal review ਵਰਕਫਲੋ
• ਨੈਗੋਸ਼ੀਏਸ਼ਨ redlining ਟੂਲ
• ਜਟਿਲ obligations ਮੈਨੇਜਮੈਂਟ (deliverables, SLAs) ਬਿਹਤਰ ਨੋਟ ਤੋਂ ਅੱਗੇ ਨਹੀਂ

ਭੂਮਿਕਾ ਅਨੁਸਾਰ ਸਧਾਰਨ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼

Contract Owner: “ਮੈਂ ਆਪਣੇ ਜਲਦੀ ਖਤਮ ਹੋਣ ਵਾਲੇ contracts ਵੇਖ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਅਤੇ ਕਾਫੀ ਅੱਗੇ ਰਿਮਾਈਂਡਰ ਮਿਲਦੇ ਹਨ ਤਾਂ ਕਿ ਮੈਂ ਮੋਲ‑ਤੋਲ ਕਰ ਸਕਾਂ।”

Procurement/Admin: “ਮੈਂ contracts ਜੋੜ/ਸੋਧ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਅਤੇ ਮਾਲਕ ਨਿਯੁਕਤ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਤਾਂ ਕਿ ਕੁਝ ਵੀ ਅਣਨਿਯੁਕਤ ਨਾ ਰਹੇ।”

Finance/Leadership (read-only): “ਮੈਂ ਆਉਂਦੇ ਨਵੀਨੀਕਰਨ ਵੇਖ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ ਤਾਂ ਕਿ ਖ਼ਰਚ ਪੂਰਨ ਤਰੀਕੇ ਨਾਲ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ ਜਾ ਸਕੇ ਅਤੇ ਅਚਾਨਕ ਆਟੋ‑ਰੀਨਿਊਜ਼ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ।”

ਜੇ ਤੁਸੀਂ ਇਹ ਕਹਾਣੀਆਂ ਸਾਫ਼ ਸਕਰੀਨਾਂ ਅਤੇ ਨਿਰਭਰਯੋਗ ਰਿਮਾਈਂਡਰਾਂ ਨਾਲ ਪੂਰੀਆਂ ਕਰ ਸਕੋ ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇਕ ਮਜ਼ਬੂਤ MVP ਹੋਵੇਗਾ।

ਡੇਟਾ ਮਾਡਲ: Vendors, Contracts, Terms, ਅਤੇ ਤਾਰਿਖਾਂ

ਇਕ contract tracker ਉਸ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕੈਪਚਰ ਕਰਦੇ ਹੋ। ਜੇ ਮਾਡਲ ਬਹੁਤ patla ਹੋਵੇ ਤਾਂ ਰਿਮਾਈਂਡਰ ਗ਼ਲਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਜੇ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋਵੇ ਤਾਂ ਲੋਕ ਜਾਣਕਾਰੀ ਦਰਜ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। 90% ਮਾਮਲਿਆਂ ਕਵਰ ਕਰਨ ਲਈ “core record + ਕੁਝ ਸੰਰਚਿਤ ਫੀਲਡ” ਲੱਭੋ।

ਕੋਰ ਐਨਟੀਟੀਆਂ

Vendor ਉਹ ਕੰਪਨੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ। ਬੇਸਿਕ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਖੋਜ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਕਰੋਂਗੇ: ਕਾਨੂੰਨੀ ਨਾਮ, display name, vendor ਪ੍ਰਕਾਰ (software, facilities, agency), ਅਤੇ ਅੰਦਰੂਨੀ vendor ID ਜੇ ਹੋਵੇ।

Contract ਉਹ ਸਹਿਮਤੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰ ਰਹੇ ਹੋ। ਇੱਕ vendor ਦੇ ਕਈ contracts ਹੋ ਸਕਦੇ ਹਨ (ਉਦਾਹਰਨ: licensing ਅਤੇ support ਲਈ ਵੱਖਰੇ agreements), ਇਸ ਲਈ Contract ਨੂੰ Vendor ਨਾਲ ਲਿੰਕ ਕੀਤਾ ਵੱਖਰਾ ਰਿਕਾਰਡ ਰੱਖੋ।

Ownership ਅਤੇ contacts

ਹਰ contract ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ contract owner (renewal ਫੈਸਲਿਆਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ) ਅਤੇ ਇੱਕ ਬੈਕਅੱਪ owner ਚਾਹੀਦਾ ਹੈ ਜੇ ਛੁੱਟੀਆਂ ਜਾਂ ਟਰਨਓਵਰ ਹੋਵੇ। ਇਹਨਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਫੀਲਡ ਮੰਨੋ।

ਮੁੱਖ contacts ਵੀ ਕੈਪਚਰ ਕਰੋ:

• Vendor rep ਨਾਮ/ਈ‑ਮੇਲ
• ਆੰਤਰਿਕ stakeholders (ਵਿਕਲਪਕ)

ਸ਼ਰਤਾਂ ਅਤੇ ਅਹਮ ਤਾਰਿਖਾਂ

ਜ਼ਿਆਦਾਤਰ ਐਪ “start” ਅਤੇ “end” ਤਾਰੀਖਾਂ ਸਟੋਰ ਕਰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਹੈਰਾਨ ਰਹਿ ਜਾਂਦੇ ਹਨ ਕਿ ਨਵੀਨੀਕਰਨ ਗੁਆਉਣਾ ਕਿਉਂ ਹੋਇਆ। ਕਈ ਤਾਰਿਖਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਟਰੈਕ ਕਰੋ:

• Start date (ਜਦੋਂ ਟਰਮ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ)
• End date (ਜਦੋਂ ਸੇਵਾ ਰੋਕ ਦਿੱਤੀ ਜਾਏਗੀ ਜੇ ਨਵੀਨਤਕਰਨ ਨਾ ਹੋਵੇ)
• Notice deadline (ਨੋਟੀਸ ਦੇਣ ਦੀ ਆਖਰੀ ਤਾਰੀਖ)
• Renewal/next term date (ਅਗਲਾ ਅਵਧੀ ਕਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ)

Auto‑renew ਅਤੇ month‑to‑month ਨਿਯਮ

ਆਮ renewal ਪੈਟਰਨਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਕੁਝ ਸੰਰਚਿਤ ਫੀਲਡ ਜੋੜੋ:

• Renewal type: fixed-term, auto-renew, month-to-month
• Renewal period: ਉਦਾਹਰਨ 12 months, 1 month
• Auto-renew enabled: yes/no

ਜੇ month-to-month ਹੋਵੇ ਤਾਂ “end date” ਅਣਜਾਣ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਰਿਮਾਈਂਡਰਾਂ ਨੂੰ notice deadline rules (ਉਦਾਹਰਨ: “ਅਗਲੇ ਬਿਲਿੰਗ ਸਾਈਕਲ ਤੋਂ 30 ਦਿਨ ਪਹਿਲਾਂ ਸੂਚਿਤ ਕਰੋ”) 'ਤੇ ਚਲਾਉ।

ਹਰ Contract ਲਈ ਸਥਿਤੀ ਨਿਯਮ ਅਤੇ ਲਾਈਫਸਾਈਕਲ

Statuses ਸਿਰਫ਼ ਲੇਬਲ ਨਹੀਂ ਹਨ—ਉਹ ਤੁਹਾਡੇ ਡੈਸ਼ਬੋਰਡ ਗਿਣਤੀ, ਰਿਮਾਈਂਡਰ ਸ਼ੈਡਿਊਲ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਦਾ ਲਾਜ਼ਿਕ ਚਲਾਉਂਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਸਧਾਰਨ ਰੱਖੋ ਅਤੇ ਹਰ vendor agreement 'ਤੇ ਇੱਕਸਾਰ ਬਣਾਓ।

ਕੋਰ ਸਥਿਤੀਆਂ (ਇਨ੍ਹਾਂ ਨੂੰ ਪਰਸਪਰ ਵਿਲੱਖਣ ਰੱਖੋ)

MVP ਲਈ ਇੱਕ ਵਿਹੰਗਮ ਸਮੂਹ:

• Active: Contract ਲਾਗੂ ਹੈ ਅਤੇ “Expiring Soon” ਵਿਂਡੋ ਦੇ ਅੰਦਰ ਨਹੀਂ।
• Expiring Soon: Contract ਹਜੇ ਭੀ active ਹੈ, ਪਰ ਨਵੀਨੀਕਰਨ ਕਾਰਵਾਈ ਨੇੜੇ ਆ ਰਹੀ ਹੈ।
• Renewed: ਨਵਾਂ ਟਰਮ ਲਾਗੂ ਹੋ ਚੁੱਕਿਆ ਹੈ (ਅਕਸਰ ਨਵੇਂ contract ਰਿਕਾਰਡ ਜਾਂ ਨਵੇਂ ਵਰਜ਼ਨ/ਟਰਮ ਨਾਲ ਲਿੰਕ)
• Terminated: Contract ਅਰਥਾਤ ਸੰਕਲਪਤ ਤੌਰ 'ਤੇ ਖਤਮ ਕੀਤੀ ਗਈ ਜਾਂ ਨੈਚਰਲ end date ਤੋਂ ਪਹਿਲਾਂ ਖਤਮ ਕੀਤੀ ਗਈ।
• Archived: ਇਤਿਹਾਸਕ ਰਿਕਾਰਡ ਜੋ ਹੁਣ ਰਿਮਾਈਂਡਰ ਨਹੀਂ ਜਨਰੇਟ ਕਰਨਾ ਚਾਹੀਦਾ (ਆਮ ਤੌਰ 'ਤੇ renewal ਮੁਕੰਮਲ ਹੋਣ ਜਾਂ termination ਤੋਂ ਬਹੁਤ ਬਾਅਦ)।

“Expiring Soon” ਨੂੰ ਸਪਸ਼ਟ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਲੋਕਾਂ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ “ਜਲਦੀ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਆਮ ਓਪਸ਼ਨ ਹਨ 30/60/90 ਦਿਨ ਅਗਲੇ ਪ੍ਰਭਾਵਸ਼ੀਲ ਅੰਤ ਤਾਰੀਖ ਤੋਂ ਪਹਿਲਾਂ। ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪ੍ਰਤੀ ਸੰਸਥਾ (ਜਾਂ contract ਕਿਸਮ) ਲਈ ਸੰਰਚਣਯੋਗ ਬਣਾਓ ਤਾਂ ਕਿ ਟੂਲ ਵੱਖਰੇ procurement ਰਿਥਮਾਂ ਨੂੰ ਫਿੱਟ ਕਰੇ।

ਜੇ end date ਬਦਲਦੀ ਹੈ ਤਾਂ ਸਥਿਤੀ ਆਪੋਆਪ ਰੀਕੈਲਕੁਲੇਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਕਿ "Expiring Soon" ਫਲੈਗ ਪੁਰਾਣਾ ਨਾ ਰਹੇ।

ਸੁਧਾਰ ਰਿਪੋਰਟਿੰਗ ਲਈ ਕਾਰਨ ਕੋੱਡ

ਜਦੋਂ contract Terminated ਜਾਂ Archived 'ਚ ਜਾਵੇ, ਤਾਂ ਇੱਕ ਕਾਰਨ ਕੋਡ ਦੀ ਲੋੜ ਰੱਖੋ ਜਿਵੇਂ:

• Canceled
• Replaced (ਕਿਸੇ ਹੋਰ agreement ਨਾਲ ਬਦਲਿਆ ਗਿਆ)
• Vendor merge (counterparty ਬਦਲਿਆ ਗਿਆ)
• Non-renewal

ਇਹ ਕਾਰਨ ਤਿਮਾਹੀ ਰਿਪੋਰਟਿੰਗ ਅਤੇ vendor risk review ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।

ਹਰ ਸਥਿਤੀ ਬਦਲਾਅ ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ (ਆਡੀਟ‑ਮਿੱਤਰ)

ਸਥਿਤੀ ਨੂੰ ਇੱਕ ਆਡੀਟਯੋਗ ਫੀਲਡ ਵਜੋਂ ਵਰਤੋਂ। ਲੌਗ ਕਰੋ ਕਿਸ ਨੇ ਬਦਲਿਆ, ਕਦੋਂ, ਅਤੇ ਕੀ ਬਦਲਿਆ (ਪੁਰਾਣੀ ਸਥਿਤੀ → ਨਵੀਂ ਸਥਿਤੀ, ਨਾਲ ਹੀ ਕਾਰਨ ਕੋਡ ਅਤੇ ਵਿਕਲਪਕ ਨੋਟ)। ਇਹ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ ਸਹਾਰੇਗਾ ਅਤੇ ਦੱਸੇਗਾ ਕਿ ਕਿਉਂ ਰਿਮਾਈਂਡਰ ਰੁਕੇ ਜਾਂ ਸਿਲੇ ਜਾ ਰਹੇ ਹਨ।

ਰਿਮਾਈਂਡਰ ਇੰਜਣ ਅਤੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਡਿਜ਼ਾਈਨ

ਇਕ contract tracker तभी ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਲੋਕ ਰਿਮਾਈਂਡਰਾਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ। ਮਕਸਦ “ਵਧੇਰੇ ਨੋਟੀਫਿਕੇਸ਼ਨ” ਨਹੀਂ—ਸਮੇਂ ਬੰਨ੍ਹੇ, ਕਾਰਵਾਈਯੋਗ ਨਜ਼ਦੀਕੀ ਨੋਟਸ ਜੋ ਤੁਹਾਡੇ ਟੀਮ ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਢੰਗ ਨਾਲ ਮਿਲਦੇ ਹਨ।

ਚੈਨਲ ਚੁਣੋ (ਸਧਾਰਨ ਰੱਖੋ)

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਈਮੇਲ ਨੂੰ ਡਿਫ਼ੋਲਟ ਰੱਖੋ: ਇਹ ਸਭ ਲਈ ਹੈ, ਆਸਾਨੀ ਨਾਲ ਆਡੀਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਵੱਧ ਪ੍ਰਸ਼ਾਸਕੀ ਕੰਮ ਨਹੀਂ ਲੈਂਦਾ। ਜਦੋਂ workflow ਸਥਿਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਵਿਕਲਪਕ Slack/Teams ਡਿਲਿਵਰੀ ਸ਼ਾਮਲ ਕਰੋ।

ਯੂਜ਼ਰ ਦੀਆਂ (ਜਾਂ ਵਿਭਾਗ ਦੀਆਂ) ਚੈਨਲ ਪਸੰਦਾਂ ਰੱਖੋ ਤਾਂ ਕਿ Finance ਈਮੇਲ 'ਤੇ ਰਹੇ ਜਦੋਂ ਕਿ Procurement ਚੈਟ ਵਿੱਚ ਰਹੇ।

ਰਿਮਾਈਂਡਰ ਸ਼ੈਡਿਊਲ ਜੋ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਰੋਕੇ

ਅੰਤ ਤਾਰੀਖ ਨਾਲ ਜੋੜੀ ਹੋਈ ਪੇਸ਼ਗੋਈਯੋਗ cadence ਵਰਤੋ:

• expiration ਤੋਂ 90 / 60 / 30 / 7 ਦਿਨ

ਇਸ ਤੋਂ ਇਲਾਵਾ ਨੋਟੀਸ ਡੇਡਲਾਈਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਵਰਗ ਦੀ ਸੂਚਨਾ ਜੋ ਉੱਚ ਪ੍ਰਾਥਮਿਕਤਾ ਰੱਖੇ (ਉਦਾਹਰਨ: “ਰੱਦ ਕਰਨ ਲਈ 45 ਦਿਨ ਦੀ ਜ਼ਰੂਰਤ”)। ਇਹ expiration date ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਗੁਆਉਣਾ ਤੁਹਾਨੂੰ ਬਦਲਦੇ ਟਰਮ 'ਚ ਫਸਾ ਸਕਦਾ ਹੈ।

ਰਿਮਾਈਂਡਰ ਕਾਰਵਾਈਯੋਗ ਬਣਾਓ: acknowledge ਅਤੇ snooze

ਹਰ ਨੋਟੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਦੋ ਇੱਕ‑ਕਲਿਕ ਕਾਰਵਾਈਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

• Acknowledge: "ਮੈਂ ਇਸ ਨੂੰ ਵੇਖ ਲਿਆ ਅਤੇ ਮੈਂ ਇਸ ਨੂੰ ਸੰਭਾਲ ਰਿਹਾ ਹਾਂ." ਇਹ ਉਸ ਕਦਮ ਲਈ ਦੁਹਰਾਅ ਰੋਕ ਦਿੰਦਾ ਹੈ।
• Snooze: ਛੋਟੇ, ਨਿਯੰਤ੍ਰਿਤ ਸਮੇਂ ਲਈ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਦੇਰੀ (ਜੈਵਕ 3 ਦਿਨ, 1 ਹਫ਼ਤਾ)

ਕਾਰਵਾਈਆਂ ਨੂੰ ਆਡੀਟ ਟਰੇਲ ਵਿੱਚ ਦਰਜ ਕਰੋ (ਕਿਸ ਨੇ acknowledge ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕੋਈ ਟਿੱਪਣੀ) ਤਾਂ ਕਿ ਫਾਲੋ‑ਅੱਪ ਸਪਸ਼ਟ ਰਹਿਣ।

ਜਦੋਂ ਕੁਝ ਨਾ ਹੋਵੇ ਤਾਂ ਇੰਸਕਲੇਸ਼ਨ

ਜੇ contract owner ਨੇ ਨਿਰਧਾਰਿਤ ਵਿੰਡੋ (ਜਿਵੇਂ 3 ਕਾਰੋਬਾਰੀ ਦਿਨ) ਦੇ ਅੰਦਰ acknowledge ਨਹੀਂ ਕੀਤਾ ਤਾਂ escalation manager ਜਾਂ backup owner ਨੂੰ ਭੇਜੋ। Escalations ਸੀਮਿਤ ਅਤੇ ਸਪਸ਼ਟ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: “ਅਜੇ ਤੱਕ ਕੋਈ ਜਵਾਬ ਨਹੀਂ; ownership ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜਾਂ ਮੁੜ ਨਿਯੁਕਤ ਕਰੋ।”

ਸ਼ੋਰ ਨਿਯੰਤਰਣ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ

ਰਿਮਾਈਂਡਰਾਂ ਨੂੰ duplicate ਨਾ ਕਰੋ (ਇੱਕੋ contract/date ਲਈ ਕੋਈ ਦੁਬਾਰਾ ਸੁਚਨਾ ਨਹੀਂ), quiet hours ਦਾ ਸਤਿਕਾਰ ਕਰੋ, ਅਤੇ ਫੇਲਯੋਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਸੁਨੇਹਾ ਦੇਰ ਨਾਲ ਜਾਂ ਦੋ ਵਾਰ ਆਉਂਦਾ ਹੋਵੇ ਤਾਂ ਵਧੀਆ ਡਿਜ਼ਾਈਨ ਵੀ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

UX ਫਲੋ: ਡੈਸ਼ਬੋਰਡ, ਖੋਜ, ਅਤੇ Contract ਵਿਸਥਾਰ ਪੰਨੇ

ਇਕ contract tracker ਦੀ ਸਫਲਤਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਕੋਈ ਵਿਅਕਤੀ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸਹੀ ਸਹਿਮਤੀ ਲੱਭ ਅਤੇ ਨਵੀਨੀਕਰਨ ਤਾਰੀਖ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਇਸਨੂੰ ਅਪਡੇਟ ਕਰ ਸਕਦਾ ਹੈ। UX ਨੂੰ ਸਭ ਤੋਂ ਅਕਸਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ—ਆਗਲਾ ਕੀ ਹੈ ਦੇਖਣਾ, ਖੋਜ ਕਰਨਾ, ਅਤੇ ਛੋਟੀਆਂ ਸੋਧਾਂ—ਦੇ ਆਲੇ‑ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰੋ।

ਸ਼ਾਮਲ ਕਰਨ ਯੋਗ ਮੁੱਖ ਪੰਨੇ

ਡੈਸ਼ਬੋਰਡ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇ: “ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਜਲਦੀ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ?” ਮੁੱਖ ਰੂਪ ਵਿੱਚ ਆਉਣ ਵਾਲੀਆਂ ਨਵੀਨੀਕਰਨ (ਅਗਲੇ 30/60/90 ਦਿਨ) ਅਤੇ ਕੁਝ KPI (ਉਦਾਹਰਨ: ਇਸ ਮਹੀਨੇ ਖਤਮ ਹੋਣ ਵਾਲੇ, ਆਟੋ‑ਰੀਨਿਊ ਜਲਦੀ, ਗੁੰਮ ਦਸਤਾਵੇਜ਼) ਦਿਖਾਓ। ਦੋ ਮੁੱਖ ਵਿਊਜ਼ ਦਿਓ:

• ਟੇਬਲ ਵਿਊ ਸਕੈਨਿੰਗ ਅਤੇ ਬਲਕ ਕਾਰਵਾਈਆਂ ਲਈ (expiration, owner, vendor ਨਾਲ sort)
• ਕੈਲੇਂਡਰ ਵਿਊ ("renewal calendar") ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਦੁਹਰਾਅ ਨਿਯਮਾਂ ਲਈ

Contract Detail "single source of truth" ਹੈ। ਅੱਗੇ ਰੱਖੋ: vendor, status, expiration date, renewal terms, owner, ਅਤੇ notification settings। ਸਹਾਇਕ ਆਈਟਮ ਹੇਠਾਂ ਰੱਖੋ: ਨੋਟ, ਟੈਗ, ਲਿੰਕ ਕੀਤੀਆਂ ਦਸਤਾਵੇਜ਼ਾਂ, ਅਤੇ ਸੰਬੰਧਿਤ contacts।

Vendor Detail ਇਕ vendor ਨਾਲ ਜੁੜੀਆਂ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਇਕੱਠੇ ਦਿਖਾਉਂਦਾ ਹੈ: active contracts, historical contracts, ਮੁੱਖ contacts, ਅਤੇ renewal ਪੈਟਰਨ। ਇੱਥੇ ਯੂਜ਼ਰ ਜਵਾਬ ਦਿੰਦੇ ਹਨ “ਅਸੀਂ ਇਸ ਤੋਂ ਹੋਰ ਕੀ ਖਰੀਦਦੇ ਹਾਂ?”

Settings ਨੂੰ ਨਿਰੇ ਰੱਖੋ: notification defaults, roles, Slack/ਈਮੇਲ ਕਨੈਕਸ਼ਨ, ਅਤੇ standard tags/statuses।

Search, filters, ਅਤੇ saved views

ਖੋਜ ਹਰ ਜਗ੍ਹਾ ਉਪਲਬਧ ਰੱਖੋ। vendor, owner, status, date range, ਅਤੇ tag ਦੇ ਨਾਲ ਫਿਲਟਰਿੰਗ ਸਹਾਇਤ ਕਰੋ। ਡੈਸ਼ਬੋਰਡ 'ਤੇ "quick filters" ਦਿਓ (ਉਦਾਹਰਨ: “Auto‑renew in 14 days,” “Missing owner,” “Draft”)। ਜੇ ਯੂਜ਼ਰ ਇੱਕੋ ਹੀ ਫਿਲਟਰ ਵਾਰੰ ਵਾਪਰਦੇ ਹਨ ਤਾਂ saved views ਦੀ ਆਗਿਆ ਦਿਓ ਜਿਵੇਂ “My renewals” ਜਾਂ “Finance approvals।”

ਤੇਜ਼ ਅਪਡੇਟ ਲਈ ਡਿਜ਼ਾਈਨ

ਜ਼ਿਆਦਾਤਰ ਸੋਧ ਛੋਟੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਟੇਬਲ ਅਤੇ contract detail ਪੰਨੇ ਦੇ ਸਿਖਰ 'ਚ expiration date, owner, ਅਤੇ status ਲਈ inline editing ਵਰਤੋ। ਸੋਧਾਂ ਨੂੰ ਸੁਖੜੀ ਫੀਡਬੈਕ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਗਲਤੀ ਨਾਲ ਹੋਏ ਸੋਧ ਲਈ "Undo" ਵਿਕਲਪ ਰੱਖੋ।

ਨੈਵੀਗੇਸ਼ਨ ਸਧਾਰਨ ਰੱਖੋ: ਡੈਸ਼ਬੋਰਡ → ਖੋਜ ਨਤੀਜੇ → contract detail, ਸਾਫ਼ back path ਅਤੇ persistent filters ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਕਨਟੈਕਸਟ ਨਾ ਖੋਵੇ।

ਦਸਤਾਵੇਜ਼ ਸਟੋਰੇਜ ਅਤੇ ਵਰਜ਼ਨ ਕੰਟਰੋਲ

ਕਾਗਜ਼ਾਤ ਬਿਨਾਂ ਟ੍ਰੈਕਰ ਅਧੂਰਾ ਹੈ। ਕੀ ਪੇਪਰਵਰਕ ਤਾਰਿਖਾਂ ਦੇ ਬਗੈਰ ਖੋ ਜਾਦਾ ਹੈ ਉਸ ਸਮੇਂ ਸੇਵਾ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ—ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਮੁੱਖ ਤਾਰੀਖਾਂ ਦੇ ਨਾਲ ਰੱਖਣਾ ਇਹ ਸਮੱਸਿਆ ਦੂਰ ਕਰਦਾ ਹੈ।

ਕੀ ਅਪਲੋਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਕਿਉਂ)

ਮੁੱਢਲੀ ਫਾਈਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋਕ ਅਸਲ ਵਿੱਚ ਲੋੜ ਪਾਉਂਦੇ ਹਨ:

• Signed agreement PDF (ਅਸਲ ਸੋਰਸ)
• Amendments ਅਤੇ addenda (ਅਕਸਰ ਕੀਮਤ, ਟਰਮ ਲੰਬਾਈ, ਜਾਂ ਨੋਟੀਸ ਪੀਰੀਅਡ ਨੂੰ ਬਦਲਦੇ ਹਨ)
• Renewal ਜਾਂ termination emails/letters (ਨੋਟੀਸ ਅਤੇ ਸਮਾਂ ਦਾ ਪ੍ਰਮਾਣ)

MVP ਵਿੱਚ uploads ਵਿਕਲਪਕ ਰੱਖੋ, ਪਰ contract detail ਪੰਨਾ 'ਤੇ “missing document” ਸਥਿਤੀ ਸਪਸ਼ਟ ਰੱਖੋ।

ਸਟੋਰੇਜ ਦ੍ਰਿਸ਼ਟੀਕੋਣ: object storage + ਡੇਟਾਬੇਸ ਲਿੰਕ

ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਲਈ ਸਰਲ ਅਤੇ ਭਰੋਸੇਯੋਗ ਵਿਧੀ ਇਹ ਹੈ:

• ਫਾਈਲਾਂ ਨੂੰ object storage (ਜੈਵਿਕ S3‑compatible) 'ਚ ਰੱਖੋ
• ਤੁਹਾਡੇ DB 'ਚ ਸਿਰਫ਼ ਮੈਟਾਡੇਟਾ ਸੇਵ ਕਰੋ: file URL/key, ਅਸਲ ਫਾਈਲ ਨਾਂ, size, content type, checksum, uploaded_by, uploaded_at, ਅਤੇ ਕਿਹੜੇ contract/version ਨਾਲ ਲਿੰਕਡ ਹੈ

ਇਸ ਨਾਲ DB ਛੋਟਾ ਤੇ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ ਅਤੇ object storage ਵੱਡੀਆਂ PDFs ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ।

ਵਰਜ਼ਨਿੰਗ: ਨਵਾਂ ਵਰਜ਼ਨ vs ਪੁਰਾਣੇ ਦਸਤਾਵੇਜ਼

ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਪਰਿਵਰਤਨੀ ਰਿਕਾਰਡ ਮੰਨੋ। ਪੁਰਾਣੀ PDF ਨੂੰ “ਬਦਲਣ” ਦੀ ਥਾਂ, ਨਵਾਂ ਵਰਜ਼ਨ ਅਪਲੋਡ ਕਰੋ ਅਤੇ ਇਸਨੂੰ latest ਮਾਰਕ ਕਰੋ।

ਇੱਕ ਕੈਰਫੁਲ ਮਾਡਲ ਹੋ ਸਕਦਾ ਹੈ:

• document_group (ਉਦਾਹਰਨ: “Master Agreement”)
• document_version (v1, v2, v3…)

contract ਪੰਨੇ 'ਤੇ, ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ latest ਵਰਜ਼ਨ ਦਿਖਾਓ, ਅਤੇ ਪਿਛਲੀਆਂ ਵਰਜ਼ਨਾਂ ਦੀ ਛੋਟੀ ਇਤਿਹਾਸ ਲਿਸਟ ਦਿਖਾਓ (ਕਿਸ ਨੇ ਅਪਲੋਡ ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਇੱਕ ਨੋਟ ਜਿਵੇਂ “Updated renewal clause”)।

ਡਾਊਨਲੋਡ, ਬਦਲਣ ਅਤੇ ਮਿਟਾਉਣ ਲਈ ਅਨੁਮਤੀਆਂ

ਦਸਤਾਵੇਜ਼ ਪਹੁੰਚ role‑based ਅਨੁਸਾਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

• Viewers: ਸਿਰਫ਼ ਡਾਉਨਲੋਡ
• Editors: ਨਵੇਂ ਵਰਜ਼ਨ ਅਪਲੋਡ ਕਰ ਸਕਦੇ ਹਨ (ਅਤੇ ਵਿਕਲਪਕ ਨੋਟ ਜੋੜ ਸਕਦੇ ਹਨ)
• Admins: ਅਨੁਮਤੀਆਂ ਮੈਨੇਜ; ਮਿਟਾਉਣ ਸਿਰਫ਼ ਜੇ ਵੀ ਸੱਚਮੁੱਚ ਲੋੜ ਹੋਵੇ

ਜੇ ਤੁਸੀਂ ਮਿਟਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋ ਤਾਂ “soft delete” (UI ਤੋਂ ਛੁਪਾਓ ਪਰ ਸਟੋਰੇਜ ਵਿੱਚ ਰੱਖੋ) 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਅਤੇ ਹਮੇਸ਼ਾ ਕਾਰਵਾਈਆਂ ਨੂੰ ਆਪਣੇ ਆਡੀਟ ਲਾਗ ਵਿੱਚ ਦਰਜ ਕਰੋ।