What this solves
A production support request names the user role, affected route, affected record, expected outcome, and risk level. That lets XaıGH route the case to the right owner.
Make the owner obvious
State whether the case is worker, employer, billing, trust and safety, account access, payout, mobile, or platform behavior. If more than one area is involved, name the primary blocker first.
A clear owner prevents a payout question from being treated like a login issue or a safety report from being treated like a generic shift problem.
Name the affected record
Include the shift, application, invoice, receipt, organization, market, route, or support case that the request is about. General messages are harder to route and easier to misread.
For product behavior, include expected behavior, actual behavior, device, browser or app, and whether the issue repeats.
Respect approval boundaries
Support can investigate, route, and explain records shown in the product. It cannot use a public help article to approve payment movement, refunds, pricing changes, legal commitments, account ownership changes, production data changes, or public statements.
If the request crosses those boundaries, support should collect the evidence and move it to the proper review owner.
Before you open support
Case includes user role and primary support owner.
Affected record or route is named.
Expected and actual behavior are clear.
Request does not assume approval for money, legal, deploy, or account-control changes.