Measuring cycle time for onboarding plan from request to verified close

Purpose and scope

A grounded customer success note for customer success leaders: onboarding plan with explicit evidence, decision rights, and a verified close.

What the protocol tests

A grounded customer success note for customer success leaders: onboarding plan with explicit evidence, decision rights, and a verified close.

Report denominators and unresolved records.

Keep the customer decision with the owner.

Limits and reporting discipline

Methodology

The protocol does not estimate an industry benchmark; it produces a local description that customer success leaders can review. The population should include cases handled by every owner and channel in scope, not only the queue with the cleanest records. Write the primary measure and one supporting measure; a measure without a denominator or observation window is not ready. If the study is exploratory, label it exploratory and do not present the result as a stable baseline. If the evidence is sensitive, record the approved reference and access path rather than copying the content.

A useful scope is narrow enough to reproduce and specific enough to show whether missed renewal signal is being detected. The population should include cases handled by every owner and channel in scope, not only the queue with the cleanest records. Define age from the first recorded request, not from the first time someone remembered to open the case. Record the exclusions in advance so a difficult case cannot be removed after the result is known. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.

Test the unit definition on a case that crosses owners, a case that is still open, and a case that was reopened. A denominator that changes during the window should be reported separately for each period. If the definition of escalation age changes, keep the old and new values side by side for the transition period. Report a case that moved between owners as one case with two owner periods unless the process creates a new requirement. Record this decision in the study log with the case key, the review date, and the person who approved the classification.

Record how duplicate requests were matched, merged, or kept separate, because that choice changes the denominator. Report the number of cases that could not be classified and the reason, rather than forcing them into a category. If the definition of renewal risk lead time changes, keep the old and new values side by side for the transition period. Separate cases opened before the window from cases opened and closed inside it, and report both counts. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue.

Define how a correction after close is linked to the original case and whether it creates a new case. Use a stable case key and a separate identity crosswalk stored in an approved system. Record the person who approved the definition and the date it became effective. Write the start and stop events as observable actions, not as opinions about whether the work felt finished. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.

Define the controlled event as the moment a onboarding plan request becomes work, not the moment someone starts typing a note. Define allowed values for status, reason, owner, and evidence state before collection. A duplicate request is a separate intake event even when it points to the same underlying need; record the link. Keep a change log for every definition adjustment and the date it took effect. At Customer Success Managers, the reviewer should be able to explain this step to CSM from the case record alone.

Use a pseudonymous case key and keep the identity crosswalk in an approved system with restricted access. Test the dictionary on a case with a missing escalation record and a case with a corrected value. Keep the original evidence reference next to the coded value so the reviewer can verify the classification. A case key should remain stable if the case moves between owners or changes status. Use the same note in the case file and the study extract; do not create a second version in a personal document.

Record the version or date of the renewal risk memo and the QBR template library value so a later reviewer can see what was known at the first action. If a field is derived, record the formula and the source fields used to calculate it. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Use a separate field for reviewer notes so the coded values stay comparable. When a case needs an exception, record the reason, the owner, and the date before continuing the review.

Test the dictionary on five cases before the full sample; ambiguous fields should be fixed before collection, not after. Name the required fields for each article type and mark conditional fields in the dictionary. A missing value should have a reason code, not a blank cell or a zero. Keep the original request, the approval, and the destination value linked to the same key. Keep the measurement note short enough to read with the case and specific enough to support the reported escalation age.

Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. Use the same collection form for every case and keep the original record linked to the extracted fields. Record the eligible count and every exclusion before the sample is drawn. Use a random start and a fixed interval when the frame is ordered, and record both. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.

Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. Record the time of each observation so a later reviewer can distinguish a late entry from a changed decision. Record the eligible count and every exclusion before the sample is drawn. Record the date of the sample and the version of the queue export. Link the observation to the exact field in the renewal forecast and to the usage report that supports it.

If the population is small, report every case and the reason the sample is exhaustive rather than presenting a false precision. Keep the collection window and the number of collectors in the report; both affect how the result should be interpreted. Use a random or systematic start rule and then take consecutive cases within each stratum. Use a random start and a fixed interval when the frame is ordered, and record both. Do not let a summary written later replace the evidence that was available at the first decision.

Compare QBR completion across owners only after checking the case mix, the channel, and the evidence standard. For onboarding plan, report the age distribution and the share of cases waiting on a named owner. Record the sample date, the denominator, the numerator, and the exclusion count for every reported rate. Use a case-level table to explain an outlier before treating it as a process signal. If the case moved between owners, include both owner periods in the review note and name the handoff time.

Keep case-level detail available for review, because a summary chart without records cannot support a decision. Compare periods only after checking the case mix, the definitions, and the queue rules. When two groups differ, check whether the difference survives after adjusting for case mix and evidence standard. Use a case-level table to explain an outlier before treating it as a process signal. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.

The cited public sources frame recordkeeping, privacy, security, or control practice; they do not provide a local result. The cited sources describe recordkeeping, privacy, security, or control practice; they do not supply a local benchmark. Record the response or access problems that prevented a case from being reviewed. If the queue changed during the window, explain how the change affects the denominator. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract.

Report what remains unknown and what evidence would be needed to answer the next question. The record may be incomplete or delayed, so the method cannot infer work that never entered the queue. Record the response or access problems that prevented a case from being reviewed. A missing record is evidence about the record, not proof that the work was never done. At Customer Success Managers, the onboarding plan review should end with a dated note and a named owner for the next check.

Keep the review note with the onboarding plan evidence so the next reviewer can see why the process changed. Keep the review note with the onboarding plan evidence so the next owner can see why the process changed. Set the next sample date before closing the review, so the action does not drift. Close the review when the owner accepts the finding and the next test is on the calendar. If the evidence is sensitive, record the approved reference and access path rather than copying the content.

A quality review should end with an owner, a date, and one testable change, not a list of intentions. If the action changes unlogged escalation, record the approval from account executive before implementation. Keep the old process note until the new process has been tested; do not erase the baseline. Close the review when the owner accepts the finding and the next test is on the calendar. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.