LEARN. PRACTICE. GROW.1. Demonstrate use during onboarding
Created accounts and completed training are useful milestones, but do not show that the customer can perform the task. In the fictional rehearsal, the user submits a request and gets stuck because a dependency is unconfigured. Record partial onboarding, fix the dependency and repeat the task through to the agreed outcome. Vary the rehearsal by shift, channel and user type where those conditions change experience. An initial rehearsal failure does not prove that the service is unviable; it exposes a gap to resolve. Define acceptance by demonstrated scope and keep conditions without evidence visible.
2. Complete exit with transferred capability
During exit, inventory capabilities that must continue, information to transfer, ownership and access. Follow applicable local rules without assuming universal retention periods or authorization to delete data. If the agreement requires historical lookup, testing only current requests is insufficient. Delivery of three files proves delivery, not readability for the new owner. Confirm import and a representative query before accepting the condition. Where working new-team access is required before old access is revoked, respect that dependency. If the deadline approaches with unmet conditions, negotiate an explicit transition with the agreement owner.
3. Listen beyond the successful channel
A dashboard may show high satisfaction among form completers while phone support receives users who could not authenticate. Relate the dropout stage, support contact and later outcome within local information-handling rules. Do not conclude the channel is effective merely because accounts were created or fewer contacts are visible in one tool. During a failure, meet the promised update time even without a confirmed cause: communicate known impact, uncertainty, next action and next contact. A historical incident average does not by itself justify promising this incident’s recovery time.
4. Interpret samples and cohorts
Distinguish the percentage among respondents from participation rate. In one example, 24 responses to 120 invitations give 20% participation; 18 satisfied out of 24 gives 75% respondent satisfaction. Do not assign opinions to the 96 nonrespondents. For request completion, follow the same cohort from start to cutoff: 56 completions from 80 pilot requests is 70%. Another 14 completions from earlier requests do not belong in that cohort’s numerator. Reporting total period completions may be useful, but it is a different metric answering a different question.
5. Validate the complete benefit
Automation may save 45 execution hours while adding 12 support hours and eight review hours. Net reduction is 25 monthly hours with non-overlapping categories. This may enable absorbing work or reducing waiting; it does not prove lower spending without observed cost changes. Also consider work transferred to the customer. If the complete task previously took 30 minutes and the new portal consumes 25 plus eight mandatory downstream review minutes, the path now takes 33. The customer did not receive a five-minute reduction. Discuss quality, time, effort, cost and risk within agreed scope rather than reducing value to a local metric.
6. Value review workshop
Prepare an expansion recommendation for a fictional pilot: 40 responses to 200 invitations, 32 satisfied, no night respondents and night authentication-failure contacts. Calculate 80% respondent satisfaction and 20% participation; identify missing evidence before recommending expansion to both shifts. Add an exit case where current requests work but history has not been imported. The recommendation should separate current acceptance, pending conditions, ownership and the next proof. Summary: demonstrate the task, preserve agreed continuity, include missing experiences, compare consistent populations and validate benefit with the people using it.
Survey: 24 responses / 120 invitations = 20% participation
Satisfaction: 18 satisfied / 24 responses = 75% of respondents
Pilot: 56 completions / 80 requests in the same cohort = 70%
14 completions from earlier requests stay outside that cohort.45 hours saved − 12 new support hours − 8 new review hours = 25 net hours/month. No spending reduction was demonstrated.
Common pitfalls
Accounts as use; delivery as usable transfer; respondents as the population; mixing cohort completions; capacity as money saved.
Related topics: Onboarding and offboarding · Value validation
Value needs evidence of the complete outcome and affected people’s experience.
Reference: ITIL 4 Specialist: Drive Stakeholder Value · ITIL 4 DSV; observed JA v1.0.1 (2025 copyright), current EN revision comparison pending