Risk, objections and escalation
Objective. Handle the five recurring account risks - low trust, low adoption, sponsor change, disputed metrics and a technical blocker - with a recovery plan and an escalation record that names a responsible owner, so risks are managed deliberately rather than hoped away.
Every account hits trouble; the ones that churn are the ones where the CSM saw it, worried about it, and did nothing structured. This lesson gives you a recovery response for each of the five common risks and teaches you to write an escalation record with a named owner and a date - because a risk without an owner is a risk nobody is actually managing.
See it in the demo
The customer problem
Risks rarely announce themselves as 'churn'. They show up as a sponsor who stops replying, a team that quietly stopped using the product, an analyst who disputes a number in front of others, or a blocker that IT keeps deprioritising. Left unmanaged, each compounds: low trust depresses adoption, low adoption removes the value story, a sponsor change erases the relationship that carried it, a disputed metric poisons every future number, and a technical blocker makes the whole thing feel not worth it. Business impact: the cost of a save at renewal is enormous compared with the cost of a structured intervention when the risk first appears. The discipline is to name the risk, choose the matched recovery, and assign an owner - not to reassure yourself it will sort itself out.
How Time Champ addresses it - matched recovery by risk
Match the recovery to the risk type. (1) Low trust: usually rooted in a data problem - run the C02 validation and C05 discrepancy discipline publicly, so the customer sees you find and fix the cause rather than defend the tool. (2) Low adoption: diagnose the layer with C07 before acting; the fix depends on whether it is entitlement, config, usage, routine or outcome. (3) Sponsor change: re-run the C01 diagnosis with the new sponsor - do not assume the old success plan still has an owner; a new sponsor needs their own stake and baseline. (4) Disputed metric: do not win the argument, run the C05 investigation and agree a standard definition; a conceded, agreed definition beats a defended number. (5) Technical blocker: validate it is real and in scope, then escalate to the specialist/product owner with evidence rather than attempting setup beyond your literacy (C02). Each recovery leans on a skill you already have; the new thing is doing it deliberately and recording it.
What to say / do - recovery plan and escalation record
For any live risk, write a short recovery plan: the risk named specifically (not 'account at risk' but 'sponsor left, no replacement identified, success plan has no owner'), the matched recovery actions, the owner of each action, dates, and the trigger that would escalate further. Then keep an escalation record for anything beyond your scope: what the issue is, what evidence supports it, what you have tried, who it is escalated to (named person, not 'product team'), when, and what resolution is expected. The named owner is the point - 'escalated to product' owns nothing; 'escalated to [named specialist], acknowledged, target Friday' is managed. Talk track to an internal escalation: 'This is a technical blocker on [account], evidence attached, it blocks the agreed milestone, I need you to own resolution by [date] - can you?' Confirm ownership explicitly; an unacknowledged escalation is not an escalation.
Objections and honest limits
A disputed-metric objection handled well: 'You may be right that our number looks off - let us not argue it, let me walk the definition and denominator with you and agree the one we will both use.' A low-trust objection: 'I would rather show you exactly how the data is produced than ask you to take it on faith.' A sponsor-change reality: resist carrying on with a plan the departed sponsor owned; it is now unowned and must be re-established. Honest limits: you own the relationship and the recovery coordination, but a technical blocker or a capture/integration fix is a specialist job - escalate it with evidence rather than guessing, because a wrong fix deepens the risk. Do not over-promise a resolution date you do not control; commit to driving it and to a named owner, and be honest with the customer about what is in your hands versus the specialist's. Never bury an unresolved risk in optimistic status updates - an undocumented risk is one nobody is managing.
Reading risk signals honestly
Calibrate risk the way you calibrate metrics (C05): a quiet sponsor is a signal to investigate, not yet a verdict; low usage of a non-success-plan feature is not a real risk (C07); a disputed number may be a definitional difference, not a failure. Equally, do not under-read: a technical blocker the customer has raised twice is already a trust risk even if the data looks fine. The escalation record is also your honesty mechanism - if you cannot write the risk specifically with evidence, you probably have not diagnosed it, and a vague escalation produces a vague response. Where the root cause is uncertain, say 'under investigation' and escalate the investigation, rather than asserting a cause you have not confirmed or confirming a fix with the customer before product has verified it.
Interpretation check
A risk is only managed once it has a specific name, a matched recovery and a named owner with a date. An escalation to 'the product team' with no acknowledged owner is a worry you have written down, not a risk you are managing.
In the field
KnackGlobal under ProHance attack is a live trust-and-metric risk: a disputed output-per-FTE number must be handled by agreeing the definition (C05), not defended, and any capture blocker escalated with evidence to a named specialist - an unmanaged dispute here is exactly the opening the incumbent wants.
Practical task
Pick two of the five risks (low trust, low adoption, sponsor change, disputed metric, technical blocker) as they might appear on KnackGlobal or OVO. For each, write a recovery plan (specific risk statement, matched recovery actions, owners, dates, escalation trigger) and, for the one needing it, an escalation record with a named owner and confirmed target.
Self-check
A sponsor leaves and no replacement is named. Why is continuing the existing success plan the wrong move?
The plan's owner is gone, so it is effectively unowned. You must re-run the C01 diagnosis with the new sponsor to give them their own stake and baseline, or the account drifts with a plan nobody is accountable for.
An analyst disputes a metric in a meeting. What do you do instead of defending the number?
Run the C05 investigation openly - definition, denominator, scope - and agree a single standard definition going forward. A conceded, mutually-agreed definition rebuilds trust; winning the argument loses it.
What makes an escalation record actually managed rather than just logged?
A named, acknowledged owner (a person, not 'product'), supporting evidence, what you have already tried, and a target date you have confirmed with that owner. An unacknowledged escalation is not an escalation.
Why should low usage of one feature not automatically be logged as an account risk?
If that feature was never part of the agreed success plan (C07), its low usage is irrelevant to the outcome. Logging it as risk triggers the wrong intervention and distracts from real risks.
Verified vs demo. The validation and investigation surfaces are demo-shown. Resolution of a real technical blocker depends on specialist/product action and timelines you do not control - commit to driving and to a named owner, and flag uncertain causes as 'under investigation / confirm with product'.