Renewals are found by scanning contract end dates in a spreadsheet, usually too late to change anything. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A renewal tracker needs four things: contract terms including the notice date, a renewal stage model with entry criteria, an owner and a plan per renewal, and a forecast that separates likely from at risk with a stated reason. The date that matters is not the renewal date, it is the date by which the customer must give notice, and the date by which you must open the conversation to have any chance of changing the outcome. Build the timeline backwards from those.
Renewals
3
Past engagement date
4.1M
Renewing this quarter
108%
Net revenue retention
2
Committed but declining
Halden Foods
410K · overdue 11 days
Kestrel Ltd
64K · engage in 88 days
Northrise Group
240K · engage in 6 days
Vantor
135K · committed
Brightsea
88K · likely
You run customer success, renewals or revenue operations. You already know your contract dates. What you want is for every renewal to be worked on a schedule set by its notice period, and for the forecast to be something you can defend line by line.
How a renewal gets worked, starting far earlier than most teams start.
Notice deadline is contract end minus notice period. Engagement date is that minus your own lead time, and it is when work has to start.
That list is the reason to build this at all.
Otherwise everything sits in the middle stage until the month it closes and the pipeline tells you nothing.
The customer decision-maker, the specific risks, the value evidence to present, and the next step with a date.
Nobody can argue with 60 percent. Everybody can argue with a stated reason, which is the point.
So a committed forecast on a declining account is visible as a contradiction rather than a surprise.
A renewal tracker is not a filtered list of contract end dates. It is four parts, and the first one changes when the work starts.
Value, term dates, auto-renew flag, notice period, uplift clauses, and the derived notice deadline. Plus the derived date to open the conversation, which is the notice deadline minus your own lead time.
The steps a renewal moves through, each with entry criteria and an expected duration: not started, discovery, value review, proposal, negotiation, closed. Criteria are what stop everything piling in the middle.
One named owner, a decision-maker identified on the customer side, the risks specific to this renewal, and the next step with a date.
Each renewal categorised with a reason, rolled up by period, with expansion and contraction tracked separately from the base renewal value.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Two derived dates, and the list they produce.
In this Helix project, build me a renewal tracker.
Load contracts: account, product, annual value, currency, term start and
end, whether it auto-renews, the notice period in days, any contractual
uplift, payment terms, and an owner.
Now derive two dates and treat both as more important than the contract
end. The notice deadline, which is term end minus notice period. And the
engagement date, which is the notice deadline minus a lead time I
configure per contract value band. A large enterprise renewal needs to
open six months out and a small one needs six weeks, and one global
setting serves neither.
Then show me the next twelve months ordered by engagement date, with days
remaining, value, owner and stage. And put anything already past its
engagement date and not started at the very top. That list is the entire
reason for building this.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Sorting by contract end shows you renewals you can no longer influence. Sorting by engagement date shows you the ones you still can.
A process rather than a date and some optimism.
Add stages, in a config file: an ordered list with entry criteria and an
expected duration. Start with not started, discovery, value review,
proposal, negotiation, closed won, closed lost, and let me edit them.
Show the entry criteria when somebody moves a renewal into a stage, and
record who moved it and when. Without criteria, everything piles up in the
middle stage until the month it closes and the pipeline tells you nothing
you did not already know.
Give each renewal a plan: the customer decision-maker and their role, the
known risks, the value evidence to present, and the next step with a date
and an owner.
Flag any renewal that has been in a stage longer than its expected
duration.Reasons instead of probabilities.
Now the forecast, and do one thing differently from every CRM.
Categories are committed, likely, at risk and lost. Whenever a renewal is
set to at risk or lost, require a reason chosen from a short editable
list. Not a probability. Nobody can argue with 60 percent, and everybody
can argue with "champion left and the replacement has not engaged", which
is the conversation you actually want.
Roll up by quarter: base renewal value, expansion, contraction, and the
net. Derive gross renewal rate and net revenue retention from those rather
than letting anyone type them. A contract renewed at 60 percent of its
size is not a win, and a tracker that only asks whether it renewed will
record it as one.
Show the forecast three ways, committed only, committed plus likely, and
full pipeline, so a leadership conversation can happen without anyone
arguing about which number is meant. Snapshot it weekly and chart how each
quarter's number moved. The shape of that line teaches a team more about
its own optimism than any coaching.Worth knowing. A reason from a fixed list beats a probability every time. It can be discussed, disputed and acted on.
The mismatch alert, which is the whole reason to build this next to a health score.
If I connect them, pull per-account signals onto the renewal record: usage
trend, open escalations, ticket volume, health score, days since the last
meeting.
Then build the single most useful alert in the app: any renewal where a
signal is deteriorating and the forecast category is still committed.
That contradiction is what a renewal tracker can see and a health
dashboard on its own cannot.
On closure, record the outcome, the final value, a reason from a fixed
list, and free text. Then report renewal rate by segment, owner and
contract size, loss reasons over time, and how accurate each forecast
category turned out to be once quarters closed. Flag any lost renewal
above a value threshold for a post-loss review with an owner and a due
date.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Salesforce>. Read renewal opportunities and write the forecast category
and decision back.
<Stripe>. Read subscription term dates, billing schedule and value, which
is where the engagement date comes from.
<Amplitude>. Pull the usage trend, so a committed forecast on a declining
account shows as the contradiction it is.
<Google Calendar>. Put the engagement date in the owner's calendar, so
preparing for the conversation is scheduled rather than remembered.
<Okta>. Resolve owners and their manager chain, which is what the app uses
to show a rep their renewals and leadership the roll-up.
<Zendesk>. Read open escalations, so a committed forecast on an unhappy
account shows as the contradiction it is.
<Snowflake>. Read the usage and payment history behind each renewal, which
is the evidence for the conversation.
<Slack>. Warn the owner at the engagement date, which is months before the
renewal date.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. At-risk reasons and contract values are commercially sensitive, so set Access Control before sharing: owners see their renewals, leadership sees the roll-up.
Renewals are worked from contract data and decided on account behaviour, and those live apart.
Salesforce
Read renewal opportunities and write the forecast category and decision back.
Stripe
Read subscription term dates, billing schedule and value, which is where the engagement date comes from.
Amplitude
Pull the usage trend, so a committed forecast on a declining account shows as the contradiction it is.
Google Calendar
Put the engagement date in the owner's calendar, so preparing for the conversation is scheduled rather than remembered.
Okta
Resolve owners and their manager chain, which is what the app uses to show a rep their renewals and leadership the roll-up.
Zendesk
Read open escalations, so a committed forecast on an unhappy account shows as the contradiction it is.
Snowflake
Read the usage and payment history behind each renewal, which is the evidence for the conversation.
Slack
Warn the owner at the engagement date, which is months before the renewal date.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It holds contract terms, feeds a revenue forecast and shapes customer conversations, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Contract values and at-risk reasons are commercially sensitive. SSO means people sign in with their existing account, and access is scoped so an owner sees their renewals while leadership sees the roll-up.
App Security
Reading contracts, usage and health signals needs real access to those systems. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It works renewals backwards from the notice deadline, moves each through defined stages with an owner and a plan, and produces a forecast with reasons rather than probabilities. Its purpose is to start the conversation while the outcome can still change.
Because a contract with a 90-day notice period is effectively decided three months before it ends. Adding your own lead time on top gives the engagement date, which is when work actually has to start.
Ordered stages with explicit entry criteria and an expected duration: discovery, value review, proposal, negotiation, closed. Without criteria, everything sits in the middle stage until the month it closes and the pipeline tells you nothing.
Reasons work better. A category of at risk with "champion left and the replacement has not engaged" can be discussed and acted on. A 60% probability cannot be argued with, so nobody does.
They need separate fields from the base renewal value, because a contract renewed at 60% of its previous size is recorded as a win by a tracker that only asks whether it renewed. Net revenue retention should be derived from those fields, not typed in.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build from a CSV import. The judgement calls are your lead times per contract band and your stage entry criteria.
Customer Success
Build a health score from signals that actually predict renewal, show the trend rather than the number, and turn a red account into a named action. Prompts to build it, and what it takes to run it.
Customer Success
Assemble the usage, support, commercial and relationship picture for an account into one reviewable draft, so preparation is editing rather than gathering. Prompts to build it, and what it takes to run it.
Finance
One list of every subscription, what it costs, who owns it, when it renews, and how much of it is actually used. Prompts to build it, and what it takes to run it.
Customer Success
Track every new customer through the same stages, with the tasks that belong to them as visible as the ones that belong to you. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.