Trace every health score change to a named owner

The operational risk around health score

When health score crosses a shift or a time zone, the next person may inherit a tidy summary that hides the missing QBR packet, the unresolved question, or the owner who never replied. The practical consequence is incomplete onboarding, and the first sign is often a question from CSM that nobody can answer from the record. Treat the health score as a closed loop rather than a message: every action needs a source, a boundary, a destination, and a time. The risk is highest when the health dashboard looks current but the QBR packet behind it was never opened.

The health score queue rarely fails in a dramatic way; it usually drifts when a familiar request arrives and the operator copies the previous outcome instead of reopening the onboarding tracker. The cost shows up later as a reopened case, an unexplained escalation age change, or a correction that takes longer than the original task. The control should make the health score path readable from the request, the escalation record, the named owner, the decision, and the confirmation in the onboarding tracker. The operator should be able to point to the exact field in the onboarding tracker that will change, not only to the message that requested the change.

Evidence map for health score

Start the evidence map by naming the field in the onboarding tracker that the health score action is supposed to change. When two escalation record versions conflict, preserve both and route the conflict to account executive; do not silently choose the cleaner-looking value. If the onboarding tracker and the escalation record disagree, stop the dependent action and record both values with the time each was observed. A late escalation record is still evidence, but it should not be presented as if it existed at the time of the first decision.

Record the renewal risk memo and the time it was observed, because a later screenshot cannot prove what the record said when the first action was taken. If the renewal risk memo contains sensitive data, store it in the approved location and record only the minimum reference needed for the health score review. Keep an exception note that explains which value was used, which was rejected, and why; a later reviewer should not have to infer the choice from the final number. The evidence map should show which fields are required, which are conditional, and which may be marked unavailable.

If CSM supplies the instruction, keep the instruction and the underlying usage report together rather than replacing one with a summary of the other. If the usage report contains sensitive data, store it in the approved location and record only the minimum reference needed for the health score review. A conflict is not a reason to rewrite history; it is a reason to show the reviewer exactly where the health score record stopped agreeing with itself. The evidence map should show which fields are required, which are conditional, and which may be marked unavailable.

Decision rights for health score

Renewal owner may prepare, compare, label, and route the health score, while CSM keeps the decision that changes the destination record in the support desk. The approver may accept, reject, or ask for more evidence, but the response should be recorded in the health score case rather than left in a chat. Record the approval in the health score case with the approver, the time, the scope, and the evidence reviewed. A standing approval should have a limit, a review date, and a clear description of the health score work it covers.

For customer success work, the safest split is preparation by the operator and judgment by the accountable owner, with both actions visible in the QBR template library. A decision right is not the same as system access; the operator may be able to edit a field without being authorized to decide its value. Record the approval in the health score case with the approver, the time, the scope, and the evidence reviewed. A standing approval should have a limit, a review date, and a clear description of the health score work it covers.

Daily workflow for health score

Before adding a new health score item, check whether the request already exists under another name or channel. For each open health score, record the source, the usage report, the decision, and the destination field before moving to the next item. Before the shift ends, reconcile the health score queue and write a carryover note for every item that is still open. If the queue is too large to review, split it by risk or channel rather than sampling only the newest items.

The daily health score routine should begin with a queue count by owner and age, not with the easiest request in the inbox. When a request changes scope, stop the old action, record the change, and route the new scope before continuing. Close the day by checking that each completed health score has a destination update in the renewal forecast and a confirmation for the requester. At the end of the day, compare the open queue with the morning list and explain every unexplained difference.

Use the same health score queue for new work, corrections, and reopened cases so the daily count reflects the real load. Keep the health score case note short enough to read during the day and specific enough to survive a weekly review. Record any correction made during the day and link it to the original health score record. A daily stand-up should review exceptions and aging items, not read every completed ticket aloud.

Exception handling for health score

Do not let an exception close because the requester stopped asking; keep the case open until the evidence or the decision is resolved. An escalation that ends in silence should remain open; silence is not approval. A stop is not a failure of service; it is the control working before the error reaches CSM. The escalation packet should be short enough to read on a phone and complete enough to decide without a meeting.

If the exception comes from a system outage, record the workaround, the temporary identifier, and the reconciliation owner. If the owner asks for more evidence, record the request, the due time, and the person responsible for obtaining it. If the exception affects unlogged escalation, pause the dependent action until support lead decides and the decision is recorded. Reason codes should be short enough to use at the queue and specific enough to route the case to the right owner.

Classify exceptions by whether the work can continue, must pause, or needs an immediate owner decision. Send the exception to the named owner with the QBR packet attached and a specific question, not a general request to review. Record the stop time, the reason, and the release decision so the delay can be reviewed without guessing. Reason codes should be short enough to use at the queue and specific enough to route the case to the right owner.

Close and verify health score

If the destination is another team, the health score is not closed until that team acknowledges the handoff. A quality check that only reads the close note cannot detect a destination that never changed. The reopen reason should use the same reason codes as the exception queue so patterns are visible. A close note should name the evidence reviewed and the person who confirmed the result.

A sent message, a closed ticket, or a verbal yes is not proof that the health score outcome reached the record. Use a second reviewer for high-risk health score closures, and record the review even when the result is accepted. When the same health score reopens repeatedly, review the intake, the QBR packet, and the approval boundary rather than only the final step. If the destination is a downstream team, keep the health score open until that team acknowledges receipt.

Review cadence for health score

Use the same checklist each week so health score freshness can be compared without renegotiating the definition. Pair speed measures with evidence measures so a faster health score queue does not hide missing QBR packet or weak approvals. Escalate a repeated high-risk health score gap to customer success leaders with the case evidence, not only a summary count. Review at least one case handled by a backup owner and one that crossed a time zone.

Pick the sample from the onboarding tracker, not from the cases the team remembers, so the review is not biased toward easy work. Use the correction log to estimate rework, and separate corrections caused by source errors from those caused by judgment. Record the decision to accept the risk when the team chooses not to change the process; an explicit acceptance is better than an invisible workaround. Review at least one case handled by a backup owner and one that crossed a time zone.