Sent is a state. Resolution is a handoff.

Wise’s public explanation of a completed transfer separates sending money to the recipient’s bank from its appearance in the recipient’s account. The reviewed transfer-detail flow supplies the interface context. Neither source grants this concept access to a bank’s final credit state.

I began with that boundary because a reassuring headline can become a false promise. The sender may need proof that Wise completed its part; the recipient may need help tracing a payment; support needs enough context to decide the next action. One green status cannot serve all three by itself.

The authored example is a £250 bank payout to Alex Morgan. It differs from the captured transfer fixture and must not be read as a same-transaction before/after experiment. Amount, recipient, date and reference are sample data.

I considered a single “Delivered” headline, a longer status explanation, and a status plus a purposeful handoff. I rejected Delivered without a confirmed destination event. Longer copy alone could explain uncertainty but still leave the sender asking what to do next.

I chose a short statement of what is known, a timeline with dated events, and access to receipt and sharing. The trade-off is exposing uncertainty instead of implying closure. The benefit is that the next action follows the actual state.

The claim map below shows what each proposed status permits the interface to say. It is a product contract to validate for a specific payout route, not an assertion about every Wise transfer or internal event name.

The earlier proposal used “View receipt” for a screen that also explained sharing. I changed the label so the next screen does not feel like a detour. The new transfer detail keeps Repeat transfer secondary and pairs help with arrival context.

The visual is an authored reconstruction. It shows hierarchy and wording, not a connected transfer. The public receipt guidance is the reference for receipt availability; route-specific document content and usefulness still require operational verification.

The proposed sequence is sender → receipt preview → explicit share → recipient → bank or support. The preview shows the transfer reference, amount, recipient and dated transfer event. It explains what the document proves and what it does not. The sender chooses whether and how to share it.

I would use the native share sheet after an explicit action rather than automatically contacting the recipient. The document contains personal transfer information, so a preview matters. A canceled share returns to the preview; it must not be labelled Sent to recipient.

The recipient-facing guidance identifies the bank-trace purpose and provides the reference the bank can use, subject to route validation. If a particular receipt is not useful for that inquiry, this concept needs a different handoff. A polished PDF would not repair that service gap.

I would not promise a universal arrival deadline or make the recipient exhaust every bank route before seeking help. The suitable escalation depends on transfer type, elapsed time and the available evidence. Those conditions need review with the people who actually resolve these cases.

I carry the reference into help because the service already knows which transfer raised the question. I chose separate receipt, detail-checking and support routes instead of forcing a single self-service path. The screen can preserve context without pretending to know when a recipient’s bank will resolve the issue.

Accessibility also matters at the document boundary: readable status labels, a text-accessible receipt, explicit timezone for events and useful support context should survive leaving the app. A screenshot of a green check is not an adequate substitute.

The addressable opportunity is status-and-evidence questions in eligible transfers, not all support demand. I would first classify a sample of contacts into unclear status, missing evidence, actual delay, incorrect details and unrelated issues. That would test whether the interface addresses a meaningful share of the workload.

For a pilot I would pair successful next-step understanding and resolution with repeat contacts, elapsed resolution time and avoidable escalation. Fewer first contacts with more unresolved recipients would be a worse service outcome. Document opens alone would only show that a button was found.

I removed the earlier arithmetic uplift chart because assumed contact reductions did not establish eligibility or resolution. The investment includes route validation, receipt accessibility, support routing and localization. I would stop at clearer status copy if the receipt handoff adds no operational value. That narrower change would be a valid result of this study.