CX Measurement
Part of Testing redesigned customer experiences
Defining success before a customer journey redesign
Define a checkable customer outcome, change hypothesis, baseline and decision rule before redesigning a journey.
Define success as a checkable customer outcome, then state how the redesign should improve it. Set this before choosing screens, scripts or metrics. Otherwise, a team can deliver the planned change without learning whether the customer's task became more successful.
Key Steps to Define Success Before a Customer Journey Redesign
- Define a checkable customer outcomeState the desired result in the customer's terms, such as securing a booking and receiving usable information.
- Write the outcome in the customer’s termsClarify where the journey begins and ends, including early exits or alternative paths. Differentiate outcomes for different customer types.
- State the change hypothesisFormulate: 'Changing this part of the journey should improve this outcome because we believe this obstacle is causing the current difficulty.' Include evidence that could challenge the hypothesis.
- Make a small measurement agreementAgree on what counts as success, failure, partial or unknown; define data sources, observation window, and diagnostic signals like repeat contact.
- Check whether the baseline is usableEnsure records can identify eligible attempts, distinguish amended from new requests, and show actual results—not just staff actions.
Write the outcome in the customer’s terms
For a hypothetical event-booking service, the outcome could be that a person secures a suitable booking and receives information they can use to attend. A submitted form is an earlier event. A confirmation message may show a request was received, while the booking record and the customer's understanding answer different parts of the final-outcome question.
Write down where the journey begins and ends, including customers who stop early or need an alternative route. If different customers seek different outcomes, define them separately. Do not use an internal queue status as the sole success condition unless it establishes the result the customer needed.
State the change hypothesis
For the proposed redesign, complete this sentence: “Changing this part of the journey should improve this customer outcome because we believe this obstacle is causing the current difficulty.” Label the explanation as a hypothesis. A team may know people call after booking without yet knowing whether the cause is unclear wording, unavailable slots or a failed confirmation.
Identify evidence that would challenge the hypothesis. If customers understand new instructions but still cannot obtain a suitable booking, the instructions were not the whole answer. This countercheck makes the success definition useful when results disappoint.
Make a small measurement agreement
| Record before the redesign | Decision it protects |
|---|---|
| Eligible customer and task | Which attempts belong in the comparison, including early exits where these can be identified? |
| Checked success, failure, partial and unknown outcomes | What will count without quietly dropping uncertain cases? |
| Baseline period and data source | What was happening before the change? |
| A few diagnostic signals, such as repeat contact or a request for help | Where might the task still break down? |
| Possible adverse effect and pause trigger | What result would call for correction even if the main measure improves? |
Name the calculation, observation window and owner for each measure. Choose a window long enough for the outcome to occur. Where a result cannot be checked through records, plan an appropriate customer follow-up and report its response limits. Keep reported confidence or satisfaction separate from verified booking outcomes.
Before vs After: Key Elements of a Measurement Agreement
- Record before the redesignEligible customer and task, checked success/failure/partial/unknown outcomes, baseline period and data source
- Decision it protectsWhich attempts count in comparison, how outcomes are classified, and what constitutes a valid baseline for evaluation
Critical Metrics for Validating Redesign Success
- Baseline Period
- Defined time frame before redesign for comparison
- Observation Window
- Time needed to observe full customer outcome post-redesign
- Diagnostic Signals
- Repeat contact, help requests – indicate hidden breakdowns
- Pause Trigger
- Condition requiring immediate review even if main metric improves
Check whether the baseline is usable
Before release, look at the proposed data: can the team identify eligible attempts, including early exits; can it tell an amended booking from a new request; does the record show the result rather than only the last staff action? If the baseline cannot answer the question, improve the collection plan or narrow the claim the later comparison can make.
Agree the decision rule in ordinary language: what would support expanding the redesign, what would require more investigation, and what would mean revising it. A target alone is not proof of causation. The later review must also consider changes in who used the service, how cases were handled and what else changed during the period.
