A fictional subscription service routes every “charged after cancellation” message through the same three bot articles and offers no human or written case route.
This is an original fictional comparison. It depicts no real business and is not a regulator finding, statutory category or legal safe harbour.
Billing supportAccount Management
Support bot loops without escalation
A fictional subscription service routes every “charged after cancellation” message through the same three bot articles and offers no human or written case route.
Potentially problematicHow can we help?
How can we help?. The bot repeats three articles and closes the conversation after each answer.. Start over. Unconfirmed state: Start over
The bot repeats three articles and closes the conversation after each answer.
Start over
Unconfirmed state: Start over
→
Neutral alternativeBilling issue not resolved
Billing issue not resolved. A written escalation route preserves the history and creates a case number.. Send to support. Saved state: Send to support. Persisted account state, expanded: The saved state behind “Send to support” remains consistent after refresh and across supported channels.
A written escalation route preserves the history and creates a case number.
Send to support
Saved state: Send to support
Persisted account stateThe saved state behind “Send to support” remains consistent after refresh and across supported channels.
Why the first version can mislead: The route adds avoidable effort between the user’s stated intention and completion. In this billing support example, the obstacle is: “The bot repeats three articles and closes the conversation after each answer.” Evidence should show whether the alternative remains usable and whether “Send to support” reaches the represented state. A customer may be unable to dispute a charge or preserve evidence of the request.
What a fairer design does: Provide an accessible escalation route, retain the conversation and issue a case reference when self-service cannot resolve the issue.
Show annotated differences (4)
Potentially problematic version
The bot repeats three articles and closes the conversation after each answer.Why this state matters: The route adds avoidable effort between the user’s stated intention and completion. In this billing support example, the obstacle is: “The bot repeats three articles and closes the conversation after each answer.” Evidence should show whether the alternative remains usable and whether “Send to support” reaches the represented state. A customer may be unable to dispute a charge or preserve evidence of the request.
Unconfirmed state: Start overReview prompt: How many steps, waits and channel changes separate “Start over” from the completed billing support outcome?
Neutral alternative
A written escalation route preserves the history and creates a case number.Fairer design: Provide an accessible escalation route, retain the conversation and issue a case reference when self-service cannot resolve the issue.
Persisted account state, expanded: The saved state behind “Send to support” remains consistent after refresh and across supported channels.Review prompt: Test the control across refresh, device and account states; is “Support is materially needed for a consumer issue connected with supply” still observable after persistence is considered?
Review questions (3)
How many steps, waits and channel changes separate “Start over” from the completed billing support outcome?
Test the control across refresh, device and account states; is “Support is materially needed for a consumer issue connected with supply” still observable after persistence is considered?
Measure the same task through the clearest available route: does the effort difference persist once “Reasonable queue or documented service hours” is accounted for?
Side-by-side billing support interface showing “How can we help?” and the clearer alternative “Billing issue not resolved”.Provenance: Original hypothetical billing support example created for this library; no real business, product or interface is depicted.
Complete practice context
How this example relates to Customer-support obstruction
Access to support needed to resolve a purchase, account, charge or right is hidden or burdened by unnecessary loops and dead ends. This is a design and research taxonomy for learning and evidence review, not a statutory offence label or an automatic finding that an interface is unlawful.
The full guide explains inclusion and exclusion criteria, potential harms, fairer design, evidence questions and separate Australian legal information layers. The example page isolates one scenario so it can be shared and discussed without reproducing the complete library on one page.
A fictional platform labels a control “Delete account”, but the confirmation only hides the profile and leaves data and reactivation available indefinitely.
A fictional retailer places account deletion behind six help pages and requires a support ticket containing an order number even for users who never ordered.