Vendor Renewal Calendar Template for Small Teams
One page. Every renewal you pay for, every notice window, every decision gate — so renewals become decisions instead of invoices that arrive too late to argue with.
Renewals are the only operational risk that arrives with a dollar amount pre-attached. The pattern is always the same: a tool bought in a busy month by a person who has since left, on a card nobody watches, auto-renews at list price for a seat count that was true eighteen months ago. The contract had a 30-day cancellation window; the invoice arrives 45 days after it closed. Nothing about that is a technology problem — it is a calendar problem. A small team does not need procurement software; it needs one table with every vendor, the real renewal date, the notice window that actually cancels it, and a named person who decides at 60 days, not at invoice day. This template is that page. The contracts behind the rows get their terms checked in the vendor contract checklist; the vendors who go get their data out via the offboarding & data-deletion checklist.
The renewal table, one page
| Column | What goes in it | Why it exists |
|---|---|---|
| Vendor + product | One line per product, not per vendor. Vendors sell bundles where you use one of four components — those are three dead lines and one live one. | Kills are per-product. You can't offboard half a vendor if your table only knows the vendor. |
| Annual cost | List price at last renewal, plus the seat count you actually paid for. | You negotiate with last year's number in hand, not with a vague memory of "it was a few hundred." |
| Renewal date | The date the contract renews — which is often not the date the invoice arrives. Check the contract, then the billing portal, then reconcile. | The renewal date is the deadline; the invoice date is a courtesy note about a decision already made. |
| Notice window | Days of written notice required to cancel or downgrade without penalty, and the calendar date that implies (renewal date minus notice days). | "30-day notice" discovered on day 12 before renewal is a full-price year. Precompute the last safe day. |
| Decision owner | One name who decides renew / downgrade / kill. Not a committee, not "whoever notices." | Renewals without owners are renewals by default — the vendor's favorite kind. |
| Usage evidence | Monthly active users, last login of least-active seat, whether the workflow it supports still exists. | The renew/kill decision is arithmetic only when someone collected the numbers beforehand. |
The 90/60/30 pipeline
Every renewal walks the same pipeline, and the calendar shows which stage each one is in:
- T−90 — Evidence. The decision owner pulls usage: seats vs. actual users, logins from the last 90 days, whether the original problem the tool solved still exists. No negotiation happens here; this is just honesty about whether anyone would notice if the tool vanished.
- T−60 — Decision. Renew, downgrade, or kill — decided and written down, one line. This is also the negotiation window: vendors discount hardest when cancellation is still cheap for you. A renewal conversation at T−60 has leverage; the same conversation at T−5 has none.
- T−30 — Execute. Signed, downgraded, or cancelled in writing (and the cancellation confirmed, not assumed — save the confirmation). Anything killed starts the offboarding clock.
- T−0 — Invoice audit. Compare the invoice to the table: same price? same seats? same term? Silent price increases and seat creep are caught here, in the one month they can still be disputed.
The auto-renew kill list
Some renewals should be re-decided every single year, by policy, because they are the ones that grow in the dark: month-to-month tools that quietly became annual; "trial" accounts that converted two restructurings ago; the security product bought during the incident that is now duplicated by the tool the platform vendor added free; the marketing tool whose champion left; anything billed to a personal card (if you find one of these, kill it this quarter — it is also how a departed employee holds a key to your data). The kill list is not a punishment for the tools on it. It is a statement that renewal is a decision, not a default. The tool that survives its kill-list review for three straight years is the one you actually needed.
Seat trueing before you sign
Seat-based contracts drift upward in only one direction. Before any seat-based renewal: count provisioned seats, count active users in the last 30 days, count the two different numbers and reconcile the gap. The gap is always people who left, accounts for departed staff that nobody reclaimed (which is also an access-review finding, not just a budget one), and "just in case" seats nobody can justify. Downgrade to the true number at renewal — vendors rarely pro-rate mid-term, but they almost always accept a lower seat count at the renewal line. A twelve-person firm that does this once usually finds 10–20% of its SaaS spend was paying for former employees.
Four metrics that tell you if the calendar is real
- Renewals caught with ≥30 days of notice — the pipeline metric. Below 90% means new purchases are not entering the table, which is how the next silent renewal is already scheduled.
- Spend cut at renewals — dollars downgraded or killed, per quarter. A healthy quarter is non-zero; a zero quarter usually means the evidence step is being skipped, not that every tool is perfectly sized.
- Orphans killed — products with zero logins in 90 days that got terminated instead of renewed. Track the cumulative number; it is the cleanest proof the table is real.
- Invoices that matched the table — price, seats, and term all as agreed. Mismatches here are disputes you can still win; mismatches noticed next quarter are donations.
Worked example: the twelve-person firm with $14k of drift
A twelve-person professional-services firm ran this as a one-afternoon project after an auto-renewal doubled their project-management tool's price at a seat count of 22 (they employed twelve, had provisioned 31, and nobody knew why). The table took two hours: 23 lines, of which 17 were real. Findings from the first pass: a $2,400/yr analytics tool whose champion had left 14 months earlier (killed at T−60 with no usage in the window), two overlapping password tools bought in different busy seasons (one killed, one kept as the password manager), a security product duplicated by features their platform vendor had since bundled free (downgraded at renewal), and 9 seats cut across three tools to match actual logins. Net result on the first cycle: $14,100/yr cut, every remaining contract has a named owner and a computed last-safe-cancellation date, and the quarterly 30-minute calendar review has found two more orphans since. Nothing about their tools got worse — they simply stopped paying for the ones nobody would have noticed losing.
Where this fits
The contract terms each line hides live in the vendor contract checklist; who to call at 2 a.m. is the vendor incident contacts one-pager; the escalation order when a vendor stalls is the escalation ladder; and the exit that follows a kill decision is the offboarding & data-deletion checklist. The sprawl that puts vendors on this table in the first place is measured by the SaaS sprawl audit, and the security side of keeping a vendor is the vendor security review. If you would rather have the whole loop — the audit that finds the gaps, the plan that closes them — run by an outside pair, that is the Small-Team Ops Audit ($149, five-day turnaround), and it reads your vendor spend as part of the audit; when a vendor outage is the scenario that worries you most, the Custom Incident Runbook ($249, delivered in 48h) turns it into a procedure. The Ops Starter Kit ($14) covers the incident half; Vol. 2 ($27) covers the on-call rotation; and the free First 30 Minutes quick-start covers the first half-hour after any vendor breaks.