Support requirements for an app on the web
What the web expects for user support, the URL fields that need filling, and how to answer without a team.
The field nobody thinks about
There is no console on the web, but a contact route that goes nowhere is the fastest way to turn a small problem into a refund request.
What a support page should do
- Answer the questions people actually ask, rather than listing features.
- Let someone write to a person when the answer is not there.
- Say plainly when nobody is available, instead of promising a reply that is not coming.
- Work on a phone, because that is where the person having the problem is.
Keeping it true after launch
A legal page stops being true the moment the product moves past it, usually by adding a payment provider, an analytics SDK or a sign-in. No store re-checks your pages against your build, so the drift is yours to notice.
- Re-read it whenever you add a dependency that sees user data.
- Re-check what loads on the page after any change: the cookie notice and the policy have to agree.
- Keep the URL stable. Changing where a policy lives breaks every listing that points at it.
Common questions
Can the support URL be an email link?
On iOS it has to be a web page. A mailto link is not accepted in the Support URL field.
What if I am one person and cannot answer quickly?
Say so. An honest "we answer within two days" beats silence, and an assistant that answers the common questions means most people never need you.
