
Reasons an Account Is at Risk of Not Renewing a Contract
By Anirudh Menon, Viaclause editor
The same usage drop can signal reduced seat needs or a failed workflow. Check the cause before choosing a renewal response.
AI-generated editorial illustration. People and setting are fictional, not an actual customer meeting.
Reasons an account is at risk of not renewing a contract are low usage or adoption, a lost champion or sponsor, unresolved support issues, missed outcomes or ROI, budget cuts or a change of owner, a competitor evaluation, an approaching notice window or auto-renewal date, and a renewal conversation that keeps slipping. Start by asking what changed and who now decides. Falling usage or a late payment deserves investigation, but does not by itself prove that the customer plans to leave.
Use the contract renewal checklist to connect this issue to the renewal decision, terms and notice record.
Why an account may not renew
GitLab separates adoption, value, quality, engagement, budget and corporate decisions. Investigate each concern before choosing a response.
| Possible reason | What to check | Useful next action |
|---|---|---|
| The promised result has not arrived. | Which agreed outcome is missing, and what evidence would demonstrate it? | Agree a specific result to demonstrate, with an owner and date. |
| Users never adopted the workflow. | Who still needs it, who can access it, and where do they stop? | Test the blocked task with the people who need to perform it. |
| Service problems remain unresolved. | Which open issue prevents useful work? Has the customer confirmed a fix? | Assign the issue to a service owner and agree a verification step. |
| The sponsor or budget owner changed. | Who now supports the purchase and who can approve spending? | Confirm the new decision-maker and their requirements. |
| The budget or required scope shrank. | Is the objection the total spend, unnecessary seats, or the product itself? | Price the actual future requirement before proposing a discount. |
| A competitor or corporate standard is replacing you. | Is a choice already made, or is there an open evaluation? | Confirm the criteria and decision stage; plan a handover if the decision is final. |
| The renewal conversation keeps slipping. | Who stopped responding, and has the decision moved? | Ask for a decision date and the approver by name. |
| The notice or auto-renewal date is close. | What do the order form's term, notice method and price-change clauses say? | Plan backwards from the notice date. |
Ask: “Would you keep, reduce or replace this service today? What must change, and who decides?” Record the date and speaker's role. A happy user may not control the budget.
Check whether the warning is real
GitLab distinguishes activation, engagement, product use and outcomes. Compare the same task, population and period; missing data does not establish zero activity.
Stripe documents temporary failures and payment-method updates. Check the actual cause before treating an unpaid invoice as an intention to cancel.
- Usage fell: check the definition, reporting window, eligible population and whether the feed still works.
- A meeting was missed: confirm whether the person changed roles or the decision moved to someone else.
- An invoice is overdue: distinguish an administrative block, disputed charge and unavailable budget.
- The customer requested an export: ask its purpose; do not mark the account lost based on the request alone.
Worked example: the same 40% drop, two different renewal problems
These are synthetic accounts, not observed customer results or predictive benchmarks. Both bought 100 seats. “Active” means a unique user completed the same named workflow at least once during a 30-day window. Assume complete data, equal reporting windows and no seasonal effect. The customer confirms who still needs that workflow.

Each account had 80 active users in the earlier window and 48 in the latest one. The reduction is 32 users, or 40% of 80. That headline is identical. The remaining need is not:
| Measure | Account A: team reduced | Account B: workflow blocked |
|---|---|---|
| Purchased seats | 100 | 100 |
| People who needed the workflow before | 80 | 80 |
| People who need it now, confirmed by customer | 50 | 80 |
| Latest active users | 48 | 48 |
| Active users divided by current need | 48 / 50 = 96% | 48 / 80 = 60% |
| Customer explanation | Reorganization removed 30 roles from this workflow. | 32 intended users cannot complete the workflow after an integration change. |
| Next renewal discussion | Confirm future scope and obtain approval for a smaller offer. | Repair and verify the task before claiming adoption recovered. |
Keep the financial effect separate. Suppose Account A's current annual fee is $120,000 and a genuinely available, internally approved smaller offer is $90,000. If the customer agrees to that offer, annual recurring fees would fall by $30,000, or 25%. If it does not renew at all, $120,000 of next-term recurring fees is exposed. Those are alternative scenarios, not losses to add together.
Keep the customer's intention separate from the contract status
Record these three answers separately:
- Business intention: what does the customer say it wants?
- Commercial approval: who has approved the scope, price and spending?
- Contract status: what do the applicable agreement and completed actions establish?
For a bounded news example of this uncertainty, read the Janai Norman non-renewal analysis without treating that reported departure as evidence about your customer’s agreement.
For a concrete example, HubSpot General Terms, sections 4.1 and 4.2, address automatic renewal and generally require turning off auto-renewal in Account & Billing before the term ends, unless the agreement or order says otherwise. A conversation and an account action are different records. These are HubSpot's public terms, not the rule for every subscription.
Three terms set your timetable: the notice period, whether silence auto-renews the term, and any price-increase cap. Read them before the notice window opens, not at the renewal date. See our evergreen clause examples.
Check notice delivery and renewal ownership separately.
A renewal-risk record you can actually update
ACCOUNT A: SYNTHETIC RECORD Review: September 29, 2026; owner: account manager Observation: 80 to 48 active users, equal 30-day windows. Explanation: Reorganization; 50 intended users remain. Evidence: Dated admin roster and workflow export. Open: Budget owner's approval of smaller renewal. Scenarios: $30,000 annual contraction OR $120,000 exposed. Intention: Admin wants service for the smaller team. Approval: Pending; admin is not the budget approver. Contract: Check renewal terms and required notice/action. Next: Meet budget owner October 1; review October 2. Close after approved scope/price and required action.
October 1 and 2 are example operating dates, not contractual deadlines. If the actual notice or approval cutoff is earlier, that earlier requirement controls the work plan.
COPYABLE RENEWAL-RISK RECORD Account and agreement: Review date and owner: Observed change, definition and comparison periods: Customer explanation / speaker / date: Evidence checked and missing evidence: Other plausible explanation: Separate revenue scenarios: Customer intention: Budget and commercial approval: Contractual renewal or notice status, with source: Next action, accountable person and due date: Evidence required to resolve the concern: Next review and escalation if unanswered:
If the customer confirms it is leaving, plan an orderly handover.
Frequently asked questions
Can an account be at risk even when users are happy?
Yes. A budget reduction or corporate purchasing decision can matter separately from user satisfaction. Confirm the decision with the person responsible for it.
Should we offer a discount immediately?
First establish the obstacle. A discount might address affordability but not a broken workflow or a decision to eliminate the product. Get authority for any proposed terms and show the customer what scope they buy.
Is a renewal-risk score a churn probability?
Not automatically. A label or weighted score is not a calibrated probability merely because it is expressed as a number. This guide's ratios and scenarios are decision aids, not a tested prediction model.
When can we mark the risk resolved?
When the evidence for that specific concern is satisfied. A repaired integration can close the technical issue while the renewal decision remains pending. Preserve both states instead of using one green label for the entire relationship.
Sources
- GitLab: Customer Health Assessment and Management. Risk categories, update and resolution process. Last modified September 24, 2026; inspected September 29.
- GitLab: Customer Health Scoring. Distinct usage and health measures, missing-statistics treatment. Last modified September 24, 2026; inspected September 29.
- Stripe: Revenue recovery. Subscription payment failures and recovery mechanisms. Inspected September 29, 2026.
- HubSpot Customer Terms of Service. General Terms, sections 4.1 and 4.2, last modified September 16, 2026. Inspected September 29; named vendor example only.