What Customer Success Manager Interviews Actually Test in 2026

It's the gap between a signed contract and the first moment the customer experiences the outcome they bought the product for, not the moment they logged in or finished a training video. A customer who's completed onboarding but hasn't hit that first real outcome hasn't gotten value yet, whatever the checklist says.

Strong answers name a concrete example, first report generated, first automated workflow live, first support ticket resolved through the tool instead of email, rather than a vague "they got up and running."

Churn is the account leaving entirely. Contraction is the account staying but paying less, a seat reduction, a downgrade, a scope cut at renewal. Contraction often gets under-reported internally because the logo technically didn't leave, but it erodes revenue the same way churn does, just more quietly.

Candidates who only track full churn and ignore contraction usually miss the earlier warning signs. A book of accounts contracting steadily is often the leading indicator of churn that shows up a quarter or two later.

Name real tools, Gainsight, Totango, Vitally, ChurnZero, or a homegrown system built on a CRM, and be specific about what the tool actually did versus what it claimed to do. A health score dashboard nobody trusted because the inputs were wrong is a common, honest story worth telling.

Interviewers are checking for hands-on familiarity, not brand-name dropping. A candidate who can describe configuring a health score model, not just viewing one someone else built, stands out here.

Generic answers about "loving to help people" are forgettable and true of almost every candidate in the room. A specific answer names what draws you to the retention and outcome side of the relationship over the acquisition side, tied to something concrete you've actually experienced managing a renewal or an escalation.

This function is genuinely still growing. Gainsight's own research, using LinkedIn's data, found customer success roles grew 736 percent between 2015 and the report's 2019 release, among the fastest-growing professions LinkedIn tracked at the time (Gainsight, 2019). That data is seven years old now and nobody's published a cleaner update since, but it's still the number most CS leadership decks reach for when they explain why the function exists at all.

Name the specific feedback, who gave it, and what you actually changed afterward, not a vague "I learned to communicate better." Concrete feedback tied to a concrete behavior change is far more credible than a general self-improvement narrative.

Candidates who can't name any feedback that changed their approach tend to read as either early in their career or not particularly reflective about the work, neither of which is disqualifying alone, but interviewers notice the gap.

Vague ambition, "I want to grow," doesn't tell an interviewer much. A specific direction, moving into a strategic or enterprise-focused CSM track, building toward CS leadership, going deeper into the ops and tooling side of the function, gives them something real to evaluate fit against.

The honest caveat worth including: plans change once you're actually doing the job for a year. Candidates who acknowledge that, while still naming a real direction, tend to come across as more grounded than ones with an oddly rigid five-year plan already mapped out.

Customer success is proactive and outcome focused. The job is to make sure the customer achieves the business result they bought the product for, and to do that before they have to ask for help. Support is reactive. Someone files a ticket, you fix a broken thing, and you move to the next ticket. A CSM is judged on renewal, expansion, and adoption metrics tied to a portfolio of accounts. A support agent is judged on ticket volume, first response time, and resolution time on individual issues.

In practice the two functions blend at smaller companies, where a CSM might close their own tickets, but as a company scales they split because the incentives conflict. A support team optimized purely for fast ticket closure will sometimes close a ticket that leaves the underlying adoption problem unsolved. A CSM who spends the day working support queues never gets to the strategic work of building a champion network or planning the account's next twelve months. Support keeps the lights on. CS makes sure the customer is glad they turned the lights on in the first place.

CSAT measures satisfaction with a single interaction, usually a 1-5 or 1-7 scale sent right after a support ticket closes or an onboarding call ends. It's a snapshot, useful for catching a bad interaction fast, but it tells you almost nothing about whether the customer will renew.

NPS measures loyalty and likelihood to recommend, on a 0-10 scale, and it's a relationship-level metric usually sent quarterly or after a renewal. It correlates with expansion and referral behavior better than CSAT does, but it's a lagging indicator. By the time a detractor tells you they're a detractor, the relationship has usually already soured.

CES, customer effort score, asks how much effort it took to get something done, and it's the best predictor of churn among the three because friction is what actually drives people to look at competitors. I use CES around specific moments, like after a support resolution or a workflow such as data migration, because a low-effort experience there is one of the strongest signals that the account will stick around. None of the three replaces a health score built from usage data. They're inputs to it.

A QBR, quarterly business review, is a working session with the day-to-day users and admins on the account. You're reviewing adoption data, open items, and the plan for the next quarter. It's tactical, and it happens on a predictable cadence for accounts above a certain tier regardless of contract size.

An EBR, executive business review, is a strategic conversation with the customer's leadership, usually the economic buyer or their manager, focused on ROI and business outcomes rather than feature usage. You don't walk an EBR through login counts. You show leadership what the investment returned in terms they report to their own board. EBRs happen less often, usually once or twice a year, and they're the meeting where renewal and expansion conversations actually get seeded, months before the paperwork happens. Conflating the two is a common mistake junior CSMs make, bringing a QBR deck full of usage charts into a room with a VP who wants to hear about revenue impact and nothing else.

A mutual action plan is a shared document, usually a simple table, that lists the milestones both sides need to hit to get the account live and getting value, with owners and dates on each line. It's mutual because it isn't a one-sided CS checklist. The customer has action items on it too, like assigning an admin or completing a data export from their old system.

The reason it matters is accountability. Without a written plan, a stalled onboarding turns into a disagreement between the CSM and the customer about who was supposed to do what. With one, you can point to the document on a call and say the customer's item has been open for three weeks, which turns an awkward conversation into a factual one. It also gives you an early warning signal. If a customer routinely misses their own action items, that previews how engaged they'll be later when you need them to champion a renewal or complete a security review.

High-touch means a named CSM owns a small number of accounts, usually the largest or most strategic, and runs regular calls, custom onboarding, and hands-on account planning. Tech-touch means the account is managed mostly through automated emails, in-app messages, and triggered playbooks, with a human stepping in only when a risk signal fires. Pooled sits in between. A small team of CSMs shares a segment of accounts, nobody owns a named book, and outreach is triggered by lifecycle stage or usage events rather than a personal relationship.

The model should follow the economics, not the other way around. If an account's contract value can't support the cost of a human doing quarterly calls, forcing high-touch coverage on it burns capacity that should go toward accounts where a relationship actually changes the renewal outcome. The mistake I've seen most is companies keeping everyone on high-touch as they scale past a few hundred accounts, which means CSMs spend their time firefighting the loudest accounts instead of the highest-value ones.

A playbook is a documented, repeatable response to a specific trigger, not a general philosophy of how to be a good CSM. A churn-risk playbook fires when usage drops below a threshold for two consecutive weeks, and it specifies exactly what the CSM does: send this email, book this call, escalate to this manager if there's no response in five business days. A renewal playbook specifies when the first outreach happens relative to the contract end date, what pricing conversations are allowed without approval, and what the escalation path looks like if the customer goes quiet.

Good playbooks have a trigger, a sequence of actions with owners, and an exit condition, so a CSM knows when the playbook is done versus when it needs to be escalated. What goes wrong is playbooks written as vague guidance, like "check in with at-risk accounts regularly," which gives new CSMs nothing concrete to execute and gives leadership no way to measure whether the playbook is actually being followed.

MRR is monthly recurring revenue, ARR is the same number annualized, multiply MRR by twelve. Which one a company reports usually depends on contract structure. Companies selling annual contracts report in ARR because that's how the deal is actually billed. Companies with month-to-month or usage-based pricing lean on MRR because ARR would imply a commitment that doesn't exist.

For a CSM's forecast, what matters is which accounts in the book renew, contract, or expand in the coming period, translated into whichever unit finance uses. The trap is treating ARR and MRR as interchangeable when forecasting a book with a mix of annual and monthly contracts, because a monthly account that churns mid-quarter shows up differently in an ARR waterfall than an annual account that churns at renewal. I've seen forecast accuracy fall apart specifically because a CSM reported an account as on track using MRR logic when it was actually an annual contract with a hard renewal date three months out.

Logo churn counts the number of customers who leave, full stop, regardless of how big or small they were. Revenue churn weights that same departure by dollars, so losing one customer that was ten percent of the book hurts revenue churn far more than losing ten small customers combined, even though logo churn treats all eleven departures the same on a per-account basis.

The distinction matters because the two numbers can tell completely different stories in the same quarter. A CS team can have flat or improving logo churn while revenue churn spikes because one large account left, and leadership needs to know which story is true before deciding whether the problem is broad, showing up across many small accounts, or concentrated in one account-specific failure. Reporting only logo churn because it looks better is a common way CS teams paper over a real revenue problem.

Reactive customer success responds to signals the customer already surfaced: a support ticket, a cancellation notice, a complaint on a call. Proactive customer success acts on signals the customer hasn't surfaced yet: usage data showing a key workflow went untouched for three weeks, a champion who stopped attending calls, a renewal six months out with zero expansion conversation started.

The shift from reactive to proactive is usually the biggest maturity marker for a CS org, and it's driven by data access more than effort. A CSM can want to be proactive all day, but without a usage dashboard or health score feeding them signals, they're stuck waiting for the customer to say something is wrong, and by then the account is often already at risk. The part nobody talks about enough: proactive outreach at scale, if it isn't well targeted, becomes noise the customer tunes out. Proactive doesn't just mean more touches, it means better-timed ones based on actual risk or opportunity signals rather than a fixed calendar cadence.

Name the handoff first: what you get from sales (the deal notes, the promises made, the champion's actual title), and what you do in the first 48 hours before the kickoff call even happens. Then walk the milestones a strong onboarding hits: a success plan written in the customer's own language for what "working" looks like, a first meaningful usage event inside two to three weeks, and a checkpoint before the 30-day mark where you can catch drift early.

Weak answers describe a generic checklist, kickoff call, training session, check-in, with no mention of what success meant for that specific account. Interviewers want to hear the plan changed shape based on what the customer actually needed, not a template applied identically to every logo.

Name the specific blocker, a missing internal stakeholder, a data migration that stalled, a champion who went quiet, and what you actually did about it, not just that you "followed up." Interviewers listen for whether you escalated appropriately or sat on the problem hoping it resolved itself.

The strongest version of this story includes what changed afterward in how you run onboarding. An account that got stuck and taught you nothing reads as a story you haven't reflected on.

Separate what's actually fixable from what isn't. Sometimes the unhappiness is about a product gap you can't close alone, and the honest move is naming that clearly instead of promising a fix you can't deliver. Other times it's a mismatch between what was sold and what the product actually does, a sales handoff problem more than a CS one.

Strong answers include a moment of directness, telling the customer plainly what will and won't change, instead of an endless string of appeasement that both sides know isn't solving anything.

Name the actual friction point, a price increase the customer pushed back on, a champion who'd left with the new stakeholder questioning the whole contract, and what you brought to the table to turn it. Data on realized value, usage against the goals set at onboarding, tends to work better than a generic pitch on features.

The follow-up worth preparing for: what would you have done if that data hadn't existed? A CSM who can only save a renewal when the usage story is already strong is missing half the skill set.

Move fast to identify who's stepping into the gap, formally or informally, and get in front of them before the account goes quiet on its own. A new stakeholder with no context on why the product was bought in the first place is one of the more common, preventable causes of churn.

Strong answers describe rebuilding the business case for the new person specifically, not assuming the value that convinced the old champion transfers automatically. It usually doesn't, especially if the new stakeholder wasn't part of the original buying decision.

Own the outcome even when the cause sat elsewhere, an outage, a bug, a support ticket that sat too long before you knew about it. Customers rarely care whose team caused the problem. They care whether the person in front of them takes it seriously and follows through on the fix.

The part candidates skip: naming what changed afterward, not just apologizing. "I escalated it and got engineering to prioritize a fix" is fine. "I escalated it, got a fix shipped, and set up a recurring check on that specific account so it doesn't happen silently again" is stronger.

Combine usage data, login frequency, feature adoption breadth, not just any activity, with relationship signals, champion engagement, support ticket sentiment, QBR attendance, and commercial signals, renewal timing, expansion conversations happening or not. No single input tells the whole story on its own.

The follow-up interviewers almost always ask: what happens when the score says green but your gut says red? Strong candidates admit the score is a starting point, not a verdict, and describe overriding it based on direct conversation when the two disagree.

Gross revenue retention (GRR) measures how much recurring revenue you kept from existing customers, capped at 100 percent, it can only go down from churn and contraction, never up from expansion. Net revenue retention (NRR) adds expansion revenue back in, so it can exceed 100 percent if upsells outpace losses.

A team can carry healthy NRR while masking a real churn problem underneath, if a handful of accounts expand heavily while many smaller ones quietly leave. Candidates who can name that gap show they understand the metric instead of just reciting the formula.

Lead with the accounts at risk and the specific reason each one is at risk, not a portfolio-wide average that hides two accounts about to churn behind twelve healthy ones. Leadership needs to know where to intervene, not just where things stand on average.

Strong answers describe a consistent reporting cadence, weekly or biweekly, not ad hoc when something goes wrong, and a format that separates "here's the number" from "here's what I need from you," since a report with no ask attached rarely gets leadership's help.

Tie every slide to the outcome the customer cares about, not a vanity metric that flatters your product without meaning anything to them. A QBR built around "logins increased 12 percent" means nothing if the customer's own goal was reducing their support ticket volume.

The honest failure mode worth admitting: QBRs that turn into a status update read off slides nobody prepared for. Strong candidates describe sending an agenda in advance and asking the customer what they want covered, instead of assuming the standard deck fits every account.

Weight each renewal by actual risk signal, health score, champion engagement, contract terms, budget cycle timing, rather than treating every account as equally likely to renew until proven otherwise. A forecast that's just "all accounts renew unless flagged" tends to be wrong in both directions.

Interviewers push on accuracy here. If your forecast last quarter was off, say by how much and what you got wrong, since a candidate who claims perfect forecasting every quarter usually hasn't been doing this long enough to have been burned by it yet.

Renewal rate is the obvious one, but strong candidates name at least one input metric they can actually influence day to day, adoption breadth across their book, QBR attendance rate, time to resolve escalations, since renewal itself lags months behind the actions that actually drove it.

Candidates who measure themselves only on the trailing renewal number tend to describe a reactive year. Ones who track a leading input metric usually have a more concrete story about what they changed and why it mattered.

Tie the expansion conversation to a problem the customer has already told you about, not a quota you need to hit. A customer who's mentioned hitting a usage limit or asked about a higher tier's features has effectively opened the door themselves.

The trap candidates fall into: pitching expansion right after a rough quarter for the account, which reads as tone-deaf regardless of how real the opportunity is. Timing the conversation against the account's own health, not just the sales calendar, separates a good CSM from one purely optimizing for their own number.

Name the signal that told you the opportunity was real, not just that quota pressure made you try. A usage pattern bumping against a plan limit, a stated future need from a stakeholder, a champion asking directly what the next tier includes.

Strong answers include the actual size of the win and roughly how long it took to close, since a vague "I drove significant expansion" without a number tends to get an immediate follow-up asking for one.

Be honest about where it sits. Don't imply it's coming soon just to keep the conversation comfortable if that's not true. Customers remember specific promises, and a vague "we'll look into it" that never resurfaces damages trust more than a clear no would have.

The stronger move: find out what underlying problem the feature request was actually solving for, and see if a workaround or adjacent feature addresses it now, rather than letting the conversation end at "not on the roadmap."

Name the specific ask and who you had to convince, product, engineering, sometimes your own manager, and what evidence you brought. "The customer wants this" alone rarely moves an internal team. A pattern across multiple accounts, or a clear revenue number tied to the request, usually does.

The honest version of this story includes what happened when you didn't get everything you asked for, and how you communicated that outcome back to the customer without either overselling the win or hiding the loss.

Take partial ownership even if the failure sat partly with another team, sales overselling a feature, engineering missing a deadline nobody flagged in time. Interviewers want accountability, not a story that quietly blames someone else the whole way through.

The stronger answers name a structural fix, not just an apology to the customer. A shared handoff document, a recurring sync between CS and the team that dropped the ball, something that addresses why the miscommunication happened, not only that it did.

The request being reasonable is the point, this isn't about refusing an unreasonable ask, which is easy. It's explaining why a legitimate request didn't fit the roadmap, timeline, or contract terms, and how you delivered that no without real damage to the relationship.

Strong answers name what you offered instead, an alternative, a timeline for reconsidering, rather than a flat no with nothing behind it. A no with an alternative attached almost always lands better than a no on its own.

Bring pattern data, not individual complaints. One customer wanting a feature is an anecdote. Twelve accounts in a specific revenue tier all hitting the same limitation is a prioritization case product teams can actually act on.

Candidates who've done this well usually describe a recurring, structured feedback loop, a shared tracker, a monthly sync, rather than sporadically forwarding individual support tickets and hoping something sticks.

Bring the actual disagreement and the evidence you used to make your case, a usage pattern your manager hadn't seen, a direct comment from the champion that changed the read on the account. Pure deference reads as weak here. So does digging in regardless of what your manager knew that you didn't.

The most credible version of this story includes an outcome that wasn't simply "I was right the whole time." A moment where your manager's read turned out partly correct too tends to land better than a story where you're cleanly vindicated.

Name the actual mechanism you used to triage, not just "I worked harder." A ranked list by risk and renewal timing, a temporary reduction in QBR frequency for the healthiest accounts, delegating a specific task to support or an onboarding specialist.

Interviewers listen for whether something genuinely got deprioritized and whether that choice held up. A candidate who claims nothing slipped during an overload period is either describing a manageable workload dressed up as a crisis, or not being fully honest about what actually happened.

Honest answers admit the load is genuinely hard some quarters rather than performing endless resilience. What separates a strong answer is naming a specific coping mechanism that's actually about the work, reprioritizing which accounts get proactive attention versus reactive-only, looping in a manager for support earlier than pride might suggest.

I don't have great data on how this varies by company size or CS team maturity, smaller teams with no backup probably feel it harder, but the honest answer here matters more than a polished one.

This question rewards honesty over flattery. A candidate who claims every customer, including the hardest one, would give a glowing review is harder to believe than one who admits the relationship was tense but describes specifically what held it together anyway, responsiveness, follow-through, honesty about limitations.

Interviewers are checking self-awareness as much as the actual answer. Naming a real tension and how you managed it says more than a flawless account of universal customer love.

The handoff should happen before the kickoff call, not during it. I want a written document from the account executive covering what was promised, any custom terms, timelines, or integrations the customer was told about, who the stakeholders are and what each one cares about, and any land mines, like a bad previous vendor experience or a technical requirement that almost killed the deal. Without that, the kickoff call becomes the first time the customer discovers whether their AE and their CSM are actually on the same page, and customers notice immediately when they aren't.

On the call itself I set the agenda before it starts: confirm the success criteria the customer and sales agreed to, walk through the mutual action plan with dates, and identify the internal owner on the customer's side accountable for hitting their milestones. I also try to get the AE on the first five minutes, not the whole call, just enough to hand off credibility and then step aside, because customers trust the CSM more when the person who sold them the deal visibly vouches for them.

The gotcha most teams hit is treating the handoff as a Slack message with a link to the CRM record. A CRM record has notes, it doesn't have judgment. An AE knows things about how a stakeholder reacted in a demo that never make it into a form field. I've had onboarding go sideways specifically because a promised integration timeline lived only in the AE's head and showed up as a surprise blocker in week three.

The first message needs to go out fast, even without a confirmed root cause, because silence during an outage damages trust more than the outage itself does. I send an initial notice within the first fifteen to thirty minutes acknowledging the issue, what we know so far, and when to expect the next update, even if the honest answer is that we don't know the cause yet and the next update is in thirty minutes.

For high-touch accounts I follow up with a direct message or call, not just a link to the status page, because an executive sponsor who learns about a major outage from a public status page instead of from their CSM will remember that. I also hold back from promising a fix time before engineering has confirmed one, because a missed ETA during an incident does more damage than a longer but accurate one.

After resolution, the postmortem matters more for retention than the outage itself did. I want a written summary of what happened and what we're doing to prevent recurrence, and I bring that to the account proactively instead of waiting for the customer to ask for it. Accounts that get a clear, honest postmortem often come out of an incident with more trust than before it, because they've seen how the company behaves under pressure. Accounts that get silence or vague reassurance use the incident as ammunition at renewal time.

Compare against a baseline, how long onboarding typically takes for accounts of similar size and complexity, instead of trusting gut feel alone. A slow enterprise rollout with a complex integration is expected. The same timeline on a simpler, self-serve-adjacent product is a signal something's wrong.

The honest answer admits this is judgment, not a formula. Good candidates name at least one specific tell they watch for, logins from only one person on a team account, a champion who stops answering scheduling requests, rather than claiming a clean rule that always works.

Usage data first: a drop in login frequency, a key feature that stopped getting used, a champion who's gone quiet across every channel. But usage data alone misses a lot, sentiment shifts in QBRs, a reorg on the customer's side, a budget conversation happening one level up nobody told you about.

Strong candidates describe combining both, a health score built from usage plus a habit of asking direct questions in every check-in, how's this looking from a budget standpoint next quarter, rather than waiting for the customer to volunteer bad news.

This is the question nearly every CSM interview eventually reaches, and it's the one where polished answers actually hurt candidates. Name the specific moment you missed, not a vague "the relationship soured." A usage drop you didn't act on for six weeks. A champion change you learned about from a cancellation email instead of catching it yourself.

What separates a strong answer isn't avoiding blame, it's naming exactly what you'd do differently with the same information today. Interviewers who've run a lot of these loops can usually tell within thirty seconds whether the failure was actually processed or just recited.

Look at whether the gap is something you can close, a product limitation, a budget cut, a stakeholder who's already decided, versus something genuinely still in motion. Fighting for a renewal that was decided three months ago wastes time you could spend on accounts where the outcome is still open.

This is one of the harder judgment calls in the role, and admitting that upfront tends to read better than pretending every account is winnable with enough effort. Interviewers want a CSM who can read the room, not one who treats every loss as a personal failure to fix indefinitely.

Good answers name something specific and slightly unusual, support ticket sentiment trending negative even while resolution times stay fast, or a drop in the breadth of feature usage even as overall login frequency holds steady, meaning the account is narrowing to a smaller slice of the product than it started with.

This question rewards candidates who've actually built or tuned a health score model themselves, since the overlooked indicators tend to come from someone who's watched a churn happen despite the standard dashboard looking fine.

Triage by actual business impact and urgency, not by who emailed loudest or who's most senior on the customer side. A P1 outage affecting a large account's production usage outranks a feature-confusion ticket from a smaller one, even if the smaller account's contact is more insistent.

Strong candidates admit they can't personally handle all three at once and describe how they delegate or loop in support and engineering fast, rather than claiming they solo-handled three simultaneous fires without help. That claim rarely survives a follow-up question about specifics.

Get honest with the customer early rather than letting the gap surface on its own during onboarding, which damages trust worse than an upfront conversation about what the product actually does and doesn't do. Customers respect a CSM who resets expectations clearly more than one who lets a mismatch fester.

Internally, this is also a feedback loop worth naming. Strong candidates describe flagging the pattern to sales leadership if it's recurring, not just fixing it account by account forever without addressing the root cause.

Deliver it plainly and early. Don't bury bad news inside a longer update hoping it gets lost. Customers who find out a problem was known internally before they were told tend to react far worse than customers told directly and promptly, even when the underlying issue is identical.

The part worth naming honestly: sometimes there's genuinely nothing you can offer beyond acknowledgment and a timeline. Candidates who admit that, instead of manufacturing a fake concession to soften the blow, tend to come across as more trustworthy in the room.

Neither role cancels the other out, but candidates who describe themselves purely as "the customer's voice" internally usually haven't had to deliver an unpopular company decision to a customer they've built real trust with. The job requires holding both directions honestly.

The strongest answers name a specific moment where the two pulled in opposite directions, what the company needed versus what the customer wanted, and how that specific tension actually got resolved, not a general philosophy about balancing both sides.

Name what specifically made them skeptical, a bad prior experience, a competing tool they preferred, a promise from sales that didn't hold up, and what you actually did to address that specific concern rather than a generic charm offensive.

Strong answers include a moment where the skepticism was at least partly fair, and how you responded to that instead of dismissing it. A story where the skeptic simply comes around with no real substance behind it tends to read as rehearsed.

First I'd pull the actual inputs that fed the green score on each churned account and check them against what was really happening in the weeks before the churn decision. Nine times out of ten the root cause is one of two things: the score weights login-based usage too heavily, which can stay green even as engagement hollows out, because a champion still logs in daily out of habit while quietly evaluating a competitor. Or the score has no input at all for relationship health, like champion turnover or executive sponsor changes, because that data doesn't live in a system the score pulls from.

Second, I'd check the score's update frequency against the actual decision cycle. A health score that recalculates weekly off a rolling 30-day usage window can still show green for a customer who made the churn decision internally two months earlier and simply hasn't told anyone yet, because a decision to leave and a change in product usage are not the same event and don't happen on the same timeline. If the score lags the real decision by more than a renewal cycle, it's descriptive of the past, not predictive of the future.

Third, I'd check whether the score conflates account types under one formula. A score built and validated on a mid-market segment usually breaks when applied unmodified to enterprise accounts, where a single stalled integration or a reorg on the customer's side can sink an account that still shows healthy day-to-day usage everywhere else. The fix usually isn't more weight on the same inputs, it's a qualitative override layer, a required CSM check-in on any account above a revenue threshold regardless of what the automated score says, because the biggest and most complex accounts are exactly where a purely quantitative score is least reliable. I'd also go back and manually tag what actually caused each of the three churns, and if none of those causes show up as a variable in the model at all, that's the real finding: not a scoring threshold problem but a missing-input problem.

Start qualitative before quantitative. With no historical churn data to validate a model against, a purely numeric score is a guess dressed up as math. Interview the CSMs and sales team about what they already believe predicts risk, then build a simple weighted model around those signals and validate it against the first few renewals as they happen.

The honest admission worth including: the first version will be wrong in places, and that's fine. The mistake is treating it as final instead of revisiting weights once real renewal outcomes start confirming or contradicting them.