Report outcomes need feedback the reporter can perceive

What it is

A system that never answers reports makes reporters doubt "does reporting even work," lowering their willingness the next time (the trust-erosion loop in the moderation-latency card). Perceptible feedback does not require disclosing punishment details (the reported player's privacy); it needs to convey status and outcome: received → handled → action taken against that player (without naming the action), plus perceptible practical evidence (that player no longer appears in your matches). Feedback turns reporting from an input black hole into a looped collaboration.

Why it happens

Feedback sustains reporting willingness through a reinforcement loop: reporting is cooperative behaviour (paying a cost to maintain the community), and feedback confirms the cooperation (your action had effect), raising the probability of future repetition. "Perceptible" sets a higher bar than "sent": a system notice ("your report was submitted") confirms receipt, not outcome—and reporters care about outcome (was that person dealt with?). Outcome feedback's privacy balance: not disclosing specific punishments (ban length, sanction type) protects the reported player's privacy, but status tiers can be disclosed (verified and actioned / insufficient evidence), showing the reporter the system is running and the report was taken seriously. Practical evidence is the stronger form: with block-report linkage, "the player you reported no longer appears in your matches" is perceptible effect, not promise. Feedback timing binds to latency promises (see the moderation-latency card)—late feedback (handled but notified a month later) loses most of its reinforcing effect.

Where it stops holding

Feedback design's boundary is no false confirmation: batch auto-replies ("handled" for everything without actually handling) sustain report rates short-term, but the trust collapse once discovered is worse than no feedback at all—feedback content must strictly match actual processing status. Non-actioned reports (insufficient evidence) are the design-hard case: an honest "insufficient evidence, no action" may frustrate the reporter but beats a false "handled"; the message can add context ("this attempt lacked sufficient evidence; continued reports raise processing priority"), so non-action is not a dead end. Feedback granularity can tier by reporter need: most reporters want only status confirmation (handled / not handled), while high-accuracy reporters can get richer detail (the handling category confirmed)—tiered feedback balances information value and system cost. Channel choice (in-game notice, email, push) affects arrival; in-game notices arrive best and serve as the default.

Applying it

• Build a report state machine (received → under review → handled / not handled), pushing in-game notifications on every state change to the reporter, strictly synced with actual processing.
• Link blocking with reporting for practical feedback (players reported and actioned join the reporter's block list automatically), explained in the notice.
• Verification: compare subsequent reporting rates between reporters who received feedback and those who didn't—a markedly higher re-report rate in the feedback group proves feedback sustains willingness; also spot-check feedback notifications against actual outcomes to prevent false confirmations.

Related

• Same group: W9.05.1 Reporting must be simple enough to use mid-match · W9.05.2 Blocking takes effect client-side instantly, not after review · W9.05.4 Punishment must scale with severity and repeat offences
• Nearby: W9.04 Disruptive behaviour · O1.01 Trust and transparency
• Search terms: report feedback · moderation transparency · closure notification · community trust