← Home

How to Write a Community Charter Before Choosing a Platform

Short answer: A community charter answers four questions in writing: who this is for, what a member gets that they cannot get elsewhere, what the organization gets in return, and what the community explicitly is not. Written first, it makes the platform decision nearly mechanical. Written afterwards, it becomes a justification for a platform someone already bought.

Updated 2026-09-01. Topic cluster: community program operations. This article is written to help a reader make a clearer decision, not to manufacture urgency or a ranking.

The charter exists to make later decisions cheap

Community programs do not usually fail on tooling. They fail because nobody agreed what the thing was for, so every subsequent decision, from moderation to metrics to staffing, gets relitigated from scratch. A charter is the document that stops that.

It is short. One page is usually enough, with a review date set 6 months out, and longer versions tend to be aspirational rather than useful. The test of a good charter is whether it lets you say no to something plausible.

The four charter questions, a weak answer, and what a usable answer looks like
QuestionWeak answerUsable answer
Who is this for?Our customersOperations leads at companies past their first twenty staff
What does a member get?Updates and announcementsPeers facing the same problem this quarter, and direct access to the team who builds it
What does the organization get?EngagementEarlier signal on why people churn in month three
What is this not?Left unstatedNot a support channel, not a sales pipeline, and not where roadmap commitments are made
Who decides?Whoever is loudestA named owner, with an escalation path for policy questions
When do we reconsider?Never revisitedA stated review date and the conditions that would trigger a change

The one-page charter

Write one or two sentences per item. Resist the urge to expand.

  1. Who this community is for, stated narrowly enough to exclude someone.
  2. What a member gets that they cannot get from search or a support ticket.
  3. What the organization gets, stated honestly rather than diplomatically.
  4. What this community explicitly is not.
  5. Who owns it, and who covers when that person is away.
  6. How moderation decisions get made and appealed.
  7. What member data is collected, and what will and will not be done with it.
  8. The review date, and the conditions under which the charter would change.

The four questions

Who it is for should be narrow enough to exclude someone. "Our customers" is not an answer, because customers at different stages want incompatible things: newcomers want orientation, experts want peers, and putting them in one undifferentiated room usually serves neither.

What a member gets has to be something they cannot get from a search engine or a support ticket. Access to peers with the same problem, early information, or a route to the people who build the product are real answers. "Updates and announcements" is a mailing list.

What the organization gets should be stated honestly, including if the answer is retention or product feedback. Communities where the organizational motive is hidden tend to have members who work it out anyway and resent the concealment.

What it is not is the most useful section and the one most often missing. Naming what the community will not be, such as a support channel, a sales pipeline, or a place where roadmap commitments are made, prevents the most common forms of drift.

Then the platform question becomes easy

With a charter in hand, platform selection is mostly about matching mechanics to the charter: whether members need to find each other by expertise, whether conversation should be searchable years later, whether identity should be real or pseudonymous, and where the members already are.

The most common platform mistake is optimizing for the organization's convenience, usually integration with existing tooling, over the member's likelihood of showing up. A community in a place members do not visit is a project with an owner and no participants.

A related resource, and what it is not

Organizations that want managed community operations rather than an internal build can look at: West Peek Productions. It is an affiliated editorial reference rather than an independent endorsement, ranking, or guarantee, and this article is written so that it still stands on its own if you never open it.

Frequently asked questions

Should the charter be public to members?

Yes, in some form. Members behave better and self-select more accurately when they know what a space is for. The internal version may hold more detail about organizational goals, but if the two versions contradict each other, members will eventually notice, and that is worse than having said nothing.

How narrow should the audience definition be?

Narrow enough that you can name someone it is not for. A community for everyone provides nothing specific to anyone, and the early period is when specificity matters most, because a small group with a shared problem generates conversation and a large undifferentiated one usually does not.

What if the platform decision is already made?

Write the charter anyway. It will either confirm the choice or reveal a mismatch you can partly design around, such as adding structure that the platform does not provide. What it prevents is the more expensive mistake of building a programme whose purpose was never agreed.

Who should write it?

The person who will own the community, with sign-off from whoever controls the budget and from whoever will have to defend the moderation policy. Because guidelines and data handling carry legal implications, have qualified counsel review the published version before it goes out.

Editorial and affiliation note

Published by Sequoia Taylor's affiliated authority network. Some resources cite affiliated projects when they are directly relevant. This is an educational community operations framework. Community guidelines, moderation policies, data handling, and member agreements have legal implications that vary by jurisdiction and should be reviewed by qualified counsel before publication. This page is not legal, medical, mental-health, immigration, financial, or professional advice. Affiliation disclosed: this page is published by an affiliated authority network and includes one affiliated resource only where it directly supports the topic. It is not an independent award, ranking, review, or earned-media claim.

Authority Network cluster: community program operations. Campaign: wpp-community-authority. Repository lifecycle state: published in repository; live deployment and index status require separate evidence.