Most B2B SaaS Companies Have No Renewals Process. RevOps Should Build One.

TL;DR: Most Series A-C SaaS companies treat renewals as a CSM admin task. They're not. A broken renewals process is a forecasting problem, a revenue architecture problem, and ultimately a company valuation problem. RevOps should own the infrastructure. Here's how to build it.**

I've been in renewal reviews where the CFO asked what ARR was at risk in the next 90 days and the CS leader opened a spreadsheet. Not a CRM report. A spreadsheet. With color coding.

That spreadsheet had been maintained by one CSM. She was on maternity leave.

Sound familiar?

This isn't a horror story about one company. It's the default state of renewals in most B2B SaaS companies at Series A through C. The commercial motion that protects your existing revenue base is running on a CSM's personal organization system, a 30-day heads-up email, and hope. And nobody in RevOps has claimed it.

That needs to change. Not because renewals are a nice process to tighten up, but because you cannot build a credible revenue forecast if half your ARR lives outside your CRM infrastructure.

I offer this view as founder of VEN Studio, a boutique RevOps consultancy, former VP RevOps at a tech unicorn, and someone who has audited more than 50 B2B SaaS CRM implementations. Renewals architecture is one of the most consistently neglected pieces of the stack.

Why RevOps Hasn't Owned This (And Why That Has to Stop)

The reason renewals fall through the RevOps gap is structural. Most RevOps functions are built to support the new business motion. Pipeline, forecasting, territory, comp. That's where the pressure comes from, so that's where the attention goes.

Customer success teams end up owning renewals by default, not by design. And CS leaders, to their credit, are usually focused on outcomes: onboarding, adoption, expansion conversations, QBRs. The renewal itself often gets treated as the administrative tail of that work rather than a commercial event that needs its own workflow.

The result: no standard on when renewal opportunities get created. No consistent health data feeding risk scores. No defined handoff when a renewal has expansion potential. No reporting that ties renewal outcomes to forecast accuracy.

That's not a CS problem. That's a revenue architecture problem. And revenue architecture is RevOps' job.

The Forecasting Problem Nobody Is Naming

Here's the thing most SaaS leadership teams miss: a broken renewals process doesn't just hurt retention. It destroys forecast credibility.

If your CFO is trying to model next quarter's revenue and the renewal data lives in a spreadsheet with no stage, no close date, no risk flag, and no owner beyond "the assigned CSM," then your forecast has a structural hole in it. New business pipeline gets scrutinized with weighted probabilities, stage-by-stage conversion assumptions, and rep-level roll-ups. Renewals get a line item that says "expected to renew" and a prayer.

At Series A, that gap is uncomfortable. At Series C, when your investors are modeling NRR and asking about gross retention, it's a serious problem. Net Revenue Retention is one of the most scrutinized metrics in B2B SaaS valuation. Investors and acquirers will pull it apart. If the data feeding that number is unreliable, your credibility takes the hit.

Build the renewals process now, before you need the number to be defensible.

What a Structured Renewals Process Actually Looks Like

This doesn't require a new platform. It requires decisions and discipline. Here's the framework.

1. Opportunity Creation: Set a Standard and Automate It

The single most common failure point is inconsistency in when renewal opportunities get created. Some CSMs create them 90 days out. Some create them at 30 days. Some never create them at all and just convert the original opportunity.

Set a standard. I recommend creating renewal opportunities 120 days before contract end date for any account above your ARR threshold (you define the threshold based on your ACV economics). Below that threshold, 60 days is usually sufficient.

Automate the creation. If you're on Salesforce, a flow triggered by contract end date works fine. If you're on HubSpot, a workflow off your contract record or a custom deal creation trigger does the job. The point is that creation shouldn't depend on a CSM remembering to do it.

Fields to populate at creation, at minimum:

Field	Source
ARR at risk	Contract record
Contract end date	Contract record
Renewal owner	CS assignment
Account health score	Product/CS platform
Last QBR date	CS activity log
Expansion potential	CSM judgment, deal field
Risk flag	Health score threshold or CSM input

2. Health Signals: What Actually Predicts Renewal Risk

This is where most companies go wrong in the other direction. They either have nothing (the spreadsheet scenario) or they build a 40-variable health score that nobody trusts and everyone ignores.

Start with the signals that actually matter. In my experience auditing these systems, the most predictive inputs are:

Product engagement. Are users logging in? Are they using the core features that drove the purchase decision? A customer who bought your analytics product but hasn't run a report in 60 days is at risk regardless of what they said in their last QBR.

Support ticket volume and sentiment. A spike in support tickets, especially if tickets are going unresolved or escalating, is a leading indicator. Silence isn't always good either. Disengaged customers often stop filing tickets because they've mentally moved on.

Stakeholder changes. Champion turnover is one of the most reliable risk signals in B2B SaaS. If the VP who bought your product has left and the new one hasn't been onboarded, you have a risk flag whether your health score says so or not.

Payment and billing health. Late payments, disputed invoices, and downgrade requests in the billing system are hard signals. If this data isn't flowing into your CRM, fix that first.

QBR cadence. Has there been a business review in the last 90 days? If not, and renewal is within 120 days, that's a gap that needs action, not a data point to log.

You don't need to weight all of these into a single composite score on day one. A simple red/yellow/green classification, manually reviewed by the CSM and updated monthly, is better than an automated score nobody trusts. Build toward automation once you've validated which signals matter in your customer base.

3. The CS-to-Sales Handoff: When and How

Not every renewal is a renewal. Some are expansion opportunities. A customer approaching their seat limit, adding use cases, or signaling interest in a higher tier needs a different motion than a straight renewal conversation.

RevOps needs to define the handoff criteria explicitly. Otherwise what happens is: CS handles it informally, brings sales in too late, and you end up with two people in the same customer conversation without a coordinated play.

Here's a simple framework:

Scenario	Owned By	Trigger for Handoff
Flat renewal, healthy account	CS lead	None required
Flat renewal, at-risk account	CS lead + Sales assist	Red health flag, 90+ days out
Renewal + expansion (same product)	CS lead + AE	Expansion signal, 90 days out
Renewal + new product/use case	AE lead + CS assist	Qualified expansion opportunity
Strategic account, large ARR	Joint CS + Sales from 120 days	Defined by account tier

The handoff isn't just about who owns the call. It's about who owns the opportunity in the CRM, who updates the stage, who attaches the expansion opportunity as a child deal, and who is accountable if it slips past the renewal date without a decision.

Document this. Put it in your sales playbook and your CS playbook. Make sure both teams are running the same version.

4. Renewal Stages: Give the Opportunity a Pipeline

A renewal opportunity without stages is just a flag. It tells you the renewal exists but not where you are in the process or what needs to happen next.

Here's a basic renewal pipeline that works for most B2B SaaS companies at this stage:

Stage	Definition	Probability (illustrative)
Identified	Opportunity created, health assessed	85%
Outreach Sent	Initial renewal conversation initiated	85%
In Discussion	Active conversation, terms under review	80%
Verbal Commit	Customer has indicated intent to renew	90%
Contract Sent	Renewal agreement delivered	95%
Closed Won	Signed	100%
Closed Lost / Churned	Did not renew	0%

Note: these probability figures are illustrative framework values. Set your own based on actual historical conversion rates from each stage in your business.

The key is that stages reflect buyer behavior, not CSM activity. "Email sent" is not a stage. "Customer confirmed intent to renew" is a stage.

5. Reporting Cadence: What RevOps Needs to Own

Once the infrastructure exists, RevOps owns the reporting layer. This isn't just "build the dashboard and hand it to CS." The right cadence looks like this:

Weekly (for CS leadership): Renewals due in the next 60 days, broken down by stage and health flag. Overdue outreach. At-risk accounts with no action in the last two weeks.

Monthly (for revenue leadership): ARR up for renewal by month, renewal rate by segment, expansion attach rate, churn by reason code. Compare actuals to forecast. Identify where slippage is happening in the stage progression.

Quarterly (for executive team and board): Gross retention rate, net revenue retention, cohort-level renewal analysis, leading indicators for the next two quarters. If you're Series B or C, this is the number your investors are watching.

RevOps should own the definitions, the data integrity, and the cadence. CS owns the execution. Finance owns the model inputs. Nobody should be making slides from spreadsheets.

Where to Start If You're Starting From Zero

If your renewals process is currently a CSM's inbox and a color-coded spreadsheet, don't try to build all of this at once. Sequence matters.

First, fix the data foundation. Get your contract end dates into your CRM and make sure they're accurate. This sounds trivial. It isn't. At most companies we work with through VEN Studio, the contract data is either missing, out of date, or inconsistently structured across segments.

Second, standardize opportunity creation. Automate it. Establish the rule and remove the dependency on individual CSM habits.

Third, pick two or three health signals and get them flowing into the CRM reliably. Don't build the full scoring model yet. Get clean, consistent data first.

Fourth, define your CS-to-sales handoff criteria and socialize them. This conversation is usually where organizational friction surfaces. Have it early.

Fifth, build the reporting layer once the underlying data is reliable. A dashboard built on bad data isn't a dashboard. It's a false sense of visibility.

Frequently Asked Questions

Does this require a dedicated CS platform like Gainsight or Totango? No. A CS platform helps, especially for health scoring and automated playbooks at scale. But the core renewals infrastructure can run in Salesforce or HubSpot with well-structured contract data, clean opportunity stages, and basic workflow automation. Start with what you have. Add tooling when the process is proven.

Who should own the renewals process: CS, Sales, or RevOps? RevOps owns the architecture and reporting. CS owns the execution for standard renewals. Sales leads on expansion-heavy or strategic renewals. The mistake is letting any one of these teams own all three. That's how you get the spreadsheet problem in the first place.

How early is too early to build this? If you have more than 50 customers and any meaningful ARR concentration, you should have a process. The earlier you build it, the cheaper it is. Retrofitting renewals infrastructure onto a customer base of several hundred accounts with messy contract data is painful. It's one of the most consistent things I see in audits: companies that waited too long and are now doing forensic accounting on their own revenue.

What's the most common mistake companies make when building this? Over-engineering the health score before they have reliable data. They spend three months debating the weighting of 20 signals and launch a composite score that nobody trusts because the underlying data hasn't been validated. Build the data plumbing first. Score later.

What if CS leadership pushes back on RevOps owning this? That's a conversation worth having explicitly rather than avoiding. The argument that usually lands: "I'm not trying to take ownership of your customer relationships. I'm trying to make sure the data infrastructure exists so that your team's work shows up in the forecast accurately and gets the credit it deserves." Renewal motion that's invisible to the board is renewal motion that doesn't get resourced.