The renewal alert fired on time and the notice window had already closed

The alert fired exactly when it was configured to fire. It was anchored on the renewal date rather than on the last day notice could validly be given, so on a contract requiring 90 days' notice, a 60-day reminder arrived a month after the window had already shut. Nothing was broken. The system was answering a different question from the one anyone needed answered.

This page is about the alerting arithmetic and the routing around it. What an auto-renewal provision is, and which date it implies, is defined in evergreen clauses and the date that actually matters. Whether a given notice is validly given is a legal question for counsel on the governing law; we build the system that gets the decision in front of a person in time to make it.

Hand-calculate five deadlines before touching the configuration

Do not start from the alert rules. Start from 5 real contracts and prove the gap, because the size and direction of that gap decides which of the causes below you actually have.

1. Pick 5 auto-renewing contracts renewing in the next quarter, deliberately across different templates, business units and counterparties.
2. For each, read the notice clause and hand-calculate the last date notice could validly be served, applying how that clause counts: calendar or business days, not less than or at least, and what happens when counting back from a month-end.
3. Subtract whatever the clause deems for service. If posted notice is deemed received some days after posting, the date it must be sent is earlier than the date it must arrive.
4. Record what the system will alert on, on what date, and to whom, from the live configuration rather than from what anyone believes it does.
5. Compute the lead: alert date minus the send-by date. A negative number is a dead alert. Then ask who has to approve a non-renewal and how long that approval has taken on the last few occasions.

Five contracts is enough. If the lead is negative on 4 of them, the anchor is wrong and no amount of tuning the reminder cadence will help. If the lead is positive but small, the problem is the approval time in step 5, which is a different repair entirely.

Five ways a correctly configured alert still arrives too late

1. It is anchored on the renewal date. The renewal date is the consequence; the notice deadline is the decision point, and they are separated by the whole notice period. Every alert should key on a derived deadline field, not on expiry.
2. The notice period was stored as text and never parsed. Ninety (90) days prior written notice sits in a free-text field, reads correctly to a human, and produces no date. Migration makes this worse rather than better — the population of records that arrive with unusable or empty fields is exactly the problem in migrated contracts arriving with empty metadata.
3. Internal decision time is not modelled. The alert marks the start of a process — business owner review, commercial analysis, legal sign-off, signature — and treating it as the moment of decision compresses weeks of work into the day it lands.
4. It goes to someone who has left. Owner fields are set at filing and rarely maintained, so alerts route to a departed employee or to a shared mailbox that no individual is accountable for. Both fail silently, because nothing bounces.
5. The renewal rolls and the stored date does not. On a contract that renews for successive terms, each cycle produces a new window. A single renewal date computed once at load is correct for exactly one cycle and quietly wrong after that.

The four dates that have to exist before anything can alert

One stored date cannot carry this. The record needs a chain, each step derived from the one before, and each one visible to the person receiving the alert so they can see why it arrived today.

Both rules depend on terms defined somewhere other than the notice clause. Business Day, Month and Notice are commonly defined in the interpretation section, occasionally overridden in a schedule, and the difference changes the deadline — the movement traced in defined terms and where their meanings move.

The decision tree behind an alert somebody acts on

An alert is not a message; it is a state machine with one question at the front of it: has a renew or exit decision been recorded for this cycle? Everything else follows from that answer.

• Decision recorded as renew. Stop alerting, roll the date chain forward to the next cycle, and diary the next first-alert date immediately rather than at renewal.
• Decision recorded as exit. Switch to preparing the notice: draft from template, route for approval, and track service. A workflow can assemble and evidence a notice, but a person sends it, which is the boundary drawn in what a workflow may prepare when notice must be given.
• No decision and the send-by date is still ahead. Escalate on the ladder below rather than repeating the same message at the same person.
• No decision and the send-by date has passed. Stop pretending. Record the cycle as auto-renewed, create a review item dated for the next cycle's first alert, and report the miss — a renewal that lapsed unnoticed is a finding, not a non-event.
• Owner unknown or departed. Route to the business unit that holds the spend and force reassignment before the next rung. An unassigned alert is not an alert.

The escalation ladder, and what happens at the last rung

A single reminder repeated weekly trains people to ignore it. A ladder changes both the audience and the content at each step, and the last rung has to do something other than send another email.

1. First alert, to the named owner, carrying the derived dates, the clause text and a direct link to the executed document — not a search result.
2. Halfway to decision-by, to the owner and their manager, now naming what happens by default if nothing is decided.
3. At decision-by, to legal and the approver, with the draft notice already prepared and the counterparty notice details attached.
4. After decision-by with no decision, daily to the approver, and visible on a renewals report that someone senior reads weekly.
5. At send-by, close the loop: record the outcome, whichever way it went, and log the reason no decision was reached. That log is the only evidence you will have when the same thing happens next year.

An alert that arrives before the deadline is not necessarily early enough. The useful question is whether it arrives before the last moment the decision could still be made.

Two dependencies sit outside the alerting logic and will defeat it if they are wrong. The alert has to link straight to the operative document, because an owner who has to go looking will not — the retrieval failure examined in search that cannot find a contract everyone knows exists. And the notice has to be addressed to the correct legal entity at the address the clause specifies, which fails when counterparty records are fragmented, as in one counterparty appearing under nine names.

None of this is difficult engineering. It is a derived-date layer, a state machine and an ownership model, built once and applied across every template — ordinary product build work whose value comes entirely from being right about which date it counts from. This page sits in the contract lifecycle: request to renewal, part of our legal technology practice.

• renewals
• notice periods
• contract alerts
• obligation management