Build a support path users can follow from question to closure
A companion app should not hide every concern behind one chatbot or a generic contact form. It needs three clearly named routes: human customer support for account, access, payment-record, or feature problems; reporting for a specific item, account, interaction, or safety concern; and appeal for challenging a decision already made by the service. Automation may acknowledge and route a case, but the app should explain when a person can review it, which information moves with the handoff, what state the case is in, when the next update is expected, and how it closes. A receipt proves submission, not a particular action. Likewise, an appeal provides a fresh review path, not a promised reversal. The practical standard is a traceable case whose owner, evidence boundary, decision scope, and next step remain understandable without requiring users to repeat private material to several teams.
Separate support, reporting, and appeal before asking for details
The first screen should help a user choose a route by task, not by internal department name. Customer support covers access, account recovery, subscription records, settings, and features that do not work as described. Reporting covers content, contact, an account, a shared space, a recommendation, or another observable event that may breach published rules. Appeal starts from an existing decision: content was removed or left up, an account or feature was restricted, or a previous complaint was closed. Show examples and allow correction if the user chose the wrong route. One shared backend may be efficient, but the public flow must preserve the reason for contact and the applicable next steps. Keep a visible human-contact option or disclosed human escalation for matters the automated route cannot understand, especially access barriers, contested decisions, repeated failed routing, and cases requiring context. Do not label a bot conversation as human support, and do not force a new report when the user is asking about an existing case.
Collect the smallest report that can still be acted on
Place reporting beside the item or interaction when possible, while also offering a help-centre route for a missing item or a person who cannot sign in. Let the user identify the affected surface, content or account, approximate time, applicable concern, and a short free-text explanation. A fixed category speeds routing, but it should not be the only way to describe an event. Preserve an item identifier, version, and relevant context on the service side when policy allows; do not make the user repeatedly reopen or redistribute the material simply to prove it existed. Explain what will be included, who can access it, and how long the case record is kept. Never ask for a password, recovery code, or unrelated conversation history. If logged-out or third-party reporting is offered, state its limits and how updates will be delivered. eSafety's design guidance specifically notes that hard-to-find tools, forced account creation, ambiguous fields, and repeated confrontation with reported material can deter reporting.
Turn a receipt into a readable case state
After submission, issue a case ID and a durable place to check it. A useful state model distinguishes received, needs information, queued, under review, action taken, no action under the stated rule, appealed, changed, and closed. These labels should describe what the service knows rather than display a permanent ‘in progress’ badge. The acknowledgement should repeat the object and route, list the evidence retained, say whether an immediate personal control such as block or mute remains available, and give the next-update window. A window is a service expectation, not an outcome promise; if it changes, send a new update rather than silently moving the date. Do not expose another person's account data or identify the reporter in status messages. When two teams own parts of a case, keep one public case ID and show the handoff instead of asking the user to start over. This creates continuity even when resolution requires several internal systems.
Define when automation hands the case to a qualified person
Automation can confirm receipt, detect missing fields, route language, link duplicate reports, and present immediate controls. It should not become an invisible dead end. Publish the conditions that lead to a person: the user asks for human contact, the issue does not match available categories, access or accessibility prevents completion, the same routing fails repeatedly, significant context is disputed, or an eligible appeal requires review. The European Commission's DSA explanation provides one jurisdiction-specific benchmark: covered platforms need direct user contact that does not rely solely on automated tools, and complaints are handled by qualified staff. An app operating elsewhere should describe the routes that actually apply rather than borrowing a compliance label. Human agents need the case history, permitted evidence, language and accessibility needs, and authority to make or escalate the relevant decision. Access to private records should follow job role, and an outsourced team should remain visible in the audit trail without exposing employee identities.
Give a reasoned decision and a usable appeal
A decision notice should identify the reviewed object, the rule category, whether action was taken, the scope and duration of that action, and the next available step. It should be specific enough to understand while withholding reporter identity, confidential detection details, and unnecessary private content. If the service cannot disclose part of the reasoning, it can name that limit rather than replace the explanation with a blank template. The appeal form should carry the original case ID, decision, and retained evidence forward, then allow the person to correct facts or add context. It is not a route to bypass controls or resubmit the same claim indefinitely. Use a reviewer or review process capable of reconsidering the first decision, record whether it was upheld, changed, or returned for more work, and apply any correction across the affected surfaces. Clear reasons and meaningful review support both reporting users and people affected by moderation decisions.
Close the case while feeding lessons back into the service
Closure should state the final case state, date, action scope, remaining personal controls, appeal availability or exhaustion, and how long the user can access the record. It should not claim that the service eliminated every future risk. Internally, compare more than total report or removal counts: routes abandoned before submission, reports needing repeated clarification, time to first meaningful response, handoff failures, reopened cases, appeal outcomes, restored items, repeated categories, and changes to instructions or product controls. eSafety's transparency guidance and UNESCO's governance principles support looking at outcomes, complaints, appeals, and system changes, not a single volume metric. Use a nine-field card for an ordinary audit: route, affected object, case ID, retained evidence, current state, owner or handoff, next-update window, decision and scope, appeal or closure. Missing fields reveal exactly where continuity breaks without requiring a live queue test or a promised result.
Common questions
Does human support mean every first reply must come from a person?
No. Automation can acknowledge and route a case, but the app should disclose when and how a qualified person becomes reachable and avoid an automated dead end.
Is a report receipt proof that action was taken?
No. It proves intake. The case state, decision notice, action scope, and appeal route show what happened afterward.
Should an appeal reveal who made the original report?
No. A useful appeal can carry the decision, rule, object, and permitted evidence without exposing reporter identity or unrelated private details.