Rescue Ledger template
The chapter “Unplanned Help Weakens the Evidence” explains why. Keep the ledger during trials, demos, onboarding, implementation, UAT, and early use. One line per intervention is enough.
| Date | Account or participant | Path stage | Who stepped in | Category | Planned or unplanned | What they did | Minutes | Severity | Build in, price as service, or leave? | Reveals a wrong ICP assumption? | Reveals a false promise? |
|---|---|---|---|---|---|---|---|---|---|---|---|
Categories
Use these eight and no others, so counts compare across tests.
| Category | Meaning |
|---|---|
None |
The participant proceeded without help. |
Clarification requested |
The participant asked what a term or screen meant and got an answer. |
Navigation hint |
Someone pointed to where a control is. |
Domain explanation |
Someone explained a concept the product assumes the user knows. |
Technical rescue |
Someone fixed an error, environment, or compatibility problem. |
Setup rescue |
Someone configured, imported, or connected something for the customer. |
Workflow rescue |
Someone showed how to fit the product into the real workday. |
Operator override |
Someone did the task for the participant, or changed the system to make it pass. |
Planned or unplanned. A planned rescue is designed, priced, and disclosed, such as a paid onboarding call. An unplanned rescue is help nobody designed or priced. Planned help is service. Unplanned help is what to look for.
Reading the ledger
Read counts as clues and not as verdicts.
-
Count interventions by stage. A stage with a rescue in most accounts often marks a product gap, though it can also be an implementation the customer expects.
-
Count by segment. A rescue confined to one segment is often an ICP problem.
-
Count by claim. A rescue that every demo needs points to a promise problem.
-
Separate intended service from hidden rescue. If the product is sold with implementation, label that work as service, and price it.
Rules
-
The ledger measures the path and not the person. Report it by stage and never by rescuer.
-
Customer success owns the entries and sees the findings first.
-
Log one cohort or a window of about six weeks, then stop.
-
Have a second reader check a sample, since the rescuers write their own entries.
Who should write entries
Everyone who can step in: salespeople, sales engineers, implementation staff, customer success, support, product managers, engineers, administrators, executive sponsors, and consultants. Add a required field to the CRM, the support system, and the onboarding checklist so the entry is made when the help is given.