SuperAPI AI Directory

contract-renewal-tracker

Office & productivity

View repository

Updated 10-16 01:18

About this skill

Contract Renewal Tracker Skill

The auto-renewal ambush is a calendar failure wearing a legal costume: the contract renews on March 1, but the decision died on January 29 — the 30-day notice deadline nobody tracked (vendor-breakup-email learned this the hard way; this skill prevents needing that lesson). The tracker inventories every contract with the date that matters (notice deadline = renewal date − notice period − decision buffer), alerts at decision-time (not deadline-time — an alert with no time to decide is a countdown to the default), and attaches the renewal ritual: every renewal is a negotiation window and a vendor-comparison-matrix-lite moment, because the rubber-stamp renewal is where pricing quietly ratchets.

What This Skill Produces

  • The inventory — every contract: vendor, cost, term, renewal date, notice period, the computed act-by date, owner
  • The alert system — calendar entries at act-by minus the decision buffer, with owners, in a shared calendar that survives personnel changes
  • The renewal ritual — the decision checklist: usage audit, market check, the renegotiation ask, then renew/renegotiate/exit
  • The negotiation playbook — what the renewal window makes possible (the only time vendor leverage flips to you)

Required Inputs

Ask for these if not provided:

  • The contract population — every recurring agreement: software (subscription-audit finds the small ones), services, leases, insurance, maintenance; the inventory hunt mirrors the subscription hunt at company scale
  • The terms, from the documents — renewal dates and notice periods from the contracts (memory says "sometime in spring"; the contract says "60 days written notice" — the tos-decoder-grade reading of the renewal clauses)
  • The owners — who decides each contract's fate; unowned contracts auto-renew by definition
  • The calendar infrastructure — where alerts live such that they survive the tracker's author leaving (the shared calendar, not the personal one)

Framework: The Tracker Rules

  1. The act-by date is the only date: renewal date − notice period − decision buffer (30 days for simple tools, 90 for anything needing a vendor-comparison-matrix evaluation) = the date on the calendar. Tracking renewal dates instead of act-by dates is the ambush with better documentation.
  2. Alerts carry the decision, not just the date: the calendar entry names the contract, the cost, the owner, and the question ("Renew CRM at $18k? Act by Feb 15; notice by Mar 1; renews Apr 1") — an alert that requires archaeology to act on gets snoozed into the default.
  3. The ritual runs three checks before any renewal: usage (are we using what we pay for? — seat counts and feature audits routinely fund the year's savings) · market (the 30-minute competitive-scan-lite: has the category moved?) · the ask (the renegotiation email — see rule 4). Renew-as-is is a legitimate outcome of the ritual; as a default it's a pricing escalator.
  4. The window is your only leverage: vendors price renewals expecting rubber stamps — the notice window is the one period where "we're evaluating alternatives" is both true-sounding and consequence-bearing. The playbook asks: multi-year for a discount (only where the tool is proven), seat right-sizing, the competitor quote on the table (the-price-pushback dynamics, reversed — you're the client now). Even the ask that fails costs one email.
  5. The tracker survives its author: shared calendar, the inventory in the team's space (spreadsheet-handover-grade documentation), owners named per contract, and the quarterly sweep (new contracts in — the intake rule: no signature without an inventory row — departed owners' contracts reassigned). Auto-renewal ambushes cluster in the quarter after the tracker's owner leaves.

Output Format

Renewal Tracker: [org/team] — [N] contracts, [$X] annual

The Inventory

Contract Cost/yr Renews Notice Act by Owner

The Alert System

[Calendar: act-by minus buffer, per contract · the alert's decision-carrying format · the shared-calendar rule]

The Renewal Ritual

[Usage audit → market check → the renegotiation ask → renew / renegotiate / exit (per vendor-breakup-email)]

The Intake + Survival Rules

[No signature without an inventory row · quarterly sweep · owner-departure reassignment]

Quality Checks

  • Every date came from the contract's actual clause, not memory
  • The calendar carries act-by dates with decision buffers, not renewal dates
  • Every contract has a named owner
  • The ritual's three checks run before any renewal
  • The intake rule and quarterly sweep keep the inventory current

Anti-Patterns

  • Do not track renewal dates — the act-by date is the decision's real deadline
  • Do not alert without the decision context — archaeology-requiring alerts get snoozed into defaults
  • Do not rubber-stamp proven tools — the usage audit and the ask cost minutes and fund budgets
  • Do not keep the tracker personal — the ambushes cluster after the owner leaves
  • Do not sign anything into the void — no inventory row, no signature; the intake rule is the whole system's moat