How to write community rules that members actually follow
The real job of community rules is not to prevent violations. If you believe the purpose of a rules document is to stop members from doing things they were going to do anyway, you will write rules that do not work — either because you write too few of them and members discover the standard only when they have already crossed it, or because you write them in the language of a legal document that no one reads and that provides no guidance for the member who is trying to figure out whether the post they are drafting is acceptable.
The real job of community rules is to give members the information they need to self-moderate before they violate. Self-moderation before violation is the only moderation intervention that costs the operator nothing. A member who checks their post against a clear, specific rule and revises it costs the operator zero time. A member who posts something that violates an unwritten standard, receives a private message from the operator, and adjusts costs the operator ten minutes. A member who posts the same thing after the private message, receives a second message, and then requires a temporary posting restriction costs the operator forty minutes across three interactions — plus the attention it draws from other members who notice the pattern and draw their own conclusions. Rules that enable self-moderation before posting eliminate the first violation entirely and make the subsequent steps in the dispute resolution ladder mostly unnecessary for the behaviours the rules cover.
Most paid community operators fall into one of two failure modes. The first is having no written rules at all. The community operates on informal norms that the operator enforces inconsistently through private messages and judgment calls that no member can predict. The second is having rules that read like a terms of service — a formal document full of legal qualifications and abstract principles that covers the operator against hypothetical disputes but gives members no concrete guidance about how to post or interact. Both failure modes produce the same outcome: members who cannot self-moderate because they do not know the standard clearly enough to apply it themselves.
This guide covers what separates rules that work from rules that do not, the five properties every enforceable rule needs, the three specific rules most paid communities need immediately, how to introduce rules into a community that does not have them, and what to do when a situation arises that your rules do not cover. The paid community moderation reference card has the structured tables that operationalise each framework covered here; the paid community moderation guide covers the three-tier norm framework and the four-step dispute resolution ladder that your rules plug into.
1. What rules actually do
The distinction between rules that reduce moderation load and rules that do not comes down to a single question: can a member check their own behaviour against this rule before they act? If yes, the rule enables self-moderation. If no, the rule is only useful after a violation has already occurred — at which point it is a justification for an intervention rather than a prevention of one.
Self-moderation before posting works because most members in paid communities are not looking to push the limits. They are trying to contribute in ways the community values, and they are uncertain, especially early in their membership, about where exactly the acceptable boundaries are. A new member considering their first promotional mention of a product they have built is not, in most cases, a member who is trying to spam the community. They are a member who does not know whether what they are about to do is acceptable. A rule they can check before posting answers that question before the post goes live. The intervention the operator would otherwise need to make — and all the downstream discomfort it creates for the member, the operator, and the community observers — simply does not happen.
The second function of rules is reducing the subjectivity of enforcement decisions when they do become necessary. When a private message to a member is necessary because they have crossed a line, a rule that clearly covers the situation makes the private message straightforward: the operator names the specific behaviour, points to the specific rule, and explains what they would like to see instead. The member who receives this message may disagree with the decision, but they cannot disagree with the existence of the standard — it was written down and available before they violated it. Without a written rule, the operator’s private message is an expression of subjective judgment: “this felt promotional to me.” The member who disagrees now has a legitimate basis for the disagreement. Rules convert enforcement conversations from disputes about the operator’s judgment into references to a documented standard, which ends most disputes before they begin.
The third function — and the one most operators underestimate — is the signal that well-written rules send about the community itself. Members who read a short, specific, clearly-written rules document learn something about the operator: this person has thought carefully about how the community should work, cares enough to write it down, and is treating the members as adults who can be given the standard and trusted to apply it. That inference is accurate, and it changes how members engage with the community from the first day. A community with no rules communicates that the operator is either indifferent to how members treat each other or has not thought carefully enough to document the standards they care about. A community with a terms-of-service-style rules document communicates that the operator is primarily thinking about liability rather than the member experience. Neither signal produces the trust that drives contribution and retention.
2. Why most paid community rules fail
The two failure modes that produce rules that do not work follow a predictable structure.
Failure mode one: no written rules. The operator has strong norms — a clear internal sense of what is acceptable and what is not — but has not written them down. Enforcement happens through private messages when something surfaces that the operator notices, and through silence (which members read as approval) when it does not. This works adequately in the very early stages of a paid community when there are twenty members and the operator knows each of them personally. It stops working as the community grows past fifty members and the operator can no longer maintain personal knowledge of every member’s posting history and context.
The specific failure in communities with no written rules is that enforcement becomes relationship-based rather than standard-based. The operator applies the norm to the members they are paying attention to in the moment. Long-tenured members who have become part of the operator’s informal circle receive different treatment than new members for the same behaviour — not because the operator is trying to be unfair, but because the decision process for a familiar member goes through a different filter than the decision process for a new one. Every member who observes both situations draws the same conclusion: the standard is not the stated norm; the standard is the operator’s relationship with you. That conclusion, once formed, is extremely difficult to reverse and substantially reduces the community’s ability to grow through referrals, because members who believe access is relationship-mediated do not refer freely.
Failure mode two: legalese rules. The operator has written rules, but they are formatted as terms of service. They include clauses like “members who engage in behaviour that the operator deems inconsistent with the community’s values may have their membership suspended or terminated at the operator’s sole discretion.” They cover hypothetical edge cases at length. They use “prohibited content” as a section heading. They describe orientations (“treat others with dignity and respect”) rather than actions (“do not send unsolicited DMs about your paid products without visible consent in a public thread”).
The legalese failure mode is especially common in operators who have a background in corporate environments and who are, reasonably, trying to protect themselves from the membership disputes that can turn into public reputation problems. The motivation is understandable. But the result is a rules document optimised for a dispute that has already occurred, not for the self-moderation that prevents disputes from occurring in the first place. Members who read a terms-of-service-style rules document learn that they are in an environment where the operator is primarily thinking about their own protection, not about giving members clear guidance. And most members do not read it at all — which means the self-moderation function the document was nominally serving is simply absent.
The diagnostic for which failure mode a community is in: ask yourself whether a new member who read your rules document before their first post would know what to do differently as a result. If the answer is no — because there are no written rules, or because the written rules are too abstract to produce a concrete behaviour change — the document is not doing the work that rules are supposed to do.
3. The five properties of enforceable rules
Every rule in a paid community rules document should have five properties. Not every rule will score perfectly on every property, but a rule that fails on more than one of these is unlikely to enable self-moderation and unlikely to be usable in an enforcement conversation.
Specific. The rule names a concrete action, not a value. “Do not send unsolicited direct messages about your paid products, services, or business to other members without first receiving their visible consent in a public thread” is specific. “Be respectful of others’ time and attention” is not. The test: can a member who read this rule and is drafting a post determine whether their planned action violates it? If the answer depends on interpretation of a word like “respectful,” the rule is not specific enough.
Behavioural. The rule describes something observable. “Do not follow up a cold promotional mention in a public thread with a direct message to members who did not respond or engage with the mention” describes a sequence of observable actions that the operator can verify and that the member can check their own planned behaviour against. “Don’t be pushy” describes an internal state that can be disagreed about and that provides no guidance for the member trying to figure out whether their planned follow-up is appropriate. Behavioural rules survive enforcement conversations because both parties are referring to observable facts, not competing assessments of a subjective quality.
Consistent. The same rule applies to all members regardless of tenure, contribution history, reputation within the community, or their relationship with the operator. Consistency is less a property of the rule’s wording than a property of how it is applied, but the wording should make consistent application possible: if the rule has carve-outs that can be interpreted to exclude familiar members, it will be applied inconsistently regardless of the operator’s intentions. The founding member who has contributed substantially to the community and who posts a promotional mention below the contribution threshold is not exempt from the value-before-promotion rule because of their history. Inconsistency applied even once to a visible member is observed by the entire community, and the conclusion members draw — that the standard is relationship-mediated — is more durable than any subsequent enforcement action aimed at demonstrating that the rule does apply to everyone.
Graduated. The rule specifies what happens on first occurrence, second occurrence, and escalation. “Unsolicited promotional DMs will result in immediate removal” is not graduated and is not credible — operators who write this rarely apply it on first offence, and members who observe the gap between the stated consequence and the actual consequence learn that the rules are not to be taken literally. A graduated consequence structure (“first occurrence: private message documenting the standard; second occurrence: seven-day posting restriction in #resources and #general; third occurrence: membership review”) is credible because each step is proportionate and documented. Graduated rules also protect the operator from the reputation damage that comes from first-offence removal of a member in a paid community: because paid community membership involves financial access, members and outside observers who hear about an ungraduated removal conclude that it was arbitrary, regardless of whether the behaviour that prompted it was genuinely severe.
Operator-modelled. The operator’s own visible behaviour in the community demonstrates the norm before it is required of members. This is not a property of the rule’s wording; it is a property of how the operator shows up. When the operator DMs before correcting anyone publicly, posts with explicit context about why they are sharing something, and gives specific feedback that references a concrete action rather than a general impression, members learn the community’s standards through imitation — which is a more durable and self-sustaining learning mechanism than any written document. The operator who has a feedback-solicitation rule but visibly offers unsolicited critique in public threads has created a norm through behaviour that contradicts the rule. Members will follow what they observe the operator do, not what the rules document says.
4. The three rules most paid communities need now
Most paid community rule sets contain more rules than are actually enforced, and fewer rules than the community actually needs. The overlap between “rules we enforce” and “rules that correspond to situations we have encountered” is typically small. The following three rules cover the situations most likely to require operator intervention in a paid community at the 100–2,000 member range, and are most likely to be missing from or inadequately specified in existing rules documents.
Value-before-promotion with a specific count. The rule is: members must make a minimum number of non-promotional contributions visible to the community before any mention of external paid work, products, or services. The specific count is three. Not two, not “several,” not “a few” — three specific non-promotional contributions that are visible in the community’s public channels and that any member can scroll back and find. Three contributions require a pattern across multiple interactions; one or two can be completed in a single burst of activity that is structurally promotional even if each individual post is not. The rule must define what counts as a non-promotional contribution (a question asked, an answer given, a resource shared without an affiliate link, a response to another member’s post) and what counts as promotion (a link to a paid product, a mention of a service the member sells, an invitation to a paid event, a referral to a member’s newsletter). Communities that find the count produces problems usually discover that their underlying problem is not the number but the absence of the definition: without a definition of what counts, members count differently than the operator does, and the enforcement conversation becomes a dispute about what qualifies as a contribution.
DM-consent with visible consent required. The rule is: direct messages about business, collaboration, services, or paid products require visible consent in a public thread before the member moves the conversation to DM. A member who asks in #general whether anyone wants to discuss a collaboration topic, receives a public reply expressing interest, and then DMs the interested member is operating within the rule. A member who DMs cold — without a public exchange where the receiving member indicated interest — is not. The word “visible” is what makes this rule enforceable: the operator can see whether a public exchange occurred before the DM was sent, because the public exchange is in the community. A rule that requires consent without requiring it to be visible (“get permission before DMing about business”) cannot be enforced because the operator cannot verify whether permission was given in a private conversation.
DM-consent violations are among the most disruptive early-member experiences in paid communities. A new member who receives a cold pitch DM from another member on their first or second day updates their assessment of the community: this is a place where paying members use their access to reach other members directly for commercial purposes. That assessment, formed from a single experience, substantially increases churn risk at month two and three, because the new member is now evaluating whether the community is worth staying in against a background assumption that includes unwanted direct solicitation. The paid community retention strategies guide covers the month-two and month-three churn windows in detail; DM-consent violations in the first two weeks are a measurable predictor of early exit in communities that track new-member churn by cohort.
Feedback-solicitation rule with an explicit answer. The rule specifies one of two positions: unsolicited critique is welcome and expected in this community, or critique requires an explicit invitation from the member who posted. Neither position is inherently better; the correct one depends on the community’s purpose and ICP. A community of product managers who are there to stress-test strategic ideas operates differently than a community of early-stage founders who are there to share wins and find encouragement during difficult periods. What matters is that the position is explicit.
The feedback-solicitation rule is the rule most likely to produce the “I was just trying to help” dispute, in which a member who gave detailed, specific, critical feedback to another member’s post is privately told that unsolicited critique is not the community’s norm, and responds that they were contributing value by being honest. Both the member who posted and the member who critiqued are operating from reasonable assumptions about what the community expects. The dispute is not resolvable with reference to the other rules; it requires a written policy on whether critique must be solicited. Communities that do not have this rule in writing almost always have informal norms that lean one way or the other — and the private messages the operator sends to address unsolicited-critique situations have been consistent enough that the rule already exists in practice. Writing it down costs nothing and eliminates the dispute entirely for members who read the rules before their first critique post.
5. Introducing rules into an existing community
Most paid community operators who decide to write a rules document are doing so in a community that already has members and already has norms — they are formalising a standard that has been informally enforced, not introducing an entirely new one. This distinction matters for how the introduction is framed, because members who have been in the community for some time have their own understanding of what is acceptable, and a rules document that arrives without framing can be read as either a warning (something has gone wrong) or a power assertion (the operator is tightening control).
The frame that works is codification, not restriction. The announcement language: “We’ve formalised the standards the community has always operated by. These are not new rules — they are the standards you’ve seen enforced informally, now written down so every new member starts with the same understanding.” This frame is accurate in most cases. The value-before-promotion rule, the DM-consent rule, and the feedback-solicitation rule that the operator is writing down are almost always rules the operator has been informally applying for months. Writing them down is not a change in policy; it is a change in where the policy lives.
The timing of the introduction matters as much as the framing. Rules introduced immediately after a public moderation event get associated with that event. Members who witnessed the event read the new rules through the lens of what just happened and interpret them as a response to the specific member or situation involved, even when the rules were drafted weeks before the event and would have been introduced anyway. The rules that arrive two weeks after an incident, with no explicit connection drawn to the incident, carry none of that association. They arrive as standing policy, not as a reaction. If your community is currently experiencing a moderation situation that needs a rules document to resolve cleanly, draft the document, handle the current situation by communicating directly with the member involved, and then introduce the document as planned policy when the current situation has been resolved.
For the announcement itself: a brief post in #announcements works better than a lengthy explanation. State that you are formalising the community’s standards, link to where the rules are posted (#start-here pinned post, or a dedicated channel), invite questions in a replies thread, and leave it there. The paid community onboarding checklist covers what belongs in the #start-here channel and in the Day 0 onboarding DM; the rules document belongs pinned in #start-here and referenced (not reproduced) in the Day 0 DM. Members who want to read the rules can find them; the DM references their existence without making them the first thing a new member encounters.
One specific mistake to avoid: the comprehensive preamble. Some operators write a lengthy introduction to the rules document that explains the community’s philosophy, its values, and the historical context for why these specific rules exist. This introduction is almost always longer than the rules themselves. It inverts the document’s function: the document should start with the rules — the specific, behavioural, actionable standards members need to self-moderate — and if the operator wants to include philosophy and context, it belongs after the rules, not before them. A member who opens the rules document to check a specific standard before posting should be able to find that standard without reading three paragraphs of preamble first.
6. When rules do not cover a situation
Every rules document has gaps. Some gaps are predictable — the behaviour you have not anticipated yet, the combination of rules that creates an apparent conflict, the norm that exists in the community but that you have not articulated clearly enough to write down. Some gaps emerge from situations that simply do not fit any of the three standard rule categories: they are not value-before-promotion situations, not DM-consent situations, not feedback-solicitation situations. They are something else.
The default response to a rules gap is DM-first. When a situation surfaces that does not fit any existing rule, the operator contacts the member privately, acknowledges that the situation is not explicitly covered by the current rules, explains what they are observing and why it does not align with the community’s values, and describes what they would like to see instead. The member gets the same treatment they would get under the dispute resolution ladder for a covered situation: a private message that names the specific behaviour, explains the relevant standard (even if the standard is “this is how we operate here, and we haven’t written it down yet”), and describes what the operator expects next. Acknowledging that the rules do not explicitly cover the situation is not a weakness in the operator’s position; it is an accurate statement that most members experience as more trustworthy than an improvised claim that the behaviour violated a rule it did not technically violate.
After the private resolution, update the rules to cover the gap. The sequence — resolve privately, then codify — is important. The temptation when a gap becomes visible is to address it publicly in the moment, either by posting a new rule in #announcements while the situation is live or by referencing the missing rule in the original thread. Both approaches create a public association between the new rule and the specific member or situation that surfaced the gap. Members who observe this association learn that rules are created reactively in response to specific incidents, which makes every new rule feel targeted rather than principled. Rules updated quietly, after a private resolution, arrive as standing policy. Members who read the updated rules document see a new standard; they do not know what prompted it.
The DM-first default also applies when two rules appear to conflict. If a member’s post satisfies the value-before-promotion count but the content of the promotional mention is something the operator would ordinarily address through the DM-consent rule — a promotional DM follow-up to an apparently-community-facing post — the operator contacts the member privately rather than resolving the apparent conflict through a public statement about which rule takes precedence. Apparent rule conflicts almost always dissolve when the operator talks to the member directly, because the specific facts of the situation are usually different from what the apparent conflict suggests. What looks like a rule conflict in the abstract is usually a specific behaviour that one rule covers clearly once the operator has the full picture. The paid community moderation reference card includes the five properties of enforceable rules and the five wrong moderation patterns structured for quick reference; the wrong-pattern table covers the failure mode of creating public precedents from private-appropriate resolutions.
The longer-term management of rules gaps is a quarterly rules review. Once the initial rules document is in place, the operator reviews it every three months against the private messages they have sent in that period: are there patterns of behaviour that prompted DMs that are not covered by the rules? Are there rules that have never been invoked because they cover situations that have not arisen and may not arise? Are there rules that have been invoked but that members visibly struggle to apply before posting because the wording is not specific enough? The quarterly review is a thirty-minute operation that keeps the rules document calibrated to what the community actually needs rather than what the operator anticipated needing when the document was first drafted. The Foothold community health check covers the contribution distribution and engagement metrics that surface moderation pressure before it becomes visible; those same metrics surface the categories of behaviour that are increasing in frequency and that may need rules coverage before they become a pattern.
Frequently asked questions
What rules should a paid community have?
The three rules most paid communities need and rarely have in documented form are a value-before-promotion rule with a specific count (three non-promotional contributions visible in the community before any mention of external paid work — not “add value first,” which has no enforcement basis), a DM-consent rule specifying that direct messages about business or services require visible consent in a public thread before the member moves to DM (the visibility of the consent is what makes the rule enforceable), and a feedback-solicitation rule specifying whether unsolicited critique is permitted in the community or requires an explicit invitation from the member who posted. Beyond these three, the rules that matter most are the ones that correspond to situations your community has already encountered informally — patterns of behaviour you have addressed through private messages but have never written down. The private messages the operator has sent in the past three months are the best source for identifying which rules the community needs next.
How do you write community rules that members actually follow?
Rules that members actually follow are specific (naming a concrete action, not a value), behavioural (describing something observable that the operator can verify and the member can check against), consistent (applying to all members regardless of tenure or relationship with the operator), graduated (specifying consequences on first, second, and escalated occurrences), and operator-modelled (demonstrated by the operator’s own visible behaviour before they are required of members). The diagnostic for whether a rule meets this standard: can a member who reads it before posting know whether their planned post violates it? If the answer depends on interpretation of a word like “respectful” or “appropriate” or “valuable,” the rule needs to be rewritten to describe a specific observable action. The value-before-promotion rule rewrites from “add value before promoting” to “three or more non-promotional contributions visible in the community before any mention of external paid work”; the same rewrite applies to every rule that currently describes an orientation.
How do you introduce new community rules without alienating existing members?
The frame that works is codification, not restriction: “We are writing down how we have always operated, not introducing new standards.” This is accurate in most cases: the rules you are writing down are the norms you have been informally enforcing. Introduce rules before an incident, not after — rules introduced immediately after a public moderation event get associated with the event and feel reactive and targeted rather than principled. A two-week buffer between a moderation event and a rules announcement is usually sufficient. The announcement itself should be brief: a short post in #announcements, a link to where the rules are posted, an invitation to ask questions. The document should begin with the rules — not with a lengthy preamble explaining the philosophy behind them. Members who open the rules to check a specific standard before posting should be able to find that standard in the first screen.
What is a value-before-promotion rule for paid communities?
A value-before-promotion rule specifies the minimum number of non-promotional contributions a member must make — visible in the community’s public channels — before mentioning external paid work, products, or services. The essential feature is a specific count. Three is the standard minimum. The rule must define what counts as a non-promotional contribution (a question, an answer, a resource share without an affiliate link, a response to another member’s post) and what counts as promotion (a link to a paid product, a mention of a service the member sells, an invitation to a paid event). Without these definitions, members count differently than the operator does, and enforcement conversations become disputes about whether a given post qualifies. The word “visible” is also essential: contributions that exist only in DMs do not satisfy the requirement because the operator cannot verify them and the community cannot observe them. A contribution that no other member can see is not evidence of community participation; it is preparation for it.
What do you do when your community rules don’t cover a situation?
When a situation arises that does not fit any existing rule, contact the member privately: acknowledge that the situation is not explicitly covered, explain what you are observing and why it does not align with the community’s values, and describe what you would like to see instead. Handle the situation the same way you would handle any DM-first intervention. Then update the rules after the private resolution, not before or during. Rules updated after a private resolution arrive as standing policy; rules announced while a situation is live feel targeted at the member or situation that prompted them. Apparent rule conflicts almost always dissolve when the operator talks to the member directly, because the specific facts of the situation are usually different from what the apparent conflict suggested. Manage gaps through a quarterly rules review: the private messages sent in the last three months identify which patterns need written coverage, and the rules that have never been invoked identify candidates for removal from a document that should remain short enough to be read.