The Customer Success OKR Check-In Template I Use to Catch Churn Before the Renewal Call

I've run CS teams for the better part of a decade, and the check-in is where customer success OKRs live or die. Most CS check-ins are status meetings in disguise: everyone reads numbers out loud, nobody changes a decision. This one is built to do one job, which is catch a renewal slipping before the customer beats you to it. It's tuned to two things I refuse to fly blind on, where NRR is moving and how much of the book I can actually see.

By Max Bondarenko · Last updated June 2026

The template, up front

I'll give you the questions first, because that's what you came for. This isn't a generic status meeting dressed up in OKR language. It's a CS-specific check-in built to catch a renewal slipping before the renewal call, not after the customer's already drafted the cancellation email. I run it against two things every time: where my net revenue retention is moving, and how much of the book I can actually see. The questions below are the ones I've kept after cutting the ones that just made people feel busy.

The 5 questions I ask in every CS check-in

01What did NRR do since the last check-in, and which accounts moved it? (We climbed from a 104% baseline toward a 118% target over two quarters; name the three accounts that did the lifting.)
02How much of the book has a current health score? (Coverage moved from a 40% baseline toward a 90% target; if it dropped, the number is now lying to us.)
03Which accounts crossed from green to yellow or yellow to red this week, and what's the leading signal that flipped them?
04Of the renewals closing in the next 60 days, which ones don't have a champion confirmed, and who's reaching out by Friday?
05What's one thing we believed about an at-risk account last week that turned out to be wrong?

Why each question is there

The NRR question goes first because it's the only number on the board that pays the bills. Logo retention can look fine while revenue quietly bleeds through downgrades. Asking which accounts moved it forces the team off the aggregate and onto the actual humans. A jump from a 104% baseline to a 118% target is meaningless if it's one expansion masking four shrinking accounts, and you only find that out by naming names.

Health-score coverage is the question almost everyone skips, and it's the one I'd protect hardest. A health score on 40% of the book isn't a health score, it's a sample, and usually a flattering one because the accounts you've scored are the ones you talk to most. The quiet accounts are where churn hides. The point of the coverage question isn't to admire a 90% target; it's to notice the week it slips back to 70% from a 90% baseline because someone stopped updating a field, and to treat the score as broken until it's fixed. Here's the part people resist: when a key result turns out to be wrong, you revise it in week 4, not week 12. I once watched a team defend a health-score model for a full quarter that was scoring accounts green right up until they churned, because nobody wanted to admit the model was off mid-cycle. We rewrote the inputs in the next planning round and retention stopped surprising us. If your check-in surfaces a wrong target and you sit on it out of pride, the check-in's doing nothing.

The last question, about what you got wrong, is the one that earns its seat slowly. CS teams build narratives about accounts, and those narratives calcify. Asking weekly what flipped your read on an account keeps the room honest and trains people to update fast instead of defending last week's story to the renewal.

How I score it

I don't score CS check-ins on a 0.0 to 1.0 grade the way I'd score a quarterly objective. Mid-quarter, the useful signal is directional: is this account or this key result trending the way the target needs it to, or not. Three states, and each one has exactly one action attached so the read turns into a move before the meeting ends.

On track	NRR trend and health-score coverage are both moving toward target (for example, coverage holding above an 85% mark on its way from a 70% baseline to a 90% target). Action: do nothing extra, log the win, and protect the time you'd have spent here for an at-risk account.
Behind	The number's moving the right way but too slow to hit target by quarter-end, or coverage slipped a few points off its baseline. Action: name one specific intervention and one owner this week, not a plan to make a plan.
At risk	A renewal inside 60 days has no confirmed champion, or an account just dropped to red on a leading signal like login decline or a support-ticket spike. Action: escalate today, put a named human on the renewal call prep, and stop talking about anything green until it's handled.

CS check-in states and the single action each one triggers

How to actually run it

Async by default. Each CSM posts answers to the five questions in writing the morning of, so the live time isn't spent reading numbers out loud. The standing meeting is 25 minutes, and it exists for exactly one thing: the at-risk accounts and the renewals without a champion. Everything green gets skipped. If a week has no at-risk movement and full health-score coverage, cancel the live session and let the written posts stand. The trap I watch for is the meeting that runs the same length whether there's a fire or not; that's a sign it's become theater.

Who attends: the CSMs who own the at-risk accounts, plus whoever can actually unblock a renewal that day, usually a CS lead and sometimes someone from product or finance if the blocker is a feature gap or a pricing fight. I keep account execs off the standing invite and pull them in only for the specific renewal that needs them. The check-in lives or dies on whether people show up having already done the written work; if they're filling it in live, you've got a status meeting wearing an OKR costume, and you should fix that before you touch the template.

Questions people actually ask

How is a customer success OKR check-in different from a regular CS team standup?

A standup tracks tasks and who's blocked today. This check-in tracks whether NRR and health-score coverage are moving toward the targets you set for the quarter, and it forces a decision on every at-risk renewal inside 60 days. If your standup already does that, you don't need a second meeting; you need to add the two retention questions to the one you have.

Why put health-score coverage in the check-in instead of just the health score itself?

Because a health score on 40% of the book is a sample, and usually a flattering one, since you've scored the accounts you talk to most. The quiet ones are where churn hides. Tracking coverage from a 40% baseline toward a 90% target tells you whether the score can be trusted before you start making renewal bets on it.

What leading signals actually predict CS churn early enough to act on?

The ones I trust are login or usage decline against that account's own baseline, a sudden spike in support tickets, a champion going quiet, and a renewal inside 60 days with no confirmed champion. Lagging signals like the renewal date itself tell you nothing you can still fix. Build the health score on the leading ones and check coverage so you know it's watching the whole book.

How often should we run the CS check-in, and can we skip weeks?

Weekly, async by default, with a 25-minute live session only when there's at-risk movement to work. If a week has full health-score coverage and nothing crossed into yellow or red, cancel the live session and let the written posts stand. A check-in that runs the same length during a quiet week as a crisis week has turned into theater.

Stop running check-ins in a spreadsheet

Okiar is free during beta. Voice check-ins, AI projections, team health — live in minutes.

Start free →