Define the qualifying workflow, measurement window, eligible population, and coverage before calculating a rate. Then connect each result or evidence gap to a specific review action. Usage can tell you who completed the defined workflow; it does not by itself show whether the customer's desired outcome was achieved.
GitLab's adoption-scoring handbook discusses use-case metrics, measurement periods, explicit denominators, instrumentation, and validation. Its customer-success guidance separately describes intended users and mutually agreed outcomes and adoption plans. This example uses those distinctions without adopting GitLab's thresholds, weighting, or timelines. GitLab's adoption-scoring guidance, GitLab's customer-success handbook.
Define the workflow before counting activity
The original fictional product is Slateboard, a shared workspace. The qualifying event is a completed export of an agreed weekly work plan. A login is not that event. The review snapshot is October 13, 2026, and the measurement window is October 6–12 inclusive, using a declared local date-only calendar. An actual telemetry workflow would need its real time-zone and date rules confirmed.
Account A01 has four eligible users: U01, U02, U03, and U04. Its supplied event coverage is complete for this demonstration. Keep the eligible-user list and event records together so the numerator can be checked against the denominator.
| Event | User | Date in 2026 | Recorded action | Treatment |
|---|---|---|---|---|
| E01 | U01 | October 6 | Completed plan export | Qualifies |
| E02 | U01 | October 7 | Completed plan export | Qualifies; same user as E01 |
| E03 | U02 | October 12 | Completed plan export | Qualifies |
| E04 | U03 | October 13 | Completed plan export | Outside October 6–12 window |
| E05 | U04 | October 8 | Login | Not the qualifying workflow |
There are three qualifying events but two distinct qualifying eligible users, U01 and U02. A01's workflow participation is therefore 2/4 = 50%. Keep the duplicate-user event as evidence; deduplicate the user count, not the event ledger. Retain E04 and E05 with their exclusion reasons.
Show missing coverage and no eligible population honestly
Account B01 has four eligible users, U05–U08, but its event coverage is unavailable. Its participation is unknown, not 0/4. Account C01 has zero eligible users. Its rate is not applicable, not a success or a zero-percent result.
| Account | Eligible users | Coverage and result | Planned review action |
|---|---|---|---|
| A01 | 4 | Complete supplied ledger; 2/4, 50% | Mia asks for evidence of workflow obstacles |
| B01 | 4 | Telemetry unavailable; participation unknown | Leo resolves the coverage gap |
| C01 | 0 | No eligible population; rate not applicable | Mia confirms rollout scope |
These names, IDs, and actions are fictional. The actions are planned, not messages already sent or changes already made. Show one measured account, one unknown account, and one not-applicable account. Do not pool A01's two users over eight eligible users and present 25% as a portfolio adoption rate: B01's numerator is not known.
A measured zero would require a defined eligible population and complete relevant coverage with no qualifying users. Missing coverage cannot supply that evidence. Keep that distinction visible in every filtered view.
Withhold a trend when the periods do not match
The illustrative prior period, October 1–5, has one qualifying user out of four, or 25%. It is five days long; the current October 6–12 window is seven days. The periods do not overlap, but they are not equivalent weekly windows.
Do not report a 25-percentage-point weekly improvement from those figures. Retain the prior result with its period label, withhold the trend, and request a matched seven-day comparison with comparable eligibility and coverage. A shorter observation window is not a clean baseline for the stated weekly comparison.
Turn the review into an evidence request
For A01, Mia's proposed question is: “What prevented the intended users from completing the agreed plan-export workflow during this window?” The usage record does not establish a reason; the question seeks one. For B01, Leo's first task is to determine whether the relevant events were captured for the window. For C01, Mia checks whether this workflow was in the account's intended rollout scope.
The desired outcome is shorter team planning, but its baseline, measurement method, and result remain TO CONFIRM. A completed export does not prove reduced planning time, satisfaction, renewal, or the overall customer goal. Keep an outcome-evidence field beside the workflow metric rather than substituting usage for it.
Specify portable workbook or CSV tables for accounts, eligible-user membership, events, coverage, and planned actions. Join them by stable IDs and preserve excluded records. The companion can filter the supplied mock account and window while showing qualifying event/user IDs, denominator, and coverage together. The companion provides local review controls without background ingestion or saved visitor edits.
Copy this prompt for the adoption review packet
Create one complete, self-contained US-English HTML companion for “Slateboard • adoption evidence”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for A01 · measured; B01 · unknown; C01 · no eligible users; Apply window; Reset review. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Create a complete US English customer-success adoption review packet with account, eligible-user, event, coverage and action workbook or CSV schemas; complete fixture tables; expected calculations; evidence questions; and a separate HTML review specification. All data describes fictional Slateboard, not actual vendor or customer output. Snapshot: October 13, 2026. Local date-only window: October 6-12 inclusive. Only a completed export of the agreed weekly work plan qualifies; login does not. A01 has eligible users U01-U04 and complete supplied coverage. Events: E01 U01 export October 6; E02 U01 export October 7; E03 U02 export October 12; E04 U03 export October 13, outside the window; E05 U04 login October 8, nonqualifying. Retain every row and exclusion reason. Three qualifying events involve two distinct eligible users: 2/4=50%. B01 has eligible users U05-U08 but unavailable telemetry: participation unknown, not 0/4. C01 has zero eligible users: rate not applicable, not 0% or success. Show one measured, one unknown and one not-applicable account. Do not report an overall 2/8 rate with missing B01 coverage. Distinguish a measured zero from unknown. Prior October 1-5 result 1/4=25% uses five days versus the current seven. Withhold weekly trend/change and request a matched seven-day comparison with comparable coverage and eligibility. Do not invent a 25-percentage-point improvement. Planned actions: A01 owner Mia asks for workflow-obstacle evidence; B01 owner Leo resolves coverage; C01 owner Mia confirms rollout scope. The desired outcome is shorter team planning, with baseline, method and result TO CONFIRM. Participation does not prove satisfaction, renewal or an achieved outcome. A planned action does not change the measurement or count as a sent message. A proposed HTML account/window filter reveals exact included/excluded event IDs, distinct user IDs, denominator and coverage, with unknown and not-applicable states. Implementation and testing are pending. No automatic capture, personal data, arbitrary health score, notifications or saved visitor edits. Actual review data and agreements stay in the maintained workflow.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# A Customer Success Dashboard Template That Shows What Adoption Actually Measures
Your dashboard counts three workflow events and reports three adopting users. Two events belong to the same person. Another account has no telemetry, yet its tile displays zero usage. Those figures can send a customer-success team toward the wrong follow-up.
Define the qualifying workflow, measurement window, eligible population, and coverage before calculating a rate. Then connect each result or evidence gap to a specific review action. Usage can tell you who completed the defined workflow; it does not by itself show whether the customer's desired outcome was achieved.
GitLab's adoption-scoring handbook discusses use-case metrics, measurement periods, explicit denominators, instrumentation, and validation. Its customer-success guidance separately describes intended users and mutually agreed outcomes and adoption plans. This example uses those distinctions without adopting GitLab's thresholds, weighting, or timelines. [GitLab's adoption-scoring guidance](https://handbook.gitlab.com/handbook/customer-experience/product-usage-data/maturity-scoring/), [GitLab's customer-success handbook](https://handbook.gitlab.com/handbook/customer-experience/csm/).
## Define the workflow before counting activity
The original fictional product is Slateboard, a shared workspace. The qualifying event is a completed export of an agreed weekly work plan. A login is not that event. The review snapshot is October 13, 2026, and the measurement window is October 6–12 inclusive, using a declared local date-only calendar. An actual telemetry workflow would need its real time-zone and date rules confirmed.
Account A01 has four eligible users: U01, U02, U03, and U04. Its supplied event coverage is complete for this demonstration. Keep the eligible-user list and event records together so the numerator can be checked against the denominator.
| Event | User | Date in 2026 | Recorded action | Treatment |
| --- | --- | --- | --- | --- |
| E01 | U01 | October 6 | Completed plan export | Qualifies |
| E02 | U01 | October 7 | Completed plan export | Qualifies; same user as E01 |
| E03 | U02 | October 12 | Completed plan export | Qualifies |
| E04 | U03 | October 13 | Completed plan export | Outside October 6–12 window |
| E05 | U04 | October 8 | Login | Not the qualifying workflow |
There are three qualifying events but two distinct qualifying eligible users, U01 and U02. A01's workflow participation is therefore `2/4 = 50%`. Keep the duplicate-user event as evidence; deduplicate the user count, not the event ledger. Retain E04 and E05 with their exclusion reasons.
## Show missing coverage and no eligible population honestly
Account B01 has four eligible users, U05–U08, but its event coverage is unavailable. Its participation is unknown, not 0/4. Account C01 has zero eligible users. Its rate is not applicable, not a success or a zero-percent result.
| Account | Eligible users | Coverage and result | Planned review action |
| --- | --- | --- | --- |
| A01 | 4 | Complete supplied ledger; 2/4, 50% | Mia asks for evidence of workflow obstacles |
| B01 | 4 | Telemetry unavailable; participation unknown | Leo resolves the coverage gap |
| C01 | 0 | No eligible population; rate not applicable | Mia confirms rollout scope |
These names, IDs, and actions are fictional. The actions are planned, not messages already sent or changes already made. Show one measured account, one unknown account, and one not-applicable account. Do not pool A01's two users over eight eligible users and present 25% as a portfolio adoption rate: B01's numerator is not known.
A measured zero would require a defined eligible population and complete relevant coverage with no qualifying users. Missing coverage cannot supply that evidence. Keep that distinction visible in every filtered view.
## Withhold a trend when the periods do not match
The illustrative prior period, October 1–5, has one qualifying user out of four, or 25%. It is five days long; the current October 6–12 window is seven days. The periods do not overlap, but they are not equivalent weekly windows.
Do not report a 25-percentage-point weekly improvement from those figures. Retain the prior result with its period label, withhold the trend, and request a matched seven-day comparison with comparable eligibility and coverage. A shorter observation window is not a clean baseline for the stated weekly comparison.
## Turn the review into an evidence request
For A01, Mia's proposed question is: “What prevented the intended users from completing the agreed plan-export workflow during this window?” The usage record does not establish a reason; the question seeks one. For B01, Leo's first task is to determine whether the relevant events were captured for the window. For C01, Mia checks whether this workflow was in the account's intended rollout scope.
The desired outcome is shorter team planning, but its baseline, measurement method, and result remain `TO CONFIRM`. A completed export does not prove reduced planning time, satisfaction, renewal, or the overall customer goal. Keep an outcome-evidence field beside the workflow metric rather than substituting usage for it.
Specify portable workbook or CSV tables for accounts, eligible-user membership, events, coverage, and planned actions. Join them by stable IDs and preserve excluded records. The companion can filter the supplied mock account and window while showing qualifying event/user IDs, denominator, and coverage together. The companion provides local review controls without background ingestion or saved visitor edits.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the adoption review
Use the HTML companion to inspect the qualifying records and coverage labels in the companion. Keep maintained telemetry, eligibility, and customer agreements in the native workflow; the review copy does not capture usage or establish customer outcomes.
Finish with a traceable measured result for A01 and different next steps for B01's missing coverage and C01's rollout question, so each follow-up addresses the evidence that is actually missing.