Community Management

A healthy community answers its members' questions, makes newcomers feel welcome, gives the company honest feedback, and stays safe. You keep it answered around the clock in the tone the owner set, you know the difference between a question and a complaint that needs a person, and you moderate fairly and visibly. The standard: no question left unanswered past the agreed time, every moderation action follows the published guidelines and is logged, private matters move to private channels, and nothing speaks for the company without the owner's approval.

When to use

• "Keep the Discord answered."
• "Set up a community for our customers."
• "Write our community guidelines."
• "Someone is being abusive in the forum; deal with it."
• "How healthy is our community? Give me a monthly report."
• During an outage, when the community fills with reports.

What you need

• Access to the platform: Discord or Slack as a connected app, or the owner's signed-in browser for forums and other platforms, with the moderator permissions the owner chooses to grant.
• The owner's tone, guidelines and escalation contacts from memory. If no guidelines exist, draft them first (step 2).
• Sources of truth for answers: the help centre, docs, the status page, known issues.
• The owner's rules on what you may post without approval, for example answers to documented product questions, and what always needs approval: announcements, policy statements, anything about incidents, pricing or the roadmap, and bans.

Method

1. Purpose and structure.
   • Write a one-sentence purpose, for example "where customers help each other get the most from X and tell us what to build".
   • Keep channels few and clear: welcome and rules, announcements (owner only), help or questions, show and tell, feedback and ideas, general.
   • Add channels only when an existing one is consistently crowded with a distinct topic.
   • Support is not community: account-specific problems move to private support.
2. Guidelines. Draft short, plain guidelines covering expected behaviour, what is not allowed (harassment, hate, spam, sharing personal data, illegal content, sales pitches), how to report problems, and the enforcement ladder. A good open base is the Contributor Covenant (CC BY 4.0; keep the attribution if you adapt it), trimmed to the owner's community; a starter is in references/moderation-ladder.md. The owner approves before publishing.
3. Daily rounds (schedule with cronjob; several times a day, more often in business hours):
   • Find unanswered posts older than the response target the owner set (for example 4 business hours).
   • Answer documented questions from the help centre, with a link. If you are not sure, say you are checking and come back; never guess.
   • Prefer helping members answer each other: when a member gives a good answer, thank them and add anything missing rather than replacing it.
   • Classify posts: question, bug report, feature idea, complaint, praise, off-topic, spam.
4. Complaints, account issues, bugs and ideas.
   • Complaints and account issues: acknowledge publicly in one line, ask them to continue privately (a direct message or a support ticket), and hand to support with context. Never ask for passwords, payment details or personal data in public.
   • Bug reports and ideas: thank them, ask for the details needed, and log them (see product-feedback-loop).
5. Moderate with the ladder. Act on the behaviour, not the person's popularity. For each issue:
   • check which guideline it breaks;
   • choose the step (correction, warning, temporary restriction, permanent ban) based on impact and history;
   • act, and log it: date, member, what happened (link or screenshot), step taken, who decided. Remove spam, scams, doxxing and clearly illegal content immediately and report it through the platform's tools. Temporary and permanent bans need the owner's approval unless the owner has delegated them in writing. Threats of harm or self-harm: escalate to the owner at once and use the platform's safety reporting.
6. Welcome and activate.
   • Greet new members within a day: a short personal welcome that points to the right channels and asks what they are working on.
   • Run light, regular rituals the owner approves: a weekly thread for wins or questions, office hours, showcases.
   • Recognise helpful members publicly; when a few members answer often, propose a small champions programme to the owner.
7. Announcements. Draft them for the owner: what changed, why it matters to members, what they need to do, where to ask questions. Post only after approval.
8. Incidents. When many members report the same problem: post one approved holding message (we know, we're working on it, where updates will appear), pin it, point duplicates to it, and post the approved update when it is resolved. Do not speculate about causes or timelines.
9. Health report, monthly, on a show_card and in a doc, compared with last month:
   • members, and active members (posted or reacted in the period);
   • new members, and how many posted within 30 days;
   • questions asked, the share answered, and the median time to first response;
   • the share answered by members rather than staff;
   • moderation actions by type;
   • top themes and notable feedback.
10. Feedback to the company. Weekly, summarise the top questions (help-centre gaps), bugs and ideas with counts and links, and any shift in sentiment, for the owner and product.
11. Legal and platform rules. Follow each platform's terms and safety rules. If the owner runs their own forum rather than a hosted platform, online safety and content laws may place duties on them (for example the UK Online Safety Act or the EU Digital Services Act, depending on size and audience); flag this for the owner to check rather than assuming.

Worked example: a heated thread

A member posts in the help channel: "Third outage this month. This product is a joke and your support team is useless."

• Classify: a complaint during a known incident, not a guideline breach (frustrated, not abusive).
• Public reply (within the approved incident wording): acknowledge the impact, link the pinned incident post, and invite them to message support privately so someone can look at their account.
• Private: hand to support with the member's handle, account (if they share it privately) and the outage dates.
• Log: no moderation action; sentiment noted for the weekly feedback summary. If the same member then insults a named staff member, that is a guideline breach: step 1 (a private correction), logged.

Output

• Answers and moderation actions within the owner's rules, all logged.
• Drafts for announcements, incident posts and guideline changes, for approval.
• The moderation log, the weekly feedback summary and the monthly health report.
• For a new community: purpose, channel plan, guidelines, welcome message, the first month's rituals and metrics.

Checks before you finish

• No question older than the response target is left without a reply or an "I'm checking" note.
• Every moderation action cites a guideline and is logged; bans had the owner's approval or a written delegation.
• No personal or account data was requested or discussed in public.
• Nothing speaking for the company was posted without approval.
• Health numbers recompute from the platform data, with periods stated.

Pitfalls

• Staff answering everything. It trains members to wait for staff. Encourage and credit member answers.
• Arguing in public. Acknowledge, move it private, solve it there.
• Inconsistent moderation. Letting a popular member off for what gets others banned destroys trust. Follow the ladder.
• Channel sprawl. Twenty quiet channels feel dead. Start small.
• Treating community as support. Account problems need private, accountable handling.
• Silence during incidents. A quick, honest holding message prevents a pile-on.

See also: product-feedback-loop, support-ticket-reply, help-centre-article.