Who Owns Renewals at an Early SaaS Company?

Who should own renewals in an early SaaS company?

Someone named, and almost never the founder by default. Early on, renewals usually belong to nobody: sales has moved to the next deal, support only hears about problems, and the founder assumes a happy customer renews itself. The money arrives automatically, so the absence of an owner stays invisible until it does not.

Our view is that renewal ownership should be assigned before the first renewal happens, and that the first owner should be whoever already talks to customers most, not whoever has the most appropriate job title.

What follows is the argument for that, plus the specific system signals that make renewal ownership possible rather than aspirational.

Why does nobody own renewals by default?

Because the billing system hides the event. A card charges, revenue appears, and nothing in the company notices that a decision was made. Compare that to a new deal, which generates meetings, a proposal, and a celebration. The renewal is the same amount of money with none of the ceremony.

The second reason is that renewals do not fit the early org chart. They are partly commercial, partly support, and partly product, which means every function has a reason to assume it is someone else's job. Shared ownership of a recurring event reliably produces no ownership at all.

And the failure is lagging. You cannot tell in month three whether renewals are being managed, because nothing renews until month twelve. By the time the data arrives, the habits are a year old.

What does a renewal actually require?

Three things, and only one of them is a conversation. Someone has to know the renewal is coming, someone has to know whether the customer got value, and someone has to act if the answer is no. Miss any one and the renewal is left to chance.

Knowing it is coming is pure systems work. The date is in your billing data and it can be surfaced automatically, so there is no excuse for discovering a renewal after it lapsed. This is the cheapest of the three and the most commonly skipped.

Knowing whether value landed is harder and it is where early teams substitute feeling for evidence. A customer who is quiet is not necessarily happy, and a customer who files tickets is not necessarily unhappy. Deciding in advance what counts as evidence is the real work.

What signal tells you a renewal is at risk?

The cancellation flag, and your billing provider will tell you the moment it flips. Stripe's documentation notes that a customer.subscription.updated event is sent for any subscription update, including when cancel at period end is set to true, and that customer.subscription.deleted is sent when a subscription is actually cancelled.

Those two are very different moments and most teams treat them identically. The first says a customer has decided to leave at some future date. The second says they have gone. There is usually weeks of difference between them, and that gap is the only window you get.

The gap is actionable because it is reversible. Stripe says you can reactivate subscriptions scheduled for cancellation by updating cancel at period end to false, at any time up to the end of the period, and is equally clear about the other side: you cannot reactivate a cancelled subscription. One of those states is recoverable and one is not.

Why is the cancellation window the most valuable moment you have?

Because the customer has told you something true and has not yet left. Every other churn signal is inference. This one is a stated decision, with a deadline, from someone who still has an account.

Stripe's cancellation mechanics make the shape of that window concrete. Setting cancel at period end allows the subscription to complete the duration of time the customer has already paid for, where the default behaviour of cancelling takes effect immediately. So a customer who cancels at period end is still a customer, often for weeks.

If nobody in your company is alerted when that flag flips, you have chosen not to use the only genuinely recoverable churn signal you get. That is an ownership failure rather than a tooling one, because the event is already being sent. Our notes on account deletion and cancellation UX cover the design side of that moment.

Should you build a health score?

Eventually, and not first. Health scoring is useful once you have enough customers that you cannot hold them all in your head, and actively misleading before that, because a score built on a handful of accounts is just your assumptions with a number attached.

When you do build one, the tooling is standard rather than specialist. HubSpot's customer success workspace health scores assign numerical values to records based on selected property values and tracked event activities, using event groups covering activities like meetings, calls, and support tickets, and property groups covering attributes such as company location, employee count, NPS feedback, and CSM sentiment.

It is worth checking what it costs to turn on. HubSpot states health scores require Service Hub Professional or Enterprise, that a Service Seat is required to create a health score, and that it needs Manage Customer Success Settings permissions. That is a real purchase decision, which is another argument for doing it when the customer count justifies it rather than at the start.

What about involuntary churn?

It is a renewal problem wearing a payments costume, and it has its own deadline. Stripe's documentation states that subscriptions cancel automatically after up to eight unsuccessful attempts to bill the customer, with the number configurable in subscription settings.

So a customer who fully intended to stay can be cancelled by a card expiry and a retry schedule. Nobody made a decision. There was no conversation to have. The account simply ran out of attempts while everyone assumed silence meant satisfaction.

Disputes add a nastier version. Stripe notes that when a customer disputes a charge for a subscription, the subscription continues to cycle, which can create more disputed charges, unless you configure it to cancel instead. A frustrated customer can accumulate several disputes before anyone notices. Our notes on lifecycle email cover automating the outreach side of this.

What does the website owe the renewal?

More than most teams think, and this is the part we can speak to directly. A renewing customer is still reading your site: your documentation, your changelog, your new feature pages, your pricing page when they wonder whether they are on the right plan.

Sites built purely for acquisition ignore that reader completely. The homepage explains the category to a stranger, the pricing page is written to win a first purchase, and there is nothing that helps an existing customer see what has improved since they signed. That is a renewal asset left unbuilt.

The cheapest fix is a maintained changelog and a what is new page that a customer success person can actually send. It costs very little, it gives the renewal conversation evidence, and it works whether or not anyone owns renewals yet. Our notes on customer marketing and expansion cover the broader version of this.

When should you hire for this?

Later than the advice suggests, and with a narrower brief. Hiring a customer success manager before you know what causes your churn produces someone doing unfocused relationship work against a problem nobody has diagnosed.

The sequence we would follow is to assign ownership to an existing person, instrument the signals, run a year of renewals with real notes on why each one went the way it did, and then hire against what that evidence shows. The first hire then has a job description derived from your business rather than from a template.

What should not wait is the instrumentation. Alerts on the cancellation flag, visibility of upcoming renewal dates, and separate reporting of voluntary and involuntary churn are all small pieces of work that make the eventual hire effective instead of exploratory.

What we would do first

Name an owner this week and wire two alerts. The owner can be the founder, the first support hire, or the account executive who sold the deal; what matters is that one person's name sits against it. The alerts are the cancellation flag flipping and a payment entering retry.

Then write down, per renewal, what actually happened and why. A year of honest notes beats any health score built on assumptions, and it is the input the score will eventually need anyway.

Where we are clear about our lane: we build the websites, content systems, and automations around this rather than running anyone's customer success function. The parts we will argue about confidently are the signals, the alerting, and whether your site serves existing customers at all. Our notes on saying no to bad fit customers cover the upstream decision that prevents the worst renewals.

Does renewal ownership change as you grow?

The owner changes, the discipline does not. At ten customers it is a person with a list. At a hundred it is a function with a score. At a thousand it is a system with exceptions routed to humans. What stays constant is that someone is accountable for a specific date and a specific answer.

Our bet is that the companies who struggle most are not the ones who hired late. They are the ones who never instrumented the cancellation window, so by the time they had the headcount to act on churn they had no history explaining it.

If you want a second opinion on whether your site and your systems support the customers you already have, we are happy to look. Find us at phoenix.studio.