Run a weekly quality sample on health score

The operational risk around health score

A customer success team can look responsive while the health score trail is too thin to support a correction, a customer answer, or a review by CSM. Without a visible owner, the request can sit in a shared inbox while everyone assumes someone else has checked the support desk. The operating standard should distinguish preparation from approval and show both in the same health score trail. A familiar vendor, member, candidate, or client name is not evidence that the underlying health score value is still valid.

A busy customer success desk can process dozens of health score requests in a day and still leave customer success leaders unable to explain which request was approved, which was only discussed, and which was never entered. The team may also overstate QBR completion, because a closed status is counted before the health score note and the destination update are verified. Use the QBR template library as the destination of record, and use the health score note to prove what the operator saw before making the change. At Customer Success Managers, the first check is whether the request is a new health score or a correction to a case that is already open.

Evidence map for health score

The health score evidence set should include the request, the health score note, the owner decision, the action taken, and the final value in the QBR template library. Keep the original health score note and the corrected version side by side, with the reason for the change and the person who approved it. After the conflict is resolved, add a short correction entry to the health score log and link it to both source versions. A late health score note is still evidence, but it should not be presented as if it existed at the time of the first decision.

For health score, the governing source is the renewal forecast; a note in the queue is only a pointer to that source. When two QBR packet versions conflict, preserve both and route the conflict to customer sponsor; do not silently choose the cleaner-looking value. If the renewal forecast and the QBR packet disagree, stop the dependent action and record both values with the time each was observed. Record the source identifier and the extraction time when the value comes from the renewal forecast.

For health score, the governing source is the CRM; a note in the queue is only a pointer to that source. When the escalation record is missing, write missing rather than leaving the field blank; missing, unavailable, and confirmed negative are different states. If the CRM and the escalation record disagree, stop the dependent action and record both values with the time each was observed. The team should test one health score case each week by reconstructing it from the evidence map alone.

Decision rights for health score

Write the health score boundary in plain language: which systems the operator may touch, which fields may change, and which questions must go back to CSM. 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. Review a sample of approvals each month to confirm that the named role still matches the current customer success process. For high-risk health score work, require a second reviewer who is not the person who prepared the packet.

The approver should see the evidence packet, not a paraphrase that removes the conflict or the missing escalation record. The health score task should say what the operator may do without asking and what requires a fresh decision. The approval record should point to the escalation record that was reviewed, not only to the request that started the work. When the operator is unsure whether a change is preparation or judgment, the safe default is to pause and ask.

Daily workflow for health score

A short morning pass should identify missing escalation record, stale approvals, and items that crossed a time zone without acknowledgment. When the next step belongs to account executive, write the request and the due time instead of leaving the case in a waiting state. Use the final queue count to test the day’s renewal risk lead time; a lower count achieved by hiding open items is not progress. If the queue is too large to review, split it by risk or channel rather than sampling only the newest items.

Before adding a new health score item, check whether the request already exists under another name or channel. Keep the health score case note short enough to read during the day and specific enough to survive a weekly review. Before the shift ends, reconcile the health score queue and write a carryover note for every item that is still open. A case with no next action should be treated as an exception even if its status is marked in progress.

A short morning pass should identify missing usage report, stale approvals, and items that crossed a time zone without acknowledgment. For each open health score, record the source, the usage report, the decision, and the destination field before moving to the next item. Close the day by checking that each completed health score has a destination update in the onboarding tracker and a confirmation for the requester. When a case moves between owners, require an acknowledgment before the old owner stops watching it.

Exception handling for health score

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. A stop-work rule should name the trigger, the person who can release the work, and the evidence needed to restart. A stop-work decision should be visible to the requester so they know why the health score work is paused.

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 support lead. A workaround used during a the onboarding tracker outage should have an expiry time and a reconciliation owner.

Track repeated exceptions separately from one-off errors; a pattern may point to a form, a queue rule, or a permissions problem. When the decision is urgent, call out the consequence of waiting and the last safe time to act. If the exception affects incomplete onboarding, pause the dependent action until account executive decides and the decision is recorded. Do not close an exception because the customer stopped replying; record the last contact and the next attempt.

Close and verify health score

Use the same close definition for routine and exception cases so the health score freshness does not improve by redefining completion. Use a second reviewer for high-risk health score closures, and record the review even when the result is accepted. A reopened case should show what changed, who noticed it, and which earlier decision is now in question. Closed cases should remain searchable by object, owner, date, and source so a later correction can find them.

The close condition should name the field, the expected value, the approver, and the time of the final check. Compare the onboarding plan, the approval, and the final value in the support desk before marking the health score complete. Close the reopened case only after the destination record and the requester confirmation agree. If the final value differs from the approved value, record the variance and the person who accepted it.

Review cadence for health score

Pick the sample from the support desk, not from the cases the team remembers, so the review is not biased toward easy work. Compare renewal risk lead time before and after a process change, using the same definitions and observation window. Keep the review notes with the health score batch so the next owner can see why the procedure changed. When a measure improves, check whether the definition, the sample, or the queue mix changed.

Include a case where the owner said no or asked for more evidence; those decisions show whether the boundary is working. Use the correction log to estimate rework, and separate corrections caused by source errors from those caused by judgment. Assign one owner and one due date to each review action, and check the action at the next sample. Give the review an owner and a follow-up date; a finding without an action is only an observation.