Operations
Part of Reading digital customer journeys with a sceptical eye
Digital customer journeys checklist: the items people skip
A digital customer journeys checklist that maps frontstage and backstage work, tests accessibility, and keeps data collection justified at every handoff.
What to take away
- Map the journey twicewhat the customer sees, and the backstage work that makes it true.
- Every customer state needs an entry condition, an exit condition, an owner, and a named evidence source.
- Test accessibility with automated tools plus keyboard and screen reader passes; tooling alone cannot judge a journey.
- Collect the minimum data each step needs, and record why it is held and for how long.
- Grade each finding as evidence or hypothesis, with the date and sample behind it.
A checklist is a working document, not a certificate. It tells you where the journey is unproven. Customer research and operating data decide whether it works.
Map frontstage and backstage together
Frontstage is what the customer touches: the page, the email, the call, the confirmation screen. Backstage is the queue, the approval, the vendor feed, the person who fixes a failed order by hand.
Frontstage vs Backstage Journey
Frontstage
- What it is
- Customer touches
- Examples
- Page, email, call
- Failure mode
- Promise looks fine
- Mapping need
- Record goal and action
Backstage
- What it is
- Hidden support work
- Examples
- Queue, approval, vendor feed
- Failure mode
- Refund sits unowned
- Mapping need
- Record delay and owner
Most broken journeys fail backstage. The promise on the page is fine; the refund sits in a queue nobody owns. Map both layers on the same canvas so the gap is visible.
The digital customer journeys guide covers the mapping method in full. For each step, record the customer's goal, the action they take, the information they need, and the delay they experience.
Define customer states, not just steps
A state is a condition the customer is in: eligible and browsing, waiting on verification, blocked by a failed payment, or past first value. Steps describe movement. States describe where someone actually sits.
Customer State Definition Checklist
- Entry condition
- Exit condition
- Expected duration
- Owner
- Exception path
For each state, write these items:
Define customer states
- the entry condition
- the exit condition
- the expected duration
- the owner
- the exception path A state with no exit condition is where customers quietly disappear.
Track the states that matter to revenue and retention: new, activated, at risk, recovered, churned. The digital customer journeys benchmarks page carries comparison figures by vertical and traffic source, each with its date.
Test accessibility as a journey, not a page
W3C's guide to selecting web accessibility evaluation tools makes the point that tools cover different standards and cannot determine accessibility alone. Pair them with expert and user review.
Run the checks that break real tasks:
Test accessibility as a journey
- Complete the primary task using only a keyboard, including payment and confirmation.
- Read the page with a screen reader and confirm labels, grouping and error messages make sense.
- Check focus order, visible focus, text contrast, and whether custom controls respond to standard keys.
- Verify time limits can be extended and multi-page progress is announced.
Then check the commercial friction: hidden fees at the last step, preselected add-ons, false urgency, and a cancellation path that takes more clicks than the purchase did.
Keep data collection justified
For every field and every event, write the purpose, the lawful basis, the retention period, and the system that holds the authoritative copy. The UK Information Commissioner's Office publishes a guide to the data protection principles. It covers the following:
- lawfulness
- purpose limitation
- minimization
- accuracy
- storage
- security
- accountability Confirm what your own market requires before you rely on it.
The W3C Privacy Principles statement warns against shifting privacy work onto the individual. Design the default so the customer does not have to opt out of something they never asked for.
| Gate | Required record | Pass condition |
|---|---|---|
| Customer | Goal, context, eligibility | Real need is verified |
| State | Task, content, accessibility | People can progress |
| Handoff | Owner, context, timing | Work does not disappear |
| Data | Purpose, minimum, retention | Collection is justified |
| Recovery | Error, support, correction | Failure can be repaired |
Grade the evidence before you act
Mark each finding as evidence or hypothesis. Evidence carries a source, a date, a sample and a market. A hypothesis carries the test that would settle it.
Path analysis needs its settings saved alongside the result:
Grade the evidence
- date range
- segment
- filters
- node types
- metric
- exclusions
- comparison population Without them the chart cannot be reproduced next quarter.
Grade the evidence
- Task success
- Time on task
- Error rate
- Recovery rate
- Fulfillment
- First value
- Retention
- Refunds Pick the two or three that match the state you are repairing.
Set the repair gate
Prioritize broken transactions, inaccurate information and unresolved service ahead of cosmetic work. Then assign a business owner and a technical owner, a target outcome, guardrails, a deadline and a test method.
Before approving a repair, confirm the evidence gaps are visible, the affected teams accept ownership, and a documented fallback exists. Set the first review date and the condition that would trigger an earlier one.
Teams that skip this gate repeat the same digital customer journeys mistakes: channel-first maps, states with no exit, and handoffs nobody owns.
Add supply-chain questions for bought software
The CISA software acquisition fact sheet covers development practice, supply-chain exposure, deployment and vulnerability management. Ask those questions of any journey tool you buy, and keep the answers with the rest of the evidence.
Common questions
Who should complete a journey checklist?
Customer research, design, content and accessibility each own part of it. Product, engineering, data and privacy each own part too. Security, marketing, sales and service each own part as well. Fulfillment, finance and accountable leadership each own part of it. One person should hold the document and chase the gaps.
Does a completed checklist prove the journey works?
No. It prepares a controlled review. Task testing, customer research, operational evidence, accessibility evaluation and outcome data decide whether the journey works.
When should the checklist be repeated?
Here is a one-sentence lead-in:
- After material change to customers, policy, price, channels, content, interface, identity, payment, data, vendors, fulfillment, support or regulation. Set a review date anyway, so drift gets caught between changes.
How do you keep the map from going stale?
Assign an owner to each state and each handoff, and store the map where the teams who change the journey will see it. A map in a slide deck nobody opens is already out of date.
