Merchant Self-Service Portal (avoid linear support scaling)
Support headcount grows linearly with customer count. A self-service portal breaks the dependency and saves $600K-1.2M/yr at 4,800 merchants.
What
A merchant-facing self-service portal where customers handle their own routine cases — terminal status, error explanations with video, settings changes, document downloads, billing self-service. Each self-service category replaces an inbound call. The portal is designed specifically to avoid linear scaling of support headcount as the customer base grows.
Why it matters
At 4,800-merchant scale, a self-service portal avoided $600K–1.2M/year in support hiring. At 50K+-merchant scale the savings are multiplicative. The strategic point: support scales linearly with customer count unless you break the dependency. Self-service is the lever that keeps the support team flat as the business grows 3–5×.
End-to-end
- Audit the last 3 months of inbound CS contacts — bucket by category (frequency × handle time).
- Pick the top 10 categories that account for 50–70% of volume — these are self-service candidates.
- For each category, design the self-service flow: typically a status check, a documented error explanation with screenshots / 30-second video, and a "fix it yourself" action button.
- Build the portal on existing stack (React + your auth) — vibe-coded in days, not months.
- Add a "still need help?" escalation that pre-fills a ticket with the merchant's context.
- Deploy with a soft launch — promote the portal in IVR ("press 1 for self-service") and in app banners.
- Measure call deflection per category weekly; expand coverage iteratively.
Gotchas
- Don't make merchants log in twice — the portal must use the same SSO as the main app or adoption craters at 5%.
Tools
- Existing merchant auth / login
- A modern web frontend (React / Next.js)
- API access to merchant-account data, terminal status, billing
- The unified KB (#76) for documented error explanations