SOP-097 — Community moderation & forum response

SOP · owner: Customer Success (Community Manager). Layer: SOP/Runbook (docs/canon.md). The channel ethos and the Principal’s voice live in docs/concept.md — not restated here. Pre-launch note: no live comment stream or learner forum exists yet (the channel is unlaunched; the forum is gated by ADR-0006; intranet/src/data/chatter.json is a single-user internal seed feed, not a community). This authors the moderation procedure stub-first with the core framework inline — there is no separate moderation policy file to defer to. It activates the day a real community surface exists. Unit boundaries: ../units/customer-success/charter.md.

Interface Contract

Inputs: raw community input (comment / post / thread) ← from self (Community Manager) · trigger: (channel/forum input — pending a live surface)
Inputs: moderation-policy direction / commissioned community intervention ← from Customer Success Director · trigger: briefing posted
Outputs: community signal (retention flag / moderation-policy input) → to Customer Success Director · trigger: community signal raised
Outputs: community-health report → to all agents · trigger: briefing posted
Outputs: approved community-health report → to Archivist · trigger: artifact approved
Outputs: crisis / legal-risk escalation → to Personal Assistant · trigger: (urgent escalation — PA-routed, no register edge)
Handoff trigger (in): a community input arrives, the report cadence is due, or the CS Director commissions an intervention
Handoff trigger (out): the input is classified and a response is drafted (for review) or a moderation action is recommended with rationale, severity, and a log entry; report-worthy signals reach the CS Director
Definition of Done before handoff:
- [ ] Input classified into one of five categories (praise / question / complaint / feature-request / hostile-or-harmful)
- [ ] If responding: draft in the Principal’s voice — proportionate, specific, no canned filler, no overpromise (“I’ll look into it” is the ceiling) — labeled draft pending review
- [ ] If moderating: action recommended (leave / hide / delete / warn / ban) with one-line rationale
- [ ] Severity tier assigned (routine / urgent / escalation); precedent checked for consistency
- [ ] Draft only — never published (posting requires Principal / CS Director review)
- [ ] One-line log entry appended to docs/community/log.md
- [ ] No personal data logged or handed off (PA-only); crisis/legal risk escalated immediately to the PA / Principal
- [ ] Pre-launch status stated; no fabricated community volume or sentiment
- [ ] Learnings captured to docs/knowledge/ if any
- [ ] Any produced report handed to the Archivist (0 drift)

Purpose

Hold the community consistently and with judgment: classify every input, draft genuine responses in the Principal’s voice (never canned), make moderation calls that are consistent because they check precedent, and keep the path from a community signal back to the CS Director open. Moderation is a trust signal, not a punishment mechanism — how the community is held shapes who stays in it.

When to use

A community input arrives (comment / post / thread / batch), a moderation call is needed on flagged or borderline content, the health-report cadence is due, or the CS Director commissions a community intervention.

Flow

flowchart LR
  A["Receive input<br/>+ context"] --> B{"Classify<br/>(5 categories)"}
  B -->|respond| C["Draft in voice<br/>(proportionate, specific) — pending review"]
  B -->|moderate| D["Recommend action<br/>leave / hide / delete / warn / ban + rationale"]
  D --> E["Assign severity tier<br/>(routine / urgent / escalation)"]
  E --> F{"Precedent<br/>exists?"}
  F -->|yes| G["Apply consistently"]
  F -->|no| H["Flag policy gap → CS Director"]
  C --> L["Log one line<br/>(docs/community/log.md)"]
  G --> L
  H --> L
  E -->|urgent / crisis| ESC["Escalate → PA / Principal"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  classDef d fill:#0f766e,color:#fff,stroke:#134e4a
  class A,C,D,E,G,H,L,ESC s
  class B,F d

Text fallback: receive the input with its context → classify into one of five categories (praise / question / complaint / feature-request / hostile-or-harmful). If responding, draft in the Principal’s voice — proportionate, specific, no filler, no overpromise — labeled draft-pending-review. If moderating, recommend an action (leave / hide / delete / warn / ban) with one-line rationale → assign a severity tier (routine / urgent / escalation) → check precedent: if it exists, apply consistently; if not, flag the policy gap to the CS Director. Log one line to docs/community/log.md. Crisis or legal risk escalates immediately to the PA / Principal.

Steps (the core moderation procedure)

Receive and contextualize. Take the raw content plus any context (the content it was posted on, recurring-commenter pattern, prior responses). Read/Grep docs/, hr/policies/, and docs/community/log.md for any existing guideline or precedent.

Classify into one of five categories — the category sets the default action:

Category	Default action
Positive / praise	Acknowledge briefly and authentically
Question / help	Answer directly or route to the right resource
Complaint / frustration	Acknowledge + address + note for the health report
Feature request / suggestion	Thank, log, do not promise
Hostile / harmful	Assess severity, recommend a moderation action

Draft the response (if responding). Principal’s voice: reference the actual comment, be proportionate, do not overpromise, never match aggression (de-escalate or disengage). Label it draft pending review — you draft, you do not post.
Recommend the moderation action (if moderating). One of leave / hide / delete / warn / ban, each with one sentence of rationale.
Assign the severity tier. routine (Principal reviews at next check-in) · urgent (flag immediately) · escalation (requires the Principal’s direct decision — legal risk, public crisis, harassment campaign).
Check precedent. Grep docs/community/log.md and hr/policies/ for prior decisions so the call is consistent. If none exists and the case is novel, recommend a policy update to the CS Director — consistency is the trust signal.
Log it. Append one line to docs/community/log.md (create if absent): [YYYY-MM-DD] | [platform] | [category] | [action taken] | [notable signal if any]. Notable signals (recurring themes, complaint spikes, feature-request clusters) feed the health report.
Escalate or route. Crisis / legal risk → PA / Principal immediately. Retention signal → CS Director (community signal raised). Personal context → PA.

Roles / approvers

Run by the Community Manager, who reports to and is reviewed by the Customer Success Director; the CS Director is accountable for community-health metrics to the CGEO. Moderation-policy proposals go to the CS Director for approval. Crisis/legal escalations route to the Personal Assistant → Principal.

Guardrails

Draft only — never publish. Every response is a draft for Principal / CS Director review.
Never overpromise. “I’ll look into it” is the ceiling; features/timelines need explicit Principal authorization.
No retention / brand / channel strategy. Surface signals to the CS Director; do not set strategy (those belong to CS Director / Creative / Growth).
No personal data logged or handed off — PA-only; escalate crisis/legal risk immediately.
Consistency via precedent — a moderation call with no precedent check is an inconsistent call.
State the pre-launch status — stub-first; no fabricated community data.
Do not restate docs/concept.md — link to it.

Job aid: JA-097-moderation-quick-card.md. See also: docs/units/customer-success/charter.md · the Community Manager manual (../units/customer-success/manuals/community-manager.md) · SOP-096 (learner health review — where community retention signals land).