---
name: community-support
description: Run a public forum where users help each other, with seeding, moderation, and staff presence that keeps answers accurate. Use when support volume exceeds staffing and questions are broadly shareable.
---

# Community support

A working community answers questions at a scale no support team can
staff, and an abandoned one is a graveyard of unanswered questions that
damages credibility more than having no forum at all.

## Method

1. **Decide whether your audience is a community.** Products used by
   many people with overlapping problems can sustain one; niche or
   enterprise tools with few, private use cases usually cannot.
2. **Seed it before opening it.** A forum launched empty stays empty, so
   populate it with real questions and answers from support history
   (see knowledge-base-design).
3. **Guarantee a staff response time for unanswered questions.** The
   community answers most; staff must catch the rest, or trust
   collapses.
4. **Mark official answers clearly.** Users need to distinguish a
   verified answer from a plausible guess, particularly on anything
   technical.
5. **Recognise contributors deliberately.** Status, visibility, and
   access are what sustain the people carrying the volume (see
   community-building).
6. **Moderate consistently and publish the rules.** Inconsistent
   moderation drives away the contributors you depend on (see
   code-of-conduct-enforcement).
7. **Harvest good answers into documentation.** A forum thread is not
   findable long-term, and the best answers belong in the knowledge
   base.

## Boundaries

Community support handles shareable problems; anything account-specific
or confidential needs a private channel. It requires ongoing staff
investment and is not a cost saving in the first year. Wrong answers
propagate and need active correction rather than silent tolerance.
