Customer Support Flows

Purpose

How a Merchant or Creator gets help when something goes wrong — not addressed in any prior doc.

Email support (ties to the same infrastructure discussed for transactional email — 06. Infrastructure, Environment Strategy's separate-email-per-environment principle applies to support email too, so staging tests never reach real support queues)
In-app support link/contact form as the primary channel for logged-in users

"My payout hasn't arrived" — support checks Payout status (05. Payments) and Swich's own payout timeline before assuming something's broken; expected window unconfirmed pending real Swich integration — the original "2–7 day bank transfer window" figure was a working assumption, not Swich-verified (see FEATURE_LIST.md §7.1's Needs Clarification)
"My application was rejected, why?" — per 01. Business Logic → Notification Logic's still-open question on whether rejections include a reason; support needs a clear answer here regardless of what ships in-product
"I think I was charged twice" — support checks for genuine duplicate Sales vs. a Swich pending-then-settled display artifact; ties to Reconciliation (05. Payments) as the authoritative check
Disputing a commission clawback — escalates to Admin review of the specific Refund Handling case

Support tooling/ticketing system choice — not decided, reasonable to pick a standard tool once ready rather than build one
Whether support is staffed directly by the founder at this stage or needs a dedicated flow — reasonable to stay founder-handled through Private Beta given current scale, revisit at Public Launch

Founder decisions, full reasoning in 02. Architecture Decision Log — reflected inline above.