Most renewal risk models treat usage as one number, when it isn’t. What people click and what actually flows through the product are two different signals. Where they disagree is where risk and opportunity can be identified first.
Usage isn’t one dataset
Ask most SaaS teams how they spot that a customer renewal is at risk in some way. You’ll often find the answer to be ‘usage dropped’. That’s the start of an answer, not the whole of one.
Attention tells you who is paying attention. Whether people log in, which features get used, whether a release got adopted, and how engagement varies across customers.
Dependence tells you what’s really going on. Records created, jobs run, and how many distinct users are doing real work rather than looking around. This usually lives in your own application data.
Blending those two together into one ‘usage’ figure isn’t the answer. The signal is in the gap between them.
Four patterns worth watching
There are four patterns worth paying attention to when it comes to how these sources operate with each other:
- Attention healthy, work flat. People log in, but nothing’s going on inside. Reads fine on an engagement dashboard, but could come back to bite.
- Attention falling, work steady or rising. Sessions decline while the work continues (usually efficiency, a changed workflow, or work moving to the API). Flag them as at-risk and CSMs chase accounts that turn out to be fine. A few of those and nobody trusts the risk list.
- Both rising, concentrated in one area. This is genuine usage, but perhaps depending on one team or user. It’s the clearest route for upselling or expansion, but can be a single point of failure if they leave.
- Both falling. Genuine disengagement, confirmed by two independent signals rather than one. This is the most obvious indicator of risk.
Let’s take pattern one. A company pays for 100 user licences, and only 45 employees use the software over the last 30 days. This suggests the customer may think they’re paying for more licences than they need. Instead of just showing ’45 active users’, the system would alert, ‘this account may reduce subscription at renewal because usage is low’. The account manager can then contact the customer, encourage adoption, or address any issues before the customer decides to buy fewer licences.
Now pattern two. A customer’s logins are down 40% over two months, which on an engagement dashboard looks like the beginning of a churn story. Check the other signal and records processed are flat: the same work is still going through, done by fewer people or pushed in through the API. Instead of adding the account to the risk list, the system flags it as a change worth a question rather than a rescue plan. One call tells the account manager whether the team has restructured, automated a step, or quietly lost the person who used to do it by hand.
And the third pattern. Suppose a customer is using more every week and is on track to pass a limit on their current plan (records, contacts, storage, whatever the tier caps) next month. Instead of waiting until the bill arrives, the system alerts the account team: ‘this customer is on track to move to the next pricing tier in three weeks’. The team can proactively discuss the upgrade, explain the benefits, or negotiate a new plan before the customer is surprised by a larger bill.
What ARR adds
Two signals tell you which accounts are moving. ARR tells you which of those moves matter.
Materiality. Rank by revenue at risk, not percentage decline. A 10% drop on your largest account is more significant than a 40% drop on your smallest one, and a percentage-only view will rank them the other way round.
Fit. ARR against activity gives you value per pound. If a customer pays the same £500 a month as similar businesses but processes ten times the amount of work, they are under-priced. This data gives your sales team the exact numbers needed to confidently pitch a higher tier.
Fit is the more useful of the two, and it’s the one usage-only reporting tends to miss.
Benchmark against peers, not against last month
A single account’s trend means little without knowing what normal looks like for accounts of similar size and tier. Comparing this quarter to last quarter on one account tells you it changed. Comparing it to a cohort of similar accounts tells you whether the change is unusual. Set up these peer comparisons early. If you see an account’s usage drop in August, you won’t panic if your data shows that every other customer of that size also slows down during summer holidays.
Give expansion equal billing
Some companies only use data to spot customers who are about to leave. But if you only use these metrics to catch problems, you are leaving money on the table. A customer adopting more and more and rising work volume is the exact same model but in reverse, showing a potential upsell rather than a rescue mission.
What this can’t see
Two data sources have limits, and it’s worth saying that plainly rather than choosing to oversell. Usage and ARR won’t show you a budget cut, a user leaving the business, or an acquisition changing who signs off on renewals. Plenty of accounts that don’t use much renew anyway because it’s part of a workflow nobody wants to rebuild, and plenty of active accounts still cancel simply because a new CFO decided to slash software budgets, regardless of how much the team loves your tool.
This is where support tickets, CS notes, and health data close the gap that usage and ARR leave open. If that side of the picture is the missing piece, that’s more of a wider data foundation question rather than a usage-reporting one.
What changes day to day
When done correctly, a member of the team will flag an account for a check-in call because usage dropped below a threshold three weeks before the renewal date, not the week of it. Your business review now becomes ‘here’s what we’re doing about account X’ rather than ‘let’s reconcile the numbers’.
Getting there is less work than it sounds if the pieces already exist. Both signals need to land in the same place on the same schedule, ARR needs joining at account level rather than at contract level, and the cohort baselines need building before you need them rather than during the quarter you first panic about an account.
