Catch contracts before they auto-renew

When to use

Every month, on schedule, for every contract in the register that can renew itself: suppliers, software, insurance, rent, maintenance, telecoms. Not for a contract already flagged for a yearly performance review — that is ops.supplier-review-yearly, and this playbook feeds it: a contract trending badly here goes onto that review. Not for insurance policies' coverage review — ops.insurance-review. Not for signing a new contract — ops.purchase-approval covers the spend decision before it exists.

Before you start

• The register exists and each entry has: end date, renewal type, notice period, notice method, spend, relationship owner.
• The notice period and method come from the contract text, not from memory — the agent reads the clause each time.
• The owner has said what "we want out" means per category (price, service, dependency) so the brief can recommend.

What a run requires3

The trail8 steps

1. S1

   Pull the 90-day horizonagent

   List every contract whose renewal date or notice deadline falls within the next 90 days. ⚠ verify compute the notice deadline from each contract's own clause (e.g. "3 months before end of term"), not from a generic default.

   Done when the list is published with, per contract: supplier, end date, notice deadline, notice method, annual spend.

2. S2

   Sweep for unregistered contractsagent

   Ask the relationship owners and check the spend ledger for recurring payments not matched to a register entry.

   Done when every unmatched recurring payment is either added to the register or written down as "known, not a contract" (e.g. utilities).

   ⛔ A subscription paid by card from a company account is a contract; it belongs in the register.

3. S3

   Build the decision briefagent

   Per contract: what it costs, what changed since last year (price, usage, incidents), the options (continue / renegotiate / exit / replace), and a recommendation with the notice deadline marked.

   Done when every contract on the S1 list has a brief.

4. S4

   Decide per contractownerneeds approval · owner

   Approval · S4 · owner — the run stops until a named person records the decision

   Review the briefs in one sitting. Each contract gets exactly one of: continue · renegotiate · exit · replace.

   Done when every contract on the list has a decision, a date and a name next to it.

   ⛔ "Leave it for now" is not a decision; if the owner defers, the agent re-asks at least 14 days before the notice deadline.

5. S5

   Prepare the noticesagent

   For exit and renegotiate decisions: draft the notice in the contract's required form and language, addressed per the contract, with the deadline date stated.

   Done when the draft is ready and shows the required method (e-mail, registered letter, portal) and sender.

6. S6

   Send the noticeagentneeds approval · ownerirreversible

   Approval · S6 · owner — the run stops until a named person records the decision

   Irreversible · S6 — an agent never closes it alone

   The owner approves the final text; the agent sends it by the method the contract requires and keeps proof of dispatch and delivery.

   Done when the proof (receipt, read receipt, portal confirmation, registered-letter number) is stored against the contract.

   ⛔ A notice sent by e-mail when the contract demands registered mail may not stop the renewal — check the clause in S3, not at the post office.

7. S7

   Execute the continue decisionsagent

   For contracts that continue: confirm the new term and price in writing from the supplier; if the price changed without notice, flag it to the owner.

   Done when the register shows the new end date for each continued contract.

8. S8

   Update the register and set the next cycleagent

   Record every outcome, correct notice periods that turned out to differ from the register, and add any contract found in S2. Set the next monthly scan.

   Done when the register's next-review dates match the new end dates, and the run summary (list → decisions → notices) is stored.

Checks — how we know it worked

• Every contract with a deadline in the next 90 days has a decision — count the list against the decisions, read it back.
• Every notice sent has proof of dispatch by the method the contract requires.
• The register's end dates equal what the suppliers confirmed — not what was assumed.
• No recurring payment in the ledger is missing from the register two cycles in a row.

If it goes wrong

What each step leaves behind

1. S1the list is published with, per contract: supplier, end date, notice deadline, notice method, annual spend.
2. S2every unmatched recurring payment is either added to the register or written down as "known, not a contract" (e.g. utilities).
3. S3every contract on the S1 list has a brief.
4. S4every contract on the list has a decision, a date and a name next to it.
5. S5the draft is ready and shows the required method (e-mail, registered letter, portal) and sender.
6. S6the proof (receipt, read receipt, portal confirmation, registered-letter number) is stored against the contract.
7. S7the register shows the new end date for each continued contract.
8. S8the register's next-review dates match the new end dates, and the run summary (list → decisions → notices) is stored.

Evidence to keep

The 90-day list per cycle · the brief per contract · the owner's decision with date and name · notice drafts and dispatch proof · supplier confirmations of new terms · the run summary. A run is trusted when someone who was not there can see, per contract, what was due, what was decided, and what proof exists.

How this playbook improves

After every 6 cycles ask: did anything renew by surprise, and was the miss in the scan (S1), the sweep (S2) or the decision (S4)? How long did the owner take per cycle, and did the briefs get shorter or longer? Did any notice method turn out to be wrong? A new version fixes the step that caused the surprise and says so in its change note; if the sweep keeps finding strays, the fix is in how contracts enter the register, not in this scan.