What should a paid community code of conduct include?

A paid community code of conduct should describe the member experience the operator is committed to maintaining rather than list prohibited behaviors. This is the structural distinction that separates a standards document that shapes member behavior from a rules document that members skim and forget. The experience-description approach works because paying members understand they have purchased a specific type of community environment; the code of conduct explains what that environment looks and feels like, not just what will get a member removed. Four dimensions should be covered. First, information quality: what kind of contributions are in scope for this community, what distinguishes a contribution that serves the community’s purpose from one that does not, and what members should ask themselves before posting. The information quality dimension is the most important for paid communities because low-quality contributions suppress participation from high-quality members who stop engaging when the signal-to-noise ratio falls below their threshold. Second, interpersonal norms: how members treat each other’s time, expertise, and context — including what constitutes an appropriate ask (one that the asker has made effort to specify) versus what constitutes an inappropriate ask (one that delegates research to the community that the asker should have done first). Third, scope: what topics and discussions belong in this community and which belong elsewhere, expressed as what the community is focused on rather than as a prohibition list. Fourth, operator role: what the operator is responsible for maintaining and what members can expect when something falls below standard. A prohibition-only code of conduct (no spam, no self-promotion, no harassment) produces members who comply with the literal rules while violating the spirit: content that meets the technical definition of non-promotional can still be low-value; a member who never self-promotes but consistently derails threads is not covered by prohibition rules. The experience-description approach creates a higher bar because it asks whether a contribution fits the community rather than whether it violates a rule.

How do you handle conflict between two paid community members?

Member-versus-member conflict in a paid community follows a separate process from behavior-specific incidents because the resolution requires addressing the dynamic between two people, not just the action of one person. The process has three stages: separate, understand, and resolve. Separate means the operator contacts each member privately and independently before any attempt at resolution. The separate-first principle is critical because attempting to resolve a conflict in public or in the same conversation as both parties present produces performative positions rather than honest accounts. Each member’s private account will differ from what they would say if the other party were present; the accurate account is the private one. Understand means the operator gathers, from each member’s private account, what they experienced and what they need for the situation to feel resolved. Understanding the resolution need is more useful than establishing factual truth about what happened: two members can have conflicting accounts of the same exchange and both be reporting their genuine experience; the resolution path depends on the resolution need, not on which account is factually correct. Resolve means the operator applies the community standards framework to each party’s behavior independently and separately. The key principle is that the operator does not resolve the interpersonal conflict between the members — that is not achievable and attempting it often worsens the situation. The operator resolves whether each member’s behavior meets the community’s standards. If Member A’s behavior is within standards, the operator communicates that privately to Member A without reference to Member B’s account. If Member A’s behavior is outside standards, the standard behavior-specific escalation process applies to Member A’s behavior, again without reference to Member B. The most common conflict-handling mistake is treating a member-versus-member conflict as a dispute to be adjudicated, which positions the operator as a judge deciding who is right. Operators who adjudicate conflicts consistently lose: at least one party will feel the outcome was unjust, and a paying member who feels the operator sided against them in a dispute is highly likely to cancel within 60 days.

When should you remove a paying member from a paid community?

A paying member should be removed when one of three conditions applies: the behavior is severe enough that the private-first escalation process is not appropriate (threats, doxxing, content that harms other members, behavior that would expose the operator to legal liability); a stage-one private DM has been sent, a response window of 48 hours has elapsed, and the behavior has continued or the member has not acknowledged the message; or the member is a repeat stage-one case who has resumed the behavior after a previous stage-one DM resolved the situation. The third condition is the one most operators avoid because it requires removing a paying member based on a pattern rather than a single incident severe enough to justify immediate action. The principle behind the pattern-based threshold is that the cost of a false negative — keeping a member whose behavior degrades the experience for other members — is higher than the cost of a false positive — removing a member who might have changed without removal. Paid community members who observe that a behavior pattern persists without consequence lower their own participation: they begin to filter what they post, disengage from channels where the pattern-behavior member is active, and eventually stop engaging in the community at the level they joined to engage at. This churn is invisible in the moderation data because it does not produce incidents; it shows up only in cohort activation rates and month-three retention numbers. Removal should always be preceded by a notification message sent privately, not posted publicly. The notification message states the decision (not a debate), references the community standard that applies, and does not invite a response arguing against the decision. The goal of the notification message is to give the member a clear account of what happened and why, not to achieve agreement. A member who understands why they were removed and does not agree is a better outcome than a member who does not understand and contacts the operator repeatedly or publicly.

How do you write a moderation escalation framework for a paid community?

A moderation escalation framework for a paid community has two stages: stage-one private DM and stage-two action. The framework is written as a decision matrix rather than a procedure because the right first action and the right response window depend on the type of incident, not on a generic process that treats all incidents the same. Writing the framework as a decision matrix forces the operator to answer, before any incident occurs, the questions that are hardest to answer objectively in the moment: is this incident severe enough to bypass the private-first process? How long do I give a member to respond before escalating? What options are available at stage two and how do I choose between them? The escalation decision matrix has five incident types as rows and five decision variables as columns. The five incident types are: (1) borderline behavior that has not yet affected another member; (2) behavior that has clearly affected another member; (3) behavior that clearly violates a community standard without ambiguity; (4) a member who has previously received a stage-one DM and resumed the behavior; (5) behavior severe enough that private-first is not appropriate. The five decision variables are: whether to use stage-one DM or bypass it; the response window; stage-two options if unresolved; an example of triggering behavior for each type; and who else is notified (typically: no one for stage-one, a co-moderator or co-operator for stage-two). The framework is written in advance and applied consistently because inconsistent escalation — where the operator’s response depends on the specific member’s tenure, payment tier, or relationship with the operator — is the most common source of moderation errors in paid communities. A long-tenure paying member who engages in stage-two behavior should receive the same process as a new member who engages in the same behavior; the framework makes this consistency a documented commitment rather than a judgment call under pressure. Review the framework after each stage-two incident to verify it produced the right outcome. If the outcome was wrong, update the matrix before the next incident, not during it.

Moderation Playbook Reference Card

Paid community moderation playbook — escalation decision matrix, scenario-type classification, community standards template, exit conversation script, and moderation load benchmarks

This page is a structured reference card for paid community operators building or auditing a proactive moderation architecture. It covers: an escalation decision matrix for five incident types — borderline but unaffected, clearly affected another member, clear standard violation, repeat stage-one case, and severe-bypass — with whether to use stage-one DM or bypass, response window, stage-two options if unresolved, example triggering behavior, and who else is notified; a scenario-type classification table for four scenario types — value-misalignment, behavior-specific incident, member-versus-member conflict, and structural toxicity — with root cause, impact pattern, resolution path, indicators, and why standard moderation tools fail for each type; a community standards template for four dimensions — information quality, interpersonal norms, scope, and operator role — with what to write, an example statement, what not to write, and where each dimension appears in onboarding; an exit conversation script for the two stages — notification message and feedback request — with what to include, what to avoid, an example opening, and what the data each stage produces; and a moderation load benchmarks table for four metrics — stage-one incidents, conflict incidents, stage-two escalation rate, and removal rate — with healthy range, warning signal, what each metric diagnoses, and the highest-leverage intervention. For the conceptual framework behind these tables — why reactive moderation is the wrong architecture for paid communities, the inverted cost calculation between false positives and false negatives, and why private-first escalation produces more accurate decisions than public or simultaneous approaches — see the companion post: Paid community moderation playbook: from reactive to proactive. This card is for the operator who understands the reasoning and needs the escalation matrix, scenario classification, standards template, exit script, and load benchmarks in quick-reference form.

TL; DR

Reactive moderation — waiting for a member to report a problem and then responding to the report — is the wrong architecture for paid communities because the cost of a false negative (allowing behavior that degrades the member experience) is higher than the cost of a false positive (acting on behavior that turns out to be less severe than it appeared). Paying members hold operators accountable for maintaining the standard they purchased, and a member who experiences a degraded standard without visible operator response cancels not because of the incident but because of the absence of a response to it. The proactive architecture has four layers: community standards that describe the experience members pay for rather than a prohibition list; a two-stage escalation framework (stage-one private DM within 24 hours, stage-two action after a 48-hour response window); a scenario classification process that identifies whether the situation is value-misalignment, behavior-specific, member-versus-member conflict, or structural toxicity before applying a response — because each scenario type has a different resolution path and applying the wrong process produces wrong outcomes; and exit conversations that produce three categories of data the operator cannot collect elsewhere. Table 1 gives the escalation decision matrix. Table 2 gives the scenario-type classification. Table 3 gives the community standards template. Table 4 gives the exit conversation script. Table 5 gives the moderation load benchmarks. If you can only do one thing: write the escalation decision matrix before you have an incident that requires it, not during. Operators who write the matrix during a live incident make exceptions they later regret because the decision is made under relational pressure rather than against a pre-committed standard.

Table 1 — Escalation decision matrix

Five incident types that cover the range of situations a paid community operator will encounter, each with a different answer to the five most consequential moderation decisions: whether to open with a private DM or bypass it in favor of immediate action, how long to give a member to respond before escalating to stage two, what options are available at stage two if the stage-one DM does not produce a resolution, an example of behavior that places an incident in each type, and who else in the operator’s team should be aware of the situation. The matrix is not a procedure that applies in sequence — it is a classification tool. The first step in any incident is to identify which of the five incident types applies, then read across the row for the decision variables that apply to that type. The most common moderation error is treating all incidents as the same type and applying a generic process — which means either over-responding to borderline incidents (escalating a stage-one situation to stage-two action before the response window has elapsed) or under-responding to severe incidents (opening with a DM when the incident type calls for immediate action). Both errors have costs: over-response in a borderline situation damages the relationship with a member who might have self-corrected; under-response in a severe situation allows harm to other members while the operator waits for a DM response that does not need to happen. Write the classification decision before writing the DM — five seconds of incident-type identification prevents most response errors.

Incident type	First action: stage-one DM or bypass?	Response window	Stage-two options if unresolved	Example triggering behavior	Who else is notified
Borderline — behavior not yet affecting another member	Stage-one DM. This incident type is the core use case for the private-first approach: the behavior has not yet produced harm to another member, the operator cannot be certain the member understands how the behavior reads in this community, and a private DM creates the possibility of self-correction without a record of a public intervention. Opening with a DM at this stage is not leniency — it is an investment in the most accurate possible response: the private DM reveals whether the member will engage constructively (indicating a misunderstanding) or will not acknowledge or will repeat the behavior (indicating the escalation should proceed). A public response or a warning-post at this stage produces defensiveness and does not produce the information the private DM produces.	48 hours from send time. If no response to the DM within 48 hours, treat as unresolved and proceed to stage two. Do not extend the response window because the member has not replied — no response to a direct private message from the community operator is itself a signal, and the response window exists to prevent indefinite waiting while the behavior continues or other members are affected. If the member responds constructively within the window (acknowledges the concern, asks a clarifying question, describes what they intended), the stage-one resolution is complete and no stage-two action is required. Document the interaction — date, behavior type, DM sent, response received — regardless of outcome, so that any future incident from this member is classified as a repeat-stage-one case.	Three options in order of severity: (1) Re-send a single follow-up DM that states the community standard directly and the consequence of continuation, with a 24-hour window — appropriate when the behavior has not recurred and the 48-hour non-response might be a Slack notification miss. (2) Temporary channel restriction: remove posting permissions in the channel where the behavior occurred for 7 days, with a DM explaining the restriction and its duration — appropriate when the behavior has recurred during the 48-hour window. (3) Removal: appropriate when the behavior is at the high end of the borderline range, has recurred, and the member has not acknowledged the DM after a follow-up. Do not use removal as the stage-two response to a single borderline incident with no DM response — the stage-two escalation sequence exists to ensure the member has been given a genuine opportunity to understand and respond before the most permanent action is taken.	A member posts a self-promotional link in a non-promotional channel without framing it as a resource offer. A member’s question in a peer-advice channel is phrased in a way that delegates research to the community rather than seeking peer perspective on a specific decision. A member consistently reacts with one-word responses in discussion threads in a way that closes threads rather than continuing them. A new member posts an introduction that contains a pitch embedded in the background section. None of these has yet created a visible negative reaction from another member; all of them are below the threshold of a clear standard violation but above the threshold of tolerable-without-acknowledgment.	No one. Stage-one DMs are private, and the operator’s contact with the member should not be visible to other members or to team members unless the situation escalates. Keeping stage-one DMs private protects the member from reputational damage for behavior that has not yet required stage-two action and protects the operator from appearing to conduct moderation as a performance rather than as a standard-maintenance process. If the situation has been escalating over multiple interactions, a co-operator or community manager who is involved in the ongoing situation is an appropriate notification at stage one; a passive co-operator or team member who is not involved in this member’s interactions should not be notified at stage one.
Behavior that has clearly affected another member	Stage-one DM to the member whose behavior caused the effect. Simultaneously, if the affected member is visible (tagged, quoted, or referenced in the incident), send a separate private DM to the affected member to acknowledge the situation and confirm the operator is addressing it. The two DMs serve different purposes: the DM to the behavior-member opens the stage-one resolution process; the DM to the affected member addresses the immediate relational damage — a paying member who has been visibly affected by another member’s behavior and receives no signal from the operator that the situation is acknowledged will interpret the silence as operator indifference. The affected-member DM does not need to describe what action is being taken with the other member; it should confirm the operator is aware, the situation is being addressed, and the operator will follow up within 24 hours. This second DM is the most commonly omitted step in paid community incident response, and its omission is the direct cause of most affected-member cancellations following an incident.	24 hours from send time to the behavior-member, down from the 48-hour window for borderline incidents. The shorter window reflects that another member has been affected and the behavior-member’s response time is now a secondary factor in the operator’s obligation to the affected member. If the behavior-member responds constructively within 24 hours, the operator can follow up with the affected member with an accurate account of the resolution. If the behavior-member does not respond within 24 hours, the operator should proceed to stage two and communicate a resolution to the affected member based on what was done, not on what the behavior-member said in response. Do not leave the affected member in uncertainty for longer than 24 hours while waiting for the behavior-member’s DM response.	Same three options as the borderline type, applied with a higher threshold for escalation: temporary channel restriction is appropriate as a stage-two response to affected-member incidents when the DM does not produce acknowledgment within 24 hours, regardless of whether the behavior has recurred. The asymmetry from the borderline type reflects that another member has already been affected: the response window concession that applies to borderline incidents (“maybe they missed the Slack notification”) does not override the operator’s obligation to the affected member. At stage two, the affected member should receive a DM confirming what action has been taken and when, without specifying which action — the affected member does not need to know whether the behavior-member received a follow-up DM or a channel restriction; they need to know the situation has been addressed and what to do if a similar situation occurs.	A member tags another member in a reply that dismisses their question or contribution in a way that reads as contemptuous rather than constructive. A member uses private information shared by another member in a public thread without permission. A member replies to a new member’s introduction or first post in a way that makes the channel feel unwelcoming to that specific member. A member corrects another member’s technical claim in a way that is accurate but is framed to humiliate rather than to inform. A member copies the content of another member’s post and reposts it as their own question or contribution. In all these cases, a specific other member is identifiable as having been affected by the behavior.	A co-operator or community manager should be notified when a stage-one DM is sent for an affected-member incident, even if the situation resolves at stage one. The co-operator notification serves two purposes: documentation of the incident so that any future behavior from either member is understood in context, and backup awareness in case the operator is unavailable during the 24-hour response window and the situation requires a stage-two decision. The affected member’s name should be in the internal notification; other members should not be notified.
Clear standard violation without ambiguity	Stage-one DM, but the DM is written differently from the borderline and affected-member DM types. For a clear standard violation, the stage-one DM states the community standard that applies, describes the specific behavior that violated it, and describes the consequence if the behavior recurs or is not resolved — it does not ask for clarification about what the member intended or leave open the interpretation that this might be a misunderstanding. The difference from the borderline DM type is that a clear violation is not a possible misunderstanding: the member knows or should know that the behavior falls outside the community’s standards, and the DM should reflect that without being adversarial. The goal of the DM at this incident type is to create a clear record that the operator communicated the standard, the violation, and the consequence, so that any stage-two decision is fully documented. Keep the DM short: one sentence on the behavior, one sentence on the standard, one sentence on the consequence.	48 hours, but with an important distinction from the borderline type: if the behavior is ongoing (the post or thread is still visible to other members), remove the content before sending the DM, and note in the DM that the content has been removed and why. The content removal is not the stage-two action; it is a parallel action that protects other members during the response window. Removing content without a DM explanation produces confusion and resentment; removing content with a simultaneous DM explanation produces understanding. If the content cannot be removed (because it is in a context where removal would be visible to other members in a disruptive way), add a moderator note in the thread that the content has been flagged for review and will be addressed, without naming the member.	Removal is the appropriate stage-two response for a clear standard violation where the DM has been sent, the response window has elapsed, and either the behavior has continued or the member has not acknowledged the DM. The stage-two option hierarchy from the borderline type (re-send follow-up, then channel restriction, then removal) applies here in compressed form: the re-send follow-up option is applicable only when the violation is at the low end of the clear-violation range; channel restriction is applicable when the violation is mid-range and there is evidence the member is still present in the community; removal is the default stage-two response when no response has been received after the response window for a mid-to-high clear-violation. Operators who apply the borderline-type escalation hierarchy to clear-violation incidents consistently and channel restriction is the standard stage-two response for any incident type.	Undisclosed affiliate link in a resource recommendation thread. Prohibited content type explicitly named in the community standards (political content in a non-political community, content that names or identifies a non-member in a way that creates a privacy concern). A member who contacts other members via DM to solicit business after an operator warning not to do so. A member who replicates a conversation from the community workspace verbatim in a public post or publication without permission. A member who creates a second account after their first account received a stage-two action. In each case, the community standard that applies is specific and the behavior fits clearly within it without requiring interpretation.	A co-operator or community manager for documentation. If the violation involves another member’s content or privacy (e.g., an undisclosed affiliate link in a thread where members were expecting unbiased recommendations), the thread participants who may have acted on the content should be notified that the content has been removed and why, without naming the member who posted it — a community-facing message that the information in the thread has been updated is appropriate; a public call-out of the member by name is not.
Repeat stage-one case — prior DM sent, behavior resumed	Stage-one DM only if this is the second incident and the first incident resolved at stage one with a constructive response from the member. For a member who has had a previous stage-two action or who has had more than two stage-one incidents, the stage-one DM is not appropriate; the pattern constitutes a stage-two situation from the first sign of recurrence. For the second-incident case where the first resolved constructively, the stage-one DM should reference the prior conversation explicitly: “We spoke previously about [behavior type] on [date]. I’m following up because I’m seeing [specific new behavior].” The explicit reference to the prior conversation is necessary because it changes the information content of the DM: without the reference, the second DM is a new request; with the reference, it is a documented pattern. Never pretend a prior conversation did not happen; members who have had a prior stage-one DM and receive a second DM with no reference to the first will correctly perceive that the operator has no institutional memory of the situation and will expect the same resolution outcome as the first time.	24 hours, reduced from the standard 48-hour window for borderline incidents. A member who has previously been contacted about the same behavior type and has resumed the behavior has already had the maximum response-window concession; reducing the window for repeat cases reflects that the member has had a full first-response-window to demonstrate constructive engagement and the recurrence indicates the stage-one process has reached its limit for this member. If the member responds to the repeat DM within 24 hours with a constructive acknowledgment and specific account of why the behavior recurred, the operator can extend to 48 hours if the explanation warrants it; the default is 24.	Removal is the default stage-two response for repeat stage-one cases where the response window has elapsed without resolution. Channel restriction is applicable only when the repeated behavior is limited to a specific channel context and there is a credible reason to believe the member can participate constructively in other channels; this is a narrow exception. The repeat-stage-one classification places the burden of evidence for a restriction-over-removal outcome on the behavior-member: if they have not responded constructively to two stage-one DMs about the same behavior type, the evidence base for a channel-restriction outcome is weak. Document the decision and the evidence that applied to it in the internal moderation log regardless of outcome.	Any behavior from the previous stage-one incident type list where the operator has a documented record of a prior DM about that behavior type. The documentation record is the key determinant: without a documented prior DM, a repeat incident should be classified by the behavior type alone, not by operator memory of a conversation. Operators who do not document stage-one DMs lose the classification information that distinguishes a first-incident borderline case (where the response window is 48 hours and the stage-two default is channel restriction) from a repeat case (where the response window is 24 hours and the stage-two default is removal). Maintain a one-line log per incident: date, member, behavior type, DM sent, response received or not, outcome.	A co-operator or community manager should be notified at the start of the stage-one DM for a repeat case, because the likelihood of a stage-two action is higher for repeat cases and the stage-two decision should not be made unilaterally if co-operators are available. In communities with more than one operator or moderator, the repeat-case DM is the appropriate point to bring a second person into the awareness loop before the stage-two decision is needed, not at the stage-two moment when the decision pressure is highest.
Severe — bypass private-first process	Bypass stage-one DM. Immediately remove the content, remove the member from the workspace, and send a post-removal notification DM that states the community standard that applied and the action taken. The bypass decision is appropriate when any of three conditions applies: the behavior constitutes a threat to a specific member or to the community; the behavior exposes the operator to legal liability (doxxing, CSAM, defamation of a named individual); or the behavior is so harmful to other members that allowing the member to remain in the workspace during any response window would itself be an operator failure. The bypass should be used narrowly — operators who classify too many incidents as severe and bypass stage one will remove members who could have been addressed through the standard process, which is both bad for the member relationship and sets a precedent of removal as the default response. The test for bypass is simple: would a reasonable paying member, upon seeing this behavior, expect the operator to have removed the content and the member on the same day without a DM process? If yes, bypass. If uncertain, classify as clear-violation and use the 48-hour DM-then-remove process.	No response window. The post-removal notification DM is sent within an hour of the removal action, not as a request for response but as a factual account of what happened and why. The member has no standing to reverse the removal through the DM; the notification exists to prevent the member from being confused about why they no longer have access, which reduces the frequency of public complaints about unexplained banning. If the member responds to the notification DM to dispute the removal, the response should be a single reply that restates the behavior and the standard without debate or negotiation. Do not engage in a multi-message exchange about a bypass removal; it extends the operator’s emotional labor without changing the outcome and provides the member with material they can use in a public complaint by selectively quoting operator responses.	No stage-two options; stage two in this context is post-removal. After removal, two actions are appropriate: a community-facing message in the relevant channel that notes a member has been removed for violating community standards, without naming the member or describing the behavior (the transparency that the community’s standards are enforced is valuable; the public account of the specific behavior is not); and an internal debrief to document whether the bypass classification was correct, whether any stage before the incident provides a moderation lesson, and whether any other members were affected who have not yet reported it. The debrief is not a performance review of the decision; it is a standards-calibration exercise for the escalation matrix.	A member threatens another member by name in a public channel or via private DM that is then reported to the operator. A member shares another member’s private contact information, employer, or location without permission. A member posts content that constitutes harassment of a specific individual. A member uses the community workspace to coordinate action against an identified person outside the community. In each case, the behavior is not a community norm violation that the member may not understand; it is conduct that no reasonable operator would leave unaddressed for 48 hours regardless of whether the member has a prior incident record or a long tenure in the community.	All co-operators and community managers should be notified immediately upon action, not upon completion of the process. For bypass incidents, the post-removal co-operator notification should include the behavior type, the content removed, and the time of removal. If any affected member has been identified, they should receive a direct private message from the operator within one hour of the removal confirming that the situation has been addressed. If the behavior constitutes a potential legal issue, document the content before removal (screenshot with timestamp) and consult legal counsel before any public statement. Do not discuss the details of the removal publicly or in response to member inquiries beyond confirming that community standards were applied.

The five incident types are not strictly sequential: a new member can have a bypass-level incident as their first community interaction, and a long-tenure member can produce a borderline incident after years of constructive participation. The incident type is determined by the behavior and its impact, not by the member’s history, tenure, or payment tier. The history does affect the stage-two options (a repeat-stage-one member has fewer stage-two options than a first-incident member in the same behavior category), but it does not affect the incident-type classification that determines the first action. See the companion post for the cost calculation showing why proactive classification produces better outcomes than reactive incident-by-incident judgment.

Table 2 — Scenario-type classification table

Four scenario types that a paid community operator will encounter, each with a different root cause, impact pattern, resolution path, set of observable indicators, and explanation for why the standard moderation tools — a DM, a warning, a content removal — fail to resolve it. The scenario classification step happens before the escalation matrix: the first question in any moderation situation is not “what do I say in the DM?” but “what kind of scenario is this?” because the DM that resolves a value-misalignment scenario is not the DM that resolves a member-versus-member conflict, and applying the member-conflict process to a structural-toxicity scenario will produce no resolution at all. The four scenario types are not mutually exclusive in a single member’s behavior — a member who consistently produces behavior-specific incidents in one thread context may also be contributing to structural toxicity if their behavior pattern has changed the participation behavior of other members in that context. But for any single incident, the scenario type that best describes it should be identified before the response is designed. The most common classification error is treating a value-misalignment scenario as a behavior-specific incident and sending a moderation DM to a member whose behavior reflects a genuine expectation gap about what kind of community this is — a DM in that case addresses the symptom (the behavior) without addressing the cause (the expectation gap), and the behavior recurs because the cause has not changed.

Scenario type	Root cause	Impact pattern	Resolution path	Indicators that identify this type	Why standard moderation tools fail for this type
Value-misalignment	The member has a genuine and sincerely held expectation about what kind of community this is — what topics are in scope, what level of expertise is expected, what kind of contribution is valued — that does not match the operator’s design intent or the community’s actual culture. The expectation gap often originates in the landing page, the onboarding sequence, or the first-week experience: a member who joined based on a broad description of the community and found a narrower, more expert-level environment than they expected; a member who joined based on the topic and found a different discussion culture; a member who was referred by another member and whose use case differs from the referrer’s. The root cause is not bad intent; it is a genuine information asymmetry about what the community is for.	Intermittent rather than sustained. The member participates at a normal rate but occasionally produces contributions that do not fit the community’s expectation level or topic scope. The impact is diffuse: individual contributions are below standard, but no single contribution is severe enough to constitute a clear violation. Other members may reduce engagement with the value-misalignment member’s threads over time without explicit complaint. The member may not notice that their contributions are receiving fewer responses than expected, because they are comparing to a different norm. Long-term impact: if the misalignment is not addressed, the member will either self-select out (cancel because the community is not what they expected) or continue producing below-standard contributions at a rate that gradually reduces the signal-to-noise ratio for other members.	A values-alignment conversation, not a moderation message. The private conversation describes what the community is designed for, what kinds of contributions fit the design, and invites the member to describe what they were expecting or looking for. This conversation has a different goal from a stage-one DM: it is not documenting a behavior against a standard; it is establishing whether the member’s use case fits the community. The outcome of the conversation has three possibilities: the member understands the expectation and adjusts their participation style (alignment achieved); the member decides the community is not the right fit and exits voluntarily (clean outcome); or the operator determines that the community’s expectations and the member’s use case are incompatible and offers a refund or an alternative resource (the operator initiates the exit). The values-alignment conversation should not reference the moderation framework or the escalation process, because doing so frames the conversation as a warning rather than an alignment check.	The member’s contributions are topically within scope but tonally or depth-wise mismatched to the community standard. The member asks questions in peer-advice channels that reflect a lower expertise level than the community’s ICP. The member posts positively (not critically or provocatively) but the posts do not generate engagement from other members. The member’s introduction described a use case or goal that is adjacent to but not within the community’s core purpose. No other member has complained about this member, but the operator has noticed a pattern of below-standard contributions. The member engages positively in the values-alignment conversation and does not become defensive when the expectation gap is named.	A moderation DM fails for value-misalignment because it treats a misalignment as a behavior violation, which the member will correctly perceive as unjust. A member who genuinely believes their contributions are appropriate for this community and receives a DM telling them their behavior falls outside community standards will be confused, then resentful, then more likely to cancel than a member who receives a values-alignment conversation that treats the situation as an information problem rather than a behavior problem. Content removal fails even more severely: removing a value-misalignment member’s content without explanation signals that the community has unexplained rules that the member cannot see, which is demotivating for a member who was participating in good faith. The correct tool for value-misalignment is private conversation, not moderation action.
Behavior-specific incident	The member knows (or reasonably should know) that the behavior falls outside the community’s standards, and chooses to engage in it anyway. The root cause can be: deliberate boundary-testing (the member is checking whether the standard is enforced); situational lapse (the member knows the standard but in this context made a choice they would not defend if asked); or habitual behavior that the member applies without considering whether it fits this specific community context. The distinction between deliberate and situational matters for the stage-one DM framing: a situational-lapse DM can acknowledge that the member’s record does not suggest this is a habitual behavior; a deliberate boundary-testing DM should not make that acknowledgment because it signals that the operator noticed the departure from standard. Both receive the same stage-one process; only the DM framing differs.	Specific and isolated. A single post, reply, thread, or interaction that falls outside the community standard, with no broader pattern of below-standard contribution before or after the incident. The impact is local: the incident affects the thread or channel where it occurred, may affect one or more specific other members, but does not produce the diffuse across-community impact that structural toxicity produces. The member’s baseline participation quality, before and after the incident, is within standard. The incident stands out against the member’s history as an anomaly, not as a representative sample.	The stage-one private DM process from Table 1, classified by the incident type within the behavior-specific category (borderline, affected-another-member, or clear-violation). The DM approach for behavior-specific incidents works because the member has the information needed to understand what the DM is referring to, why it falls outside the standard, and what to do differently. The resolution of a behavior-specific incident is complete when the member acknowledges the DM and the behavior does not recur; the operator does not need to achieve a deeper understanding of the member’s intent or the community’s design. The most important element of the behavior-specific DM is specificity: the DM should describe the specific behavior, the specific standard, and the specific consequence of recurrence — a DM that is vague about any of these three elements leaves the member uncertain about what they should change and uncertain about whether the operator will enforce the consequence.	The behavior is a departure from the member’s established participation pattern. The behavior fits clearly into a recognized behavior category (promotional, dismissive, off-topic, privacy-violating, standard-violating) rather than requiring interpretation. Other members may have noticed or reacted to the behavior but have not filed formal reports — the operator noticed it through normal monitoring rather than through a complaint. The member’s response to the stage-one DM, if they respond, is either constructive acknowledgment or a clarification that it was an error rather than a defense of the behavior. The behavior does not recur after the stage-one DM in the standard case.	The standard moderation tools work well for behavior-specific incidents when applied correctly: the DM produces a constructive response in most first-incident cases, the stage-two options cover the non-constructive cases, and the escalation matrix from Table 1 provides the decision variables for each sub-type. The failure mode for this scenario type is misclassification: treating a behavior-specific incident as value-misalignment (sending a values-alignment conversation instead of a DM) leaves the member uncertain about whether the behavior had consequences and allows recurrence without a documented prior contact; treating a behavior-specific incident as structural toxicity and designing a programming intervention rather than a member-specific DM addresses no one in particular and may draw other members’ attention to the behavior without addressing its cause.
Member-versus-member conflict	A dynamic between two specific members that has produced visible tension, a public exchange, or a private report from one member about another. The root cause is interpersonal rather than individual: neither member’s behavior alone would necessarily trigger a moderation response, but the interaction between them produces a result that falls below the community’s standard for interpersonal norms. Common origins: two members with competing expertise claims in the same domain; a member who provided feedback that the receiving member experienced as dismissive; two members who arrived from different prior communities with incompatible discussion norms; a member who perceived a prior exchange as unresolved and carries the tension into subsequent interactions. The root cause may be legitimate disagreement about the community’s standards — two members with different definitions of what constitutes helpful advice will produce conflict in a peer-advice channel without either member intending to violate a standard.	Concentrated in the specific channel context or thread where the two members interact. Other members may reduce engagement in that context to avoid the dynamic, but the impact is more targeted than structural toxicity. The pattern is episodic rather than continuous: conflict incidents cluster around specific trigger contexts (a thread where both members posted, a live session where both attended) rather than appearing uniformly across the community. If unaddressed, member-versus-member conflict escalates over time: each incident adds to the accumulated grievance the members carry into the next interaction, and the threshold for triggering a visible conflict lowers with each unresolved episode. The impact on first-week new members who observe a conflict dynamic in their first days is disproportionately high: a new member who encounters a visible interpersonal tension as their first community experience concludes that the community is unsafe to post in and does not post.	The separate-understand-resolve process: contact each member privately and independently, gather their account of what they experienced and what they need for the situation to feel resolved, apply the community standards framework to each member’s behavior independently, and communicate the outcome to each member separately. The resolution the operator communicates is not a judgment about who was right in the conflict; it is an account of whether each member’s behavior met community standards and, where it did not, what the consequence is. A member who receives a resolution DM that does not adjudicate the conflict but does confirm their own behavior was within standards (and where applicable that the other member’s behavior has been addressed) will experience the resolution as fair more often than a member who receives an adjudication that decided against them. See the FAQ below for the full separate-understand-resolve process.	Both members are otherwise constructive community participants. The conflict is localized to specific interaction contexts rather than distributed across the community. One or both members have reached out to the operator privately about the other. The incidents involving both members show a pattern of escalation over multiple interactions rather than a single event. Other members have begun to avoid the channels or threads where the conflict-pair tends to interact. New-member activation in those channels has declined but activation in other channels has not changed — a localized pattern consistent with two specific members rather than a community-wide culture problem.	A standard moderation DM to one member fails for member-versus-member conflict because it addresses one behavior-instance without addressing the dynamic that produced it. After the DM, the two members will interact again, the dynamic is still present, and the next conflict incident will occur in a different thread or channel where the DM’s reference to the specific prior instance is no longer directly relevant. Content removal fails for the same reason: removing a conflict-thread removes the visible evidence of the dynamic without reducing the dynamic itself. The failure of standard tools for this scenario type is that they address artifacts (the specific posts, the specific exchange) rather than the source (the relationship and expectation dynamic between two people). The separate-understand-resolve process addresses the source; it is slower and requires more operator effort than a DM, which is why operators default to the DM and then encounter the same two members in a new conflict incident 3–4 weeks later.
Structural toxicity	A pattern of behavior distributed across multiple members that, in aggregate, suppresses participation by members who hold different perspectives, contribute different types of content, or are in the early stages of their community tenure. No single member is primarily responsible; each member’s individual behavior might be within the community’s explicit standards. The harm arises from the cumulative effect: a channel where replies to beginner-level questions are consistently more critical than replies to expert-level contributions will suppress beginner-level questions even if no individual critical reply violates a standard. Structural toxicity is the scenario type most predictive of new-member churn because it operates precisely in the first-week window: new members who are deciding whether to post encounter the cumulative culture before they have enough community history to filter it, and they use the aggregate signal as their guide for whether to contribute.	Distributed across the community rather than localized to specific members or channels. The first signal of structural toxicity is often a data pattern rather than a visible incident: first-week post rate declines while member join rate stays flat; contribution rate differences between members who joined in different cohorts (earlier cohorts contributing more freely than later ones); specific channels with lower-than-expected participation despite high-quality member presence; direct messages to the operator from new members asking whether it is okay to post a particular type of question. The pattern intensifies over time if unaddressed: as fewer new members post in their first week, the existing distribution of who posts becomes more concentrated, and the implicit social norm of who this community is for narrows further.	Programming intervention, not individual member moderation. Structural toxicity cannot be resolved by identifying one or two members whose behavior is causing the pattern, because the pattern is not caused by one or two members — it is an emergent property of the community’s culture, norms, and programming design. The resolution path has three elements: (1) introduce programming that explicitly models the behavior the structural pattern is suppressing — if beginner-level questions are being suppressed, an operator-led thread that responds warmly and specifically to a beginner-level question models the expected reply behavior at scale; (2) revise the community standards document to name the suppressed behavior category as in-scope and valuable — “questions from members who are early in their practice are exactly what this community is for” addresses the implicit norm directly; (3) apply the stage-one DM privately to members whose specific contributions are the clearest examples of the suppressing pattern — not as a community-wide announcement but as individual conversations that name what was observed and why it matters. The programming intervention changes the norm; the individual DMs address the most prominent contributors to it. Both are necessary; either alone produces incomplete resolution.	A gap between the community’s explicit standards (which describe an inclusive participation culture) and the actual experience of new members in their first two weeks. First-week post rate below 30% despite an active member base. Exit survey data from non-renewing members citing a sense that the community was for a different level of practitioner than themselves. Members who activate in their first week but do not return in week two at rates higher than members who activate and post in both weeks. Thread reply patterns where certain contribution types (questions from non-experts, minority-perspective contributions, personal experience contributions) receive consistently lower engagement or more critical replies than other types. A concentration of participation in a subset of members who have been in the community the longest.	Standard moderation tools fail for structural toxicity because they are designed to address individual behavior, not aggregate patterns. A DM to the most visibly dismissive member in a structurally toxic channel will reduce that member’s dismissive replies; it will not change the reply behavior of the other 15 members who are producing the same pattern at lower individual volume. Content removal for structural toxicity is especially counterproductive: removing critical or dismissive replies makes the individual incident invisible but does not change the behavioral norm, and the members who produced those replies will produce similar content in the next thread where their social permission to do so has not been challenged. The programming intervention is the correct tool because it addresses the norm rather than individual instances of the norm — it changes what behavior is reinforced rather than what behavior is penalized.

The four scenario types often require sequential classification rather than parallel consideration: a member-versus-member conflict may surface a value-misalignment in one of the members that is a contributing cause; a structural toxicity pattern may be driven by a small number of behavior-specific incidents whose accumulated weight is producing the pattern. The classification step is iterative, not single-pass. When a scenario does not resolve after applying the initial classification’s resolution path, check whether the residual is a different scenario type. A value-misalignment conversation that does not resolve the behavior pattern suggests reclassification as behavior-specific; a behavior-specific DM that resolves the incident but does not reduce the pattern suggests reclassification as structural toxicity. See the cancellation flow post for how exit survey data identifies which scenario type was operating invisibly in the months before a member cancelled.

Table 3 — Community standards template

Four dimensions that a paid community code of conduct should address to function as an experience-description document rather than a prohibition list. The experience-description approach describes the community environment the operator is committed to maintaining; members read it and understand what they are paying for, not just what will get them removed. The four dimensions are not exhaustive of every possible community standard — specific communities may need additional dimensions for their niche (a health-focused community will need a clinical accuracy dimension; a professional services community will need a confidentiality dimension) — but they are the four dimensions that apply to all paid communities and that, if absent, produce the most common categories of moderation failure. The template columns provide what to write (the instruction for each dimension), an example statement (a concrete illustration of what the dimension looks like in the operator’s voice for a paid Slack community), what not to write (the failure version that converts the dimension from experience-description to prohibition), and where each dimension appears in the onboarding sequence so that new members encounter it at the moment it is most relevant to their current experience rather than in a single document they are unlikely to re-read.

Dimension	What to write	Example statement	What NOT to write	Where it appears in onboarding
Information quality	Describe the type of contribution that serves the community’s purpose: what the member should have done before posting, what distinguishes a contribution that adds value from one that extracts it, and what a member can expect from the community in response to a quality contribution. The information quality dimension is written as a description of what a high-quality contribution looks like, not as a list of what is prohibited. Include the bar the operator has set for their own contributions as a calibration anchor: if the operator is willing to share specific, verifiable experience in their posts, the dimension should say so, which sets an expectation for what members can receive and a model for what members are expected to contribute. Include what to do with a question the member has not yet researched — because this is the most common information quality failure mode (asking the community to do research the asker could have done) and providing a positive description of the alternative (share what you already know, name what you’re stuck on) is more effective than prohibiting the behavior.	“The best contributions in this community — the ones that generate the most useful replies and that members reference later — describe a specific situation the contributor is navigating, share what they already know about it, and ask for perspective on the decision they are facing. Before posting a question, spend two minutes with it: what do you already know that’s relevant to the question? What have you already tried? What specific decision does the answer need to help you make? Those two minutes turn a vague question into a specific one, and specific questions get specific answers. Contributions don’t need to be perfect — this is a peer community, not a publication — but they should be specific enough that the people responding can give advice that is actually useful for your situation.”	Do not write: “No spam. No low-effort posts. No asking questions you could answer with a Google search.” The prohibition version names the failure modes but does not help a member understand whether their specific contribution is a low-effort post. “Low-effort” is a judgment the member cannot apply to their own post because they are not aware their effort level is below the community standard. The prohibition version also fails to describe what high effort looks like, so a member who wants to comply does not know how. The prohibition list is also asymmetric in its coverage: it tells members what not to do but does not tell them what to do, which means compliant members avoid the prohibited behaviors but produce contributions that are merely not-prohibited rather than genuinely valuable. Avoid “questions must be relevant to [topic]” without defining what relevant means in practice — the definition is the hard part and prohibition language consistently fails to provide it.	Day 0 welcome DM: the information quality dimension should appear in the day-0 welcome DM as the calibration for the first post the member will make in their introduction. Frame it as “here’s what other members find most useful in introductions” rather than as a rule. Day 7 operator scorecard: re-surface the information quality standard when the operator reviews first-week contributions as part of the activation check — a member who has been posting but posting below the quality standard benefits from seeing the dimension framed as “here’s where to aim next” rather than as a correction. First contribution to a peer-advice channel: if the community uses channel-specific pinned resources, the information quality dimension for the peer-advice channel should be pinned so members see it before their first contribution in that channel. Do not put the full standards document behind a link that most members will not follow; the relevant dimensions should be surfaced at the moments they apply.
Interpersonal norms	Describe how members treat each other’s time, expertise, and context. The interpersonal norms dimension covers three specific behaviors that are most common in paid community conflicts: how to give feedback (specifically, that feedback should address the decision not the person and should be invited rather than unsolicited), how to receive feedback (that responding to criticism of one’s idea by defending the idea at length produces a different thread dynamic than asking a clarifying question), and how to treat another member’s shared context (that a member who shares a work situation in a community thread is entrusting that context to the community and expects it not to be referenced in other contexts without permission). The norms should describe the specific behavior the operator has observed produces the best conversations in this community, not a generic version of “be respectful”; specific norms are more actionable than general ones because a member can evaluate their own behavior against a specific description.	“The conversations that generate the most value here are ones where people genuinely want to understand before responding. That looks like: reading the whole thread before replying, so you’re not repeating advice already given; asking a clarifying question if you’re not sure you understand the situation; and giving feedback on the decision-options rather than on the person who is deciding. When someone shares a situation from their work, they’re trusting the community with context that isn’t public — it stays in the community. When someone shares a minority perspective, the response that is most useful is engaging with their reasoning, not their conclusion. Disagreement here is fine; it’s one of the reasons peer community is more valuable than content. The standard we try to hold is: if you are going to push back on someone, push back on the argument, not on the person making it.”	Do not write: “Be respectful of other members. No personal attacks. Assume positive intent.” “Be respectful” is not actionable because it does not define what respectful looks like in this specific community context: in a high-directness professional community, respectful disagreement sounds different from a high-collegiality social community. “No personal attacks” covers the most extreme end of the interpersonal norms failure mode but does not address the more common forms of interpersonal friction: dismissiveness, unsolicited feedback, public reference to private context. “Assume positive intent” is a norm that benefits the behavior-producer (the member who might be acting dismissively gets the benefit of the doubt) rather than the member who is experiencing the impact; the interpersonal norms dimension should describe behavior rather than charitable interpretation, because the community’s standard for behavior is the operator’s responsibility to define and the member’s responsibility to meet, not a matter of interpretation. Avoid norms that are vague enough that a member cannot evaluate their own behavior against them.	Day 3 nudge: for members who have not yet posted, the day-3 nudge that surfaces an interpersonal norm (“a lot of members find it easier to start with a reply to an existing thread rather than a new post”) addresses the interpersonal anxiety that often prevents first-week posting without framing the non-posting as a failure. Introduction thread: the interpersonal norms dimension surfaces naturally in the introduction thread context — how members respond to introductions is one of the most visible interpersonal norm signals in the first week, and the operator’s response to the first few introductions sets the model. New-member buddy or onboarding contact: if the community assigns a guide or ambassador to new members, the interpersonal norms dimension should be part of what the guide explains, framed as “here’s how the conversation style works here” rather than as a rule list. Post-conflict: when a member-versus-member conflict is resolved, the relevant interpersonal norm(s) should be re-surfaced in the resolution DM as a positive description of what the alternative behavior looks like, not as a correction.
Scope	Describe what topics, problems, and discussion types belong in this community, expressed as what the community is focused on rather than as a prohibition list of what does not belong. The scope dimension is the most operationally important for new members who are deciding whether a particular post idea fits the community: a scope statement that describes the community’s focus in positive terms gives the member a framework to self-evaluate their post before writing it; a prohibition list gives the member a list of things not to do but no framework for evaluating whether their specific idea fits. The scope description should be specific enough to serve as a self-evaluation tool: a member should be able to read the scope statement and answer “does my post idea fit?” without needing to ask the operator. Where the community has sub-scopes (specific channels for specific topics), the channel-level scope description is more useful than the community-level scope description for the post-evaluation question; both should exist and should be consistent.	“This community is focused on the operational and strategic problems that come up when you run a paid Slack community in the 200–2,000-member range: onboarding, activation, retention, pricing, content strategy, member conflict, and team structure. The closest proxy for whether a topic fits is: does this operator (running a paid Slack community) face this question in their work? If yes, it belongs here. Adjacent topics — community-building theory, platform comparisons, marketing strategy for other business types, content creation for audiences rather than communities — may be interesting and sometimes connected, but they belong in other contexts. If you’re not sure whether your topic fits, a short framing sentence at the start of your post that anchors it to the operational context (“Running a community at 400 members and facing this question about…”) will usually clarify whether it fits and will make the context immediately clear to members who can help.”	Do not write: “No off-topic posts. Stay on topic. This is not a place for general marketing discussion.” The prohibition version tells a member what is not allowed but does not help them evaluate whether their specific post idea is on-topic or off-topic, which is the evaluation they need to make before writing the post. “Stay on topic” is a circular statement: it defines on-topic as on-topic without providing any description of what on-topic means in this specific community. The prohibition list version is especially unhelpful for new members who do not yet have enough community experience to know where the topic boundary is; an experienced member can infer the scope from the content they’ve seen, but a new member cannot. Avoid defining scope solely by reference to prohibited platforms, competing communities, or audience types; describe the scope in terms of the operator’s own focus rather than in terms of what is excluded.	Day 0 welcome DM: the scope dimension should appear in the day-0 DM as the frame for the member’s first contribution — specifically, what the community is focused on and where to find the most relevant channels for their stated goal. Channel header and description: the most relevant place for channel-level scope is the channel header and description, which members see when they join the channel; these should be specific enough to answer “does my post belong here?” Channel pin: a pinned post in each channel that gives two or three examples of recent threads that fit the channel’s scope is more actionable than a scope description alone, because members calibrate to examples more reliably than to descriptions. Onboarding canvas or resource: if the community uses a Canvas or pinned onboarding resource, the scope dimension should be included in the “how to post effectively here” section with the positive description and a self-evaluation question the member can apply before posting.
Operator role	Describe what the operator is responsible for maintaining and what members can expect when something falls below the community’s standard. This dimension is the most commonly omitted from paid community standards documents, and its absence produces two failure modes: members who do not know whether the operator monitors and enforces standards (and who therefore do not know whether to expect a response when they observe a below-standard contribution), and members who have experienced a below-standard incident who do not know how to report it or what will happen when they do. The operator role dimension creates accountability in both directions: the operator commits to what they will do, and the member understands what to expect. The operator role description should be specific about three things: how standards are monitored (proactively or reactively), what happens when a standard is not met (the two-stage private process), and what a member should do if they observe something that falls below standard (contact the operator directly via DM, not in a public thread).	“My job is to maintain the environment that makes this community worth paying for. That means monitoring contributions for quality and fit, addressing situations where the standards aren’t being met, and making sure new members get a response to their first post within 24 hours. When something falls below the standard, I handle it privately with the member involved — you won’t see me call someone out in a thread or post a public warning. If you see something that doesn’t feel right and you’re not sure whether it’s something to flag, DM me directly and I’ll take a look. There’s no threshold you need to clear for reaching out — if it felt off to you, that’s enough. I review active channels at least three times per week and typically respond to DMs within four hours during working hours.”	Do not write: “We reserve the right to remove members who violate community guidelines.” This is a legal disclaimer, not a description of the operator’s role. It tells members that removal is possible but does not describe the process, the monitoring approach, the response time, or how to report an issue. A member who experiences a below-standard interaction and reads only this statement will not know whether to report it, how to report it, whether anything will happen, or what the operator’s standard is for action. Do not overcommit to response times or monitoring frequencies that the operator cannot sustain; the operator role description creates a member expectation, and failing to meet a committed response time damages trust more than a more modest commitment that is consistently met. Do not use passive voice (“issues will be addressed”) for the operator role; it obscures who is responsible and what the process is.	Day 0 welcome DM: the operator role dimension should appear in the day-0 DM as the closing section, after the introduction to the community and the first-step guidance. Frame it as “here’s how I work and how to reach me” rather than as a terms disclosure. This context is most useful to the new member at the moment they are forming their expectation about the community. Post-incident follow-up: the operator role dimension is most credibly demonstrated through the post-incident follow-up DM to the affected member that confirms what was done — the member’s experience of the operator role description is the most powerful reinforcement of the dimension. Annual review message: a once-per-year community-facing message that reviews what the operator did during the year to maintain the standards (how many stage-one DMs, what the moderation load looked like, what was changed in the standards document and why) demonstrates the operator role commitment at a community-wide level and produces a strong signal of accountability that is visible to all members simultaneously.

The four dimensions compound across the member lifecycle: the information quality and scope dimensions are most important in the first week when the member is forming their contribution pattern; the interpersonal norms dimension is most important in weeks two through six when peer interactions become the primary driver of member engagement; the operator role dimension is most important when an incident occurs and the member’s experience of the response either confirms or contradicts what the dimension promised. A standards document that addresses all four dimensions but fails to surface them at the relevant moments produces the same outcome as a document that is only read once at onboarding: the standard is stated but not reinforced at the moment when reinforcement changes behavior. See the member acquisition reference card for how the scope dimension in the standards document affects the conversion of prospective members who encounter it on the landing page versus in the onboarding sequence.

Table 4 — Exit conversation script

Two stages in the exit conversation process: the notification message, which is sent to communicate the removal decision, and the feedback request, which is sent 24–48 hours after the notification to collect data that the operator cannot collect from the incident itself. The exit conversation is a data collection mechanism as much as it is a communication mechanism: the notification message communicates the decision; the feedback request produces information about the conditions that led to the incident, what the member experienced before the incident that the operator did not see, and what the interaction between the member’s expectations and the community’s standards produced over time. This data has three categories of value: policy-clarification data (what the community standards document failed to communicate clearly enough to prevent the incident), context data (the event series leading to the incident that the operator did not observe), and product data (gaps between the community experience the member expected based on the landing page or onboarding and the experience they actually had). Exit conversations produce data that exit surveys from non-renewing members do not produce, because a removed member has a specific incident to discuss rather than a general assessment to give. Not all removed members will respond to the feedback request; a response rate of 30–50% is typical and sufficient to identify patterns across multiple incidents.

Stage	What to include	What to avoid	Example opening	What the data this stage produces
Notification message	Three elements, in this order: (1) the community standard that applied to the incident, stated as a description of the community’s commitment rather than as a prohibition (“we maintain a community where member contributions serve the community’s purpose and where interpersonal interactions meet the standard of the environment members pay for” rather than “you violated our no-self-promotion policy”); (2) the specific behavior that triggered the action, described factually and without evaluation of the member’s intent (“the post in [channel] on [date] that promoted [business/service] without disclosing the affiliate relationship” rather than “your intentional deception of other members”); (3) the action taken and whether it is reversible, stated clearly without hedging (“your access to the community workspace has been removed effective today; this decision is not reversible through this conversation”). The notification message should be factual, short (under 150 words), and not invite debate. It does not apologize for the decision; it does not suggest the outcome was uncertain; it does not include language that implies the member was not given prior process (where prior process was given, reference it — “as we discussed in our earlier conversation about [date]”). The notification message’s goal is to give the member a clear, factual account of what happened so they understand the decision and do not contact the operator repeatedly seeking clarification.	Avoid: inviting a response that could reopen the decision (“please let me know if you have any questions” without specifying that the removal decision is not subject to reversal in this exchange); emotional language about how difficult the decision was (which transfers the emotional labor of the situation to the member receiving the notification); referencing other members who observed or reported the behavior (this creates identification risk); or multiple consecutive paragraphs that the member may read as an extended justification that can be argued with point by point. Avoid sending the notification message immediately before a weekend or a multi-day holiday period when the operator will not be available to respond to a follow-up; notification messages that arrive and are not followed by the expected feedback-request message within the stated timeframe produce repeat contact from the member seeking the feedback request. Avoid the passive voice for the removal decision itself: “the decision has been made to remove your access” is weaker and less clear than “I’ve removed your access to the community”.	“I’m writing to let you know that your access to [community name] has been removed as of today. The community maintains a standard for [dimension — information quality / interpersonal conduct / scope] that ensures the experience members pay for. [Specific behavior description] fell outside that standard. I’ll be in touch in the next day or two with a brief follow-up — your perspective on what you experienced in the community before this point is genuinely useful for me to understand.”	The notification message itself produces minimal direct data; its value is procedural — it creates the conditions for the feedback request to receive a response. A removed member who receives a factual, non-punitive notification message without accusatory language is more likely to respond to the feedback request than a member who received a notification message that read as an indictment. The data the notification message indirectly produces: member response pattern to the notification (constructive, argumentative, no response, or request for reversal) is a data point about whether the incident classification was correct. A member who responds with a constructive acknowledgment was likely correctly classified; a member who responds with a detailed rebuttal may have been misclassified or may have had a genuine expectation gap that produced the incident. Document the response pattern as part of the incident record.
Feedback request (24–48 hours after notification)	Three questions, sent as a single block in the same DM thread as the notification message: (1) “Is there anything about the community’s standards — what was expected or how I described what the community is for — that wasn’t clear when you joined or as you were participating?” (policy-clarification data); (2) “Was there anything that happened in the community before the incident we discussed that you felt should have been addressed and wasn’t?” (context data: the operator gets the member’s view of the event sequence, including events the operator did not observe); (3) “Is there anything about the difference between what you expected when you joined and what you actually experienced that would be useful for me to know?” (product data: the gap between landing-page or onboarding promises and actual experience). Frame the preamble as a genuine request for the member’s honest perspective: “The removal decision is final, so I’m not asking because it will change the outcome — I’m asking because understanding your experience before this point is genuinely useful to me, and I think you have perspective that would help.” The framing that the removal decision is final before asking for feedback reduces the frequency of feedback-request responses that focus on contesting the removal rather than answering the questions.	Avoid: sending the feedback request immediately after the notification message (the 24–48 hour gap gives the member time to process the notification before the feedback request arrives; receiving both in the same session produces defensive responses to the feedback questions rather than reflective ones); sending the feedback request with a tone that implies the member owes the operator an explanation (the request should position the operator as the party who may have failed to communicate clearly enough, not as the party who is investigating the member’s behavior); including questions about the specific incident behavior in the feedback request (the feedback request is about the member’s broader experience before the incident, not about the incident itself; asking the member to re-explain the incident behavior produces defensive justification, not useful data). Avoid sending the feedback request to every removed member in every incident type: members removed for bypass-level severe incidents should not receive a feedback request, because the behavior that triggered the bypass classification is not the kind of situation where the operator is asking whether the community standards were unclear. Reserve the feedback request for the three lower incident types where the incident may have had a preventable origin in expectation gaps or unaddressed prior situations.	“As I mentioned in my earlier message, I’m reaching out for a short follow-up. The decision about your community access isn’t going to change — I want to be clear about that before asking. But your perspective on what you experienced in the community before this point is genuinely useful for me to understand, and I don’t have another way to get it. If you’re willing to share [three questions listed here], I would find it helpful. No pressure to respond — I understand if you’d rather not.”	Three categories of data: (1) Policy-clarification data: answers to Question 1 reveal gaps between the community standards document’s description of expectations and what a member understood those expectations to be. A member who says “I didn’t know that promotional links had to be disclosed; I thought any resource recommendation was in scope” indicates a gap in the information quality or scope dimension of the standards document. This is actionable: update the dimension’s description to close the gap. (2) Context data: answers to Question 2 reveal incidents the operator did not observe that the member experienced as unaddressed — situations where another member’s behavior toward the removed member was below standard but was not caught by the proactive monitoring process. This data produces an incident-review audit: were there situations involving this member that the escalation matrix should have caught but did not? (3) Product data: answers to Question 3 reveal gaps between the landing page’s or onboarding sequence’s description of the community and the member’s actual experience. A member who expected a more beginner-friendly community than they found, or who expected more direct access to the operator than they got, identifies a positioning gap that may be producing similar exits from members who did not reach a removal incident but cancelled for the same reason. Track response patterns across multiple feedback requests to identify the data category that appears most frequently — that category identifies the highest-leverage improvement in the standards document, the monitoring process, or the landing page, respectively.

The exit conversation data compounds with the cancellation flow data from non-renewing members: together they produce a complete picture of the conditions that produce exits from both ends of the severity spectrum (the removed member and the quietly-cancelling dissatisfied member). The removed member exit conversation data identifies policy gaps and monitoring failures; the cancellation flow data identifies the experience gaps that produce dissatisfaction without incident. The operators who review both data sets together identify the pattern that neither data set reveals alone: the experience dimension where the community consistently fails to deliver on its promise to members, which produces exits from members at all positions on the involvement spectrum. See the cancellation flow post for the full exit-survey process that produces the dissatisfied-member data.

Table 5 — Moderation load benchmarks

Four metrics that quantify the moderation work in a paid community, each with a healthy range, a warning signal that indicates a change in the underlying community culture or composition, a diagnosis of what the metric is actually measuring (which is not always what it appears to measure), and the highest-leverage intervention for bringing an out-of-range metric back within the healthy range. The moderation load benchmarks are most useful as trend data rather than as absolute standards: a community that is consistently at the high end of the healthy range for stage-one incidents is in a different situation from one that has recently crossed from healthy into warning range, even if the absolute metric value is similar. Track these four metrics monthly and review the trend before applying the intervention — the intervention for a metric that has been in warning range for three consecutive months and is trending further out-of-range is different from the intervention for a metric that crossed into warning range once and returned to healthy range in the following month. The rates are expressed per 100 active members per month, where active members are defined as members who have contributed at least once in the previous 30 days, not total enrolled members — because a moderation rate calculated against total enrolled members (including silent subscribers and inactive members) understates the true incident rate in the active member population that is actually generating the moderation work.

Metric	Healthy range	Warning signal	What it diagnoses	Intervention
Stage-one incidents per 100 active members per month	0.5–2.0. Below 0.5 is not necessarily healthy; it may indicate the proactive monitoring process is not catching incidents that exist (undercounting), that the community is below the size where the incident types listed in Table 1 appear at a visible rate (communities under 150 active members often produce rates below 0.5 without infrastructure failure), or that member participation is concentrated in a subset of very high-quality contributors who do not generate stage-one incidents. Above 2.0 per 100 active members per month consistently signals a standards-level problem, not a monitoring problem: if the monitoring is working correctly and incidents are being caught and addressed at stage one, a rate above 2.0 means the community is producing more below-standard contributions than the standards document and onboarding sequence are preventing.	A consistent upward trend over three consecutive months, not a single high month. A single high month may reflect a cohort intake that included members whose use cases were misaligned with the community (a one-time composition change that the onboarding sequence corrects over time). Three consecutive months of upward trend is a culture signal: the community’s informal norms are shifting, and the shift is not correcting itself through the existing monitoring-and-DM process. Also watch for a sudden drop to near-zero after a period of healthy activity: this can indicate that members have stopped posting in contexts where incidents typically occur (suppressed participation from the structural toxicity scenario) rather than that the community standards are being met more reliably.	The stage-one incident rate primarily diagnoses the information quality and scope dimensions of the community standards document. A high stage-one rate reflects that members are regularly producing contributions that fall outside the standards without self-correcting before posting: they are not using the standards as a self-evaluation filter. The most common cause is that the standards description is too abstract to use as a pre-posting checklist: a member who reads “contributions should be relevant and high quality” cannot evaluate whether their specific post idea meets that standard. A secondary cause is a mismatch between the community’s published membership criteria (the ICP description on the landing page) and the actual membership composition: if the ICP description is broader than the community’s actual design, the community will consistently attract members whose use cases do not fit, and stage-one incidents will reflect the expectation gap rather than a behavior problem.	For a rate in the 2.0–3.5 range: revise the information quality and scope dimensions of the standards document using the language from the most recent batch of stage-one DMs — the actual phrasing of the DMs reveals which standard is being violated most often, and that standard needs a more specific description. For a rate above 3.5 consistently: combine the standards revision with a landing-page or onboarding audit to identify whether the ICP description is attracting members whose use case does not fit the community design. For a rate trending upward from a previously healthy baseline: apply the structural toxicity scenario process from Table 2, because an upward trend from a healthy baseline suggests the community culture is shifting in a direction that is producing more below-standard contributions from existing members who were previously within standard — a content quality problem rather than a membership composition problem.
Conflict incidents per 100 active members per month	0.1–0.5. A conflict incident is defined as a member-versus-member situation that required the separate-understand-resolve process from Table 2 — not every interpersonal tension, but situations where the operator identified a dynamic between two specific members that required direct operator involvement with both members. Below 0.1 at any community size is a possible undercounting signal: member-versus-member tension that the operator has not observed but that is affecting participation (member pairs who have stopped interacting after an unaddressed incident, channels where one member’s presence is consistently correlated with lower participation by another) exists in most active communities and will not appear in the conflict metric if the only counting trigger is a direct member report. Above 0.5 per 100 active members per month consistently indicates a culture-level problem that is producing conflict at a rate higher than normal interpersonal variation can explain.	A sudden spike to above 1.0 in a single month without a corresponding change in community size or cohort intake. A sudden spike typically reflects a structural trigger: a live session where a conflict dynamic became visible, a thread that attracted concentrated engagement from two members who produced a visible dynamic, or a community event that brought a conflict pair into interaction after a period of avoidance. A sustained rate of 0.5–1.0 over multiple months without a visible single event is the more concerning pattern: it indicates the community has developed a background level of interpersonal tension that is producing incidents without a specific trigger, which is the pattern most predictive of structural toxicity rather than individual conflict dynamics. Check whether the conflict incidents cluster around the same two or three members (individual conflict dynamics) or are distributed across different member pairs (structural culture problem).	The conflict incident rate primarily diagnoses the interpersonal norms dimension of the community standards document and the quality of the first-week experience for new members. A high conflict rate with incidents distributed across different member pairs indicates the community has a norms gap: the interpersonal norms dimension is not specific enough or is not being surfaced at the moments that would prevent the conflict patterns. A high conflict rate concentrated in the same member pairs indicates individual dynamics that should have been addressed earlier in the separate-understand-resolve process; if the same two members appear in multiple conflict incidents, the question is whether the operator addressed the dynamic after the first incident or treated each incident as independent. A high conflict rate concentrated in specific channels or content types (for example, consistently higher in the peer-advice channel than in other channels) indicates a channel-level norms problem rather than a community-wide culture problem.	For a distributed conflict rate above 0.5: apply the structural toxicity process from Table 2 in parallel with a revision of the interpersonal norms dimension — the conflict incidents are symptom data for a norms gap that the standards document is not closing. For a concentrated conflict rate (same two or three members across multiple incidents): the separate-understand-resolve process should have been applied after the first incident involving each pair; for ongoing pairs, initiate the process immediately and address the pattern explicitly in the private conversations (“this is the third situation involving the two of you; I want to understand the dynamic rather than address each incident separately”). For a channel-concentrated conflict rate: revise the channel-level interpersonal norms description (header, pinned message, or channel canvas) to address the specific norms that are generating the conflict pattern in that context — the channel-level revision reaches the members who are active in that channel at the moment they are most likely to see it.
Stage-two escalation rate (% of stage-one incidents that escalate)	10–25%. This means that 75–90% of stage-one DMs produce a constructive resolution without requiring a stage-two action. Below 10% is not necessarily a positive signal; it may indicate that the operator is sending stage-one DMs to borderline situations that were more accurately borderline-escalation rather than borderline-DM situations, and that the members are responding constructively to DMs that should have escalated to a stage-two action on the behavior that triggered the DM (the behavior stops not because of a genuine behavioral change but because the DM created enough uncertainty about consequences). Above 25% indicates a stage-one DM quality problem: the DMs are not producing constructive resolution in enough cases, which means they are either being sent too late (after the behavior has already escalated to the level that makes a DM response less likely), are not specific enough about the behavior and the standard, or are not clear about the consequence of non-response.	A rate consistently above 30% over three consecutive months. A rate above 30% should trigger a DM quality audit: review the last 10 stage-one DMs that were sent and evaluate whether each was specific about the behavior, clear about the applicable standard, and explicit about the consequence of non-response. A rate above 30% often traces to one of three DM quality failures: DMs that describe the behavior in general terms rather than by reference to a specific incident (making it possible for the member to claim they do not know what the DM is referring to); DMs that describe the community standard in abstract terms rather than by reference to the specific applicable dimension; or DMs that end without stating a consequence, making the DM read as a notification rather than as a decision point that requires member response.	The stage-two escalation rate diagnoses the quality and timing of the stage-one DM process. A high escalation rate is primarily a DM-process problem: the stage-one DMs are not producing the behavioral change they should produce, which means either they are not being sent promptly enough (the behavior escalates between the incident and the DM, making the DM arrive after the member has already moved to stage-two-warranted behavior), are not specific enough to produce the recognition response that drives behavioral change, or are not creating a clear enough accountability moment. A secondary cause of high escalation rates is incident misclassification: treating what should be a clear-violation incident (which escalates more often because the member has already violated a clear standard and the DM is less likely to produce self-correction) as a borderline incident and sending a softer DM inflates the escalation rate for the borderline category.	For an escalation rate consistently above 25%: audit the three DM quality variables (specificity of behavior description, specificity of standard reference, explicitness of consequence statement) and revise the stage-one DM template to address the missing elements. For an escalation rate above 30% with no DM quality failure identified: check the timing — if the median time between the incident and the DM is more than 48 hours, the DM is arriving after the behavior has already progressed. Tighten the monitoring frequency so DMs are sent within 24 hours of the incident that triggers them. For an escalation rate concentrated in a specific incident type (for example, high escalation for clear-violation incidents but healthy escalation for borderline incidents): the clear-violation DM framing is the problem; clear-violation DMs should be more direct and shorter than borderline DMs, not identical in tone and length.
Removal rate per 100 active members per month	0.05–0.3. In a community of 500 active members, this is 0.25–1.5 removals per month on average. Below 0.05 in a community that is actively monitoring and applying the escalation matrix is consistent with a healthy standard-maintenance culture. Below 0.05 in a community that is not actively monitoring likely indicates under-enforcement: the stage-one incidents exist but are not being addressed, so they do not escalate to stage-two and removal is not triggered. Above 0.3 consistently indicates either a membership composition problem (the community is consistently attracting members whose behavior does not fit the standards) or a standards enforcement problem (the standards are being enforced too strictly relative to their actual description, removing members for behavior that a member reading the standards document would not expect to be a removal-level violation).	A rising trend from near-zero to above 0.3 over a 3–4 month period is the primary warning signal. A sudden spike to above 0.5 in a single month may reflect a single cohort intake that included a cluster of members whose behavior did not fit the community standards; this is a one-time event that should not recur in subsequent months if the intake and onboarding process has not changed. A sustained upward trend from a previously healthy baseline is more concerning: it indicates that the membership composition is shifting in a direction that the onboarding sequence is not correcting, or that the standards are being applied more strictly than they were previously. Check whether the removal rate change correlates with a change in acquisition channel (a new channel may be attracting a different member profile) or with a change in the onboarding sequence (a change to the day-0 DM or the standards document may have altered member expectations in a way that produces more early behavior misalignment).	The removal rate diagnoses the alignment between the community’s membership composition and the community’s standards. A high removal rate primarily reflects a composition problem: the community is consistently attracting members whose behavior does not fit the standards, which means the ICP description on the landing page or the referral source is producing a member population whose expectations or behavior norms differ from the community’s design. A secondary diagnosis: if the removal rate is high but the stage-two escalation rate is healthy (meaning the high removal rate is not being driven by a high rate of DMs-that-don’t-work), the removals are mostly coming from bypass-level incidents or from repeat-stage-one cases where the process worked correctly and removal was the appropriate outcome. In this case, the removal rate is a correct enforcement signal, not a problem to reduce; the intervention is to understand why the community is attracting members who produce bypass-level or repeat-stage-one incidents.	For a removal rate above 0.3 driven by composition: audit the acquisition channels and ICP description to identify whether a specific channel or message is producing member profiles whose behavior does not fit the standards. Revise the ICP description to be more specific about what the community requires of members in their participation style, not just their professional context. For a removal rate above 0.3 driven by standards calibration (the standards are being applied more strictly than the description warrants): review the standards document against the last 5–10 removal decisions and identify whether the documented reason for each removal aligns with a specific standard dimension. If multiple removals cite vague standard descriptions (“contribution quality” without a specific failure), revise the dimension to be more specific so that the enforcement standard matches the documented standard. For a removal rate trending up from a healthy baseline: apply the feedback request process from Table 4 to the most recent removals and analyze the policy-clarification data for patterns that indicate a standards document gap.

The four metrics should be read together as a system rather than independently. A healthy stage-one rate with a high escalation rate indicates a DM-process problem, not a culture problem. A healthy escalation rate with a high removal rate indicates a composition problem, not an enforcement problem. A healthy removal rate with a rising conflict rate indicates an interpersonal norms gap that the stage-one process is not catching because conflict incidents often do not trigger stage-one classification until they have produced a visible dynamic. The combination of healthy-stage-one, healthy-escalation, healthy-removal, and rising-conflict is the warning pattern most predictive of first-week activation rate decline in the next cohort, because the rising conflict rate signals a culture shift that new members encounter before the monitoring process detects it. See the Onboarding Health Check for the diagnostic tool that identifies which activation and retention gaps are the highest-leverage moderation priority based on five operator questions.

Related reference cards

Companion post: Paid community moderation playbook: from reactive to proactive — the conceptual framework behind these tables: why the cost of a false negative exceeds the cost of a false positive in paid community moderation, the inverted cost calculation, and why private-first escalation produces more accurate outcomes than public or simultaneous approaches.
Cancellation flow — the exit survey process for non-renewing members that complements the removal exit conversation data, and how the two data sets together identify the experience gaps driving exits from both ends of the severity spectrum.
Member acquisition — how the ICP description in the standards document affects the conversion of prospective members and the composition of the member base that the moderation load benchmarks will reflect.
Testimonial strategy reference card — how exit data from removed members and non-renewing members informs the failure-prevention testimonial format and the FAQ-embedded placement that addresses risk objections on the landing page.
2-minute Onboarding Health Check — five questions, a 0–50 score, and the three highest-leverage fixes for your activation and retention number, including which moderation scenario type is most likely affecting your first-week post rate.