---
name: customer-success-save-plan-author
description: "Load when a Customer Success leader (CSM, CS Manager, Director, VP CS) pastes a confirmed at-risk account packet — containing at minimum ARR, renewal date, notice clause, and some combination of usage telemetry, stakeholder map, or support history — and asks for a save plan, a reclassification recommendation, a formal-notice response, or a refusal. Returns a seven-section intervention plan sized to the true opt-out window, a structured refusal naming missing signals, or a scoped recommendation when a specific question was asked. Do not load for churn scoring, QBR authoring, or renewal forecasting."
---

# What Changed, and When

A CS Director reads this and then spends their team's next weeks on it. A plan that opens with the wrong meeting, or runs a six-week arc inside a two-week window, has spent the one save window the account had on the wrong intervention. Two rules govern everything below. **The packet is the whole of the evidence** — what you know about this industry or this kind of buyer helps you read the wording in front of you and never supplies a fact, a name, a disposition or a number. And **the deadline shapes the plan, the classification fills it**: nothing downstream is written until both are settled, in that order — and nothing at all is written until the packet has been checked for what it can carry (see *Which deliverable the packet can carry* in `references/classification-guide.md`). The method is the same whatever the packet holds — a merger that reshuffled the buyer's reporting line, a budget freeze, a champion promoted into the buyer's seat, a multi-year agreement with an annual opt-out, usage rising while sentiment falls, two products on one paper with different anniversaries — because it reasons from dates, people and evidence rather than from a list of situations.

## Step one is arithmetic, not diagnosis

The save window is the number of days between today and the last day the customer could still deliver non-renewal notice — never the number of days to the renewal date, which is a deadline the customer cannot use.

**Save window = days to renewal − days of notice the contract requires.** Show the subtraction on the page every time, and subtract once: the notice period comes off the days to renewal, never off a window already computed.

Before subtracting, read every contract line in the packet, because the notice period quoted first is not always the one that governs: contracts qualify their own headline terms, and a qualification that applies to this account applies. Use the period that actually binds this customer, and say in one line why it is that one. The longer notice governs whether or not anyone on our side has read that clause lately.

Every phase, trigger and success date is counted from today, and the final commitment date sits before the deadline. The deadline itself is internal knowledge, never disclosed in an executive call: a buyer who learns the notice deadline is close shifts from partnership to negotiation.

## Classification: what changed, and who is complaining

**Step zero: who is in the room.** Before classifying, name the customer person the Week 1 meeting would be held with — the name that will sit in the snapshot's *Contact in post* field. If the packet names nobody still in post, there is no meeting to plan and no classification to make; the document is the refusal described under *No reachable contact* in `references/classification-guide.md`, written as a refusal under a refusal's heading, without a snapshot section or an *In brief*. A classification carrying the word "blocked" is a refusal that has not admitted it.

Exactly one of four root causes drives the plan, and choosing it is the load-bearing decision: the Week 1 opener, the midpoint question, the escalation triggers and the executive brief all branch on it. The wrong opener forecloses the save, because the first meeting tells the customer whether we understand their situation.

So run the **people test before the product test.** Take every person in the stakeholder map and write down what happened to them in the window: departed, replaced, went quiet, arrived, changed role. Then ask who is doing the complaining.

Read `references/classification-guide.md` for the full four-type decision rules, the two-question product-gap test, opener scripts, the deliverable-routing checklist, and all extended case handling before writing the classification.

### Writing the call

**Conditional classification.** When one Week 1 conversation could flip the call — a new stakeholder nobody has met, a procurement inquiry nobody can explain — say so: name the conversation, run it in Week 1 in parallel with the opener, and state what happens if it reveals an evaluation. At high ARR an evaluation revealed that way is a same-day CRO event, not a midpoint one.

**Never invent status.** A contact marked active in CRM whose last logged interaction is many weeks old has an unknown status. Say the CRM record cannot be taken at face value, make verification the first action, and branch Phase 2 on the answer. The packet's log is the record in the other direction too: a champion whose last logged call is recent is in contact, and only outreach the packet says went unanswered counts as silence; tickets belong to whoever the packet says filed them, never to a newcomer by assumption.

## The plan follows the call

**The midpoint gate** is one binary question tied to the root cause, answered by a named customer person's written confirmation — end of Week 4 on a standard play, Day 7 or Day 10–14 on a compressed one; **Yes** moves to Commit and activates the AE, **No** escalates the same day and tables a commercial lever (an SLA credit, a services engagement, a month-to-month bridge) beside an exec-to-exec call. **Success criteria** are four or five numbered, account-specific lines: the written confirmation, the utilization threshold with a date, the renewal signed before Day N, the secondary stakeholder engaged, the flag that did not escalate.

## Escalation calibrated to what the account is worth

One table — **Trigger | Escalates To | Action** — of four or five rows, triggers as day ranges from today, the last row always the deadline itself: opt-out imminent, no commitment; CRO or VP CS with Legal; month-to-month bridge or emergency extension; planned churn workflow if declined. An italic line above it states the ARR and why the ceiling sits where it does. **Under roughly $100K:** the CS Manager owns it, VP CS is the ceiling and only if the midpoint fails or an evaluation is announced; CRO and CEO never appear. **$100K to $750K:** VP CS at midpoint failure, from Day 1 when compressed; CRO only about seven days before the deadline; no CEO. **$750K to two million:** VP CS and CRO briefed from Week 1, CRO in the room at midpoint failure, CEO briefed — not a call — about a week out. **Above two million:** CRO mandatory at midpoint failure, a CEO-to-buyer call about two weeks out, multi-year the target; an active RFP is a same-day CRO escalation.

## Putting it on the page

Only two first lines are legal — *## Account Save Plan — <account>* when someone is in post, or *## Refusal — classification blocked: <reason>* when nobody is or the signals cannot separate the causes — and the two shapes are never mixed: a refusal is the heading, the window arithmetic as its first line, three or four sentences on why, a numbered list with due dates, one closing line on what will not be produced, under three hundred and fifty words, with no snapshot, no *Contact in post* line and no *In brief*.

Read `references/page-template.md` for the seven-section plan template, phase table, midpoint gate, exec-brief format, and `references/worked-examples.md` for four annotated miniatures before drafting.