Every CSP ships a success plan module. It is also, consistently, the least-adopted module in the deployment. Not because your team lacks discipline. Because a plan that needs manual maintenance decays fastest on exactly the accounts that need it most. So we rebuilt it with no status fields, no percent-complete, and nothing anyone can set to green.
A CSM opens the plan the week before a QBR. Last status change: March. It is August. She reconstructs five months from memory, in twenty minutes, under deadline, for a form whose only reader is a slide. Nothing she enters is false. All of it is a guess.
Look closely at what the plan record actually carries. Not observations. Declarations, made under pressure, by the one person whose manager reads the result.
A CSM under renewal pressure sets a picklist, and the system takes her word for it. That is not a character flaw. It is what happens when anyone grades their own work in a field their manager reads.
The progress bar measures the fraction of tasks someone marked done. A CSM can close every task on an objective the customer quietly abandoned, and the bar reads one hundred percent.
A CSM writes plausible outcomes after a kickoff call. The customer nods once in a meeting and never sees the record again. The plan describes what the vendor hoped would matter.
The pricing thread that ran three months. The sponsor who stopped replying in April. The security review blocking your integration since February. All of it is in the record. None of it is in the plan.
Nowhere in this artifact does a human declare how something is going. No picklist, no health field, no last-reviewed date. Each was considered and rejected for the same reason: a field a human sets is a field a human sets under pressure.
A number gets optimized. Give a team a composite and within two quarters the composite is what gets managed, not the account. Per-criterion verdicts with evidence attached resist gaming, because there is nothing to move except the underlying reality.
A human decides what a safe renewal looks like. That is the one judgment in the whole system that is genuinely not derivable, and pretending otherwise would be the most dangerous thing the artifact could do. You write the criteria once. The plan measures every account against them.
Where the account stands. What is moving and what is stuck. What you owe them. Who is in the room. What to worry about. It just never asks anyone what they think.
Each criterion had to pass one test to earn a place: can communications alone answer it? A criterion that needs telemetry or survey scores renders permanently gray, no matter how good it looks in a playbook.
A CSP records tasks: things your team assigned itself inside the tool. What it structurally cannot record is the promise your solutions architect made in an email on the seventeenth. That promise was made where work is actually agreed, and it never entered the system. The register extracts those. Both directions, from full message text, vendor-side first, overdue at the top.
A commitment is never marked fulfilled on the promiser's own later assertion. You need the artifact, or the other party's acknowledgment.
A vendor writing "as discussed, we sent that over" is not evidence that anything was sent. Without this rule, the register quietly reverts to self-reported status: the thing this entire system exists to remove.
Our team offered, in writing, to correct an inconsistency in a data scope document before it went to the customer's security review. Twenty days later the correction had never been sent, and the customer had already forwarded the document onward.
We recommended the customer decide whether to retain or purge a set of records. No owner was ever named on either side, and the question sat open inside an active security review while both parties assumed the other had it.
The full paper includes Appendix A: the literal project instruction set, pre-configured with the five default criteria and the render template contract. Paste it into a Claude project, connect Sturdy over MCP, type an account name. Running in under an hour.
# Derived Success Plan: Project Instructions **Requires:** Sturdy connector (tenant instance) and Salesforce connector. Read-only: nothing is created, updated, or deleted in any system. ## CONFIGURATION BLOCK ══════════ EDIT BELOW THIS LINE ══════════ STATUS: CONFIGURED DEFAULT_MODE: brief MODE_PROMPT: on RENEWAL_CRITERIA: - id: C1 name: Economic sponsor is present good_looks_like: A contact with budget authority (VP or above, or someone named as an approver) authored a message within the last 45 days. evidence_cues: VP, SVP, Chief, Head of, Director, sponsor, budget, approve, sign off, procurement - id: C2 name: We are keeping our promises good_looks_like: No vendor commitment open past 14 days, and no thread where the customer spoke last has gone unanswered past 10. evidence_cues: I'll send, we'll get, following up, any update, still waiting, circling back...
Get the full whitepaper PDF, the paste-ready instruction set, and the hosted render template. Then do the exercise that actually validates it: open the commitment register on an account you know and check the vendor-side rows against your own memory.
Download the whitepaper PDFInstructions land in your inbox. Run them against your own accounts today.