When completion stalls, isolate the stuck step

What it is

A checklist frozen at 40% or 3 of 5 is not a diagnosis. The question is which item is unticked, and whether it was never opened, opened then failed, or finished and not recorded. Stall is a distribution, not an average. Treating stall as “users are not motivated enough” nags the whole list; isolating the step is what lets you change that entry, copy, or external dependency. This entry is measurement and location on a checklist, not how progress is displayed, and not whether items have value.

Why it happens

Items have different cost structures: one tap, wait for a colleague to accept, fetch a key from another site. Stall piles onto the costliest or least understandable failure, not evenly. Without a split, operations send every incomplete person the same “finish setup” nudge; someone stuck on an OAuth failure still receives a ledger, the problem stays, the nudge becomes noise. Location must also split “never opened this item” from “opened and did not finish”: the first is can’t find or dare not click; the second is failure inside the flow. A missed record (email already connected, tick not set) creates a fake stall and people redo finished work. A completion dashboard with only a percentage therefore encourages the wrong intervention.

Studying it

Build a per-item funnel: shown, opened, succeeded, recorded. Inspect error types on open-then-fail sessions; for never-opened, look at the item’s place and copy in the list.

Independent variables: external dependency, order in the list, whether failure copy is actionable. Dependent variables: open and success rates per item, stall duration, whether a nudge still leaves them on the same item.

Do not use total completion as the only KPI. Labs often proxy external dependencies, underestimating stall. In follow-ups, ask which named item, not whether onboarding was “hard.”

Where it stops holding

On an unordered list, an undone item may be a deliberately skipped low-value step; stall is not failure unless that item is required for the core task. In a team space, “invite members” may stall on org policy, not UI. Completion stopped by a plan wall is acquisition, not an onboarding stall to nag. After the user dismisses the checklist, completion stops updating; do not read dismiss as stall.

Applying it

• Record shown, opened, and succeeded per item; fire stall alerts per item, not only on the total percentage.
• For open-then-fail, put an actionable error inside that item, not a list-level “continue setup.”
• Audit recording: spot-check ticks against true completed state; fix fake stalls in the recorder first.
• Verify by listing the unticked item for accounts whose completion has not moved across several sessions. If the intervention is still a uniform nudge rather than a change to that item, location never entered the product.

Related

• Within the group: H2.09.1 Checklists need a total and a completed count for progress · H2.09.2 Checklist items should produce value, not ceremonial ticks · H2.09.4 Too many checklist items become a burden, not guidance
• Adjacent: H2.05 Feature Discovery · H3.02 Three elements of error messages · H3.13 Handling partial failure
• Search terms: onboarding stall · checklist drop-off · step-level funnel