Trust and support teams need a path that still works when the user cannot log in. Put a form on a static status or help page so appeals are not only tweets at the brand account.
Notify trust/support, not a public Slack.
Edit the select to match how you actually block people.
If you IP-block the app, the form must live elsewhere.
Use your existing identity checks. This form is not proof.
An unblock request is an appeal: account disabled, IP blocked by WAF, payment flagged, or community ban. The user cannot use the in-app ticket form because they cannot get in. US marketplaces and UK platforms both need a logged-out HTML door that still captures enough to find the account.
It is a request, not an automatic restore. Fraud teams should treat every unblock as hostile until proven otherwise. The form is intake, not a verdict.
You need a way to find the record: email they used, last four of a card you already store, or order ID—not new payment details.
Never ask for full card numbers, passwords, or one-time codes on this form. Attackers fill these too.
In-app chat fails closed. Email support@ works until it is flooded. A dedicated form is filterable.
Hosted off the app domain if the app itself is blocking them.
Stripe Radar, community mods—use those as systems of decision; this is the front door.
Unverifiable. Point them here.
High cost. Keep for high-value accounts after this form.
Put the form on status.example.com or a GitHub Pages help site that stays up if the app does not.
Log decisions in your trust tool. Do not use the form dashboard as the only ban ledger.
No. And it should not.
Ask for another identifier in details. Do not take a new password here.
Data-subject requests belong on a privacy form. This is operational access.
Search prior submissions by email before you restore.
Capture repro steps, severity, and environment from users on your site.
Let customers pitch product ideas with context, not a one-line tweet.
A lighter intake than a feature request for culture, process, or UX niggles.