Slack Communities: Build, Join or Sponsor, Decided First

Start with the bill. Slack's free plan keeps ninety days of message history, so any community you run on it either pays per member or loses its archive on a rolling basis. At Pro rates a two thousand member community costs somewhere near one hundred and sixty thousand euros a year, for a room whose search results otherwise expire. That single line decides more Slack community strategies than any content plan, and it is why most branded Slack communities should not exist. Where Slack genuinely works: Three cases. A closed peer group of senior people, under about three hundred members, where the per-seat cost is defensible because the membership itself is the product. Slack Connect channels with named accounts, which is customer operations rather than community and should be resourced as such. And other people's Slacks — the operator-run communities your buyers already sit in, which in media means groups like News Product Alliance and the OpenNews network, and in hiring and content means the practitioner rooms where vendors get discussed candidly and unprompted. What I do: The engagement produces a decision, written down: build, join, sponsor, or do nothing. I cost your intended community honestly, including the moderation hours nobody budgets, and set it against Discord, a hosted forum, Circle, and the unfashionable option of a newsletter with three events a year. I have recommended the newsletter more than once. Where the answer is to participate in communities that already exist, I make the introductions to their operators, negotiate the terms, and set what your people may and may not do inside somebody else's room. Sponsorship terms: Any placement is disclosed by the operator to their members, in the operator's own words, before it runs. Attribution is agreed with them in advance — usually a code, a dedicated landing path, or nothing at all, and I would rather report nothing than a number both parties know was invented. If an operator will not disclose a sponsorship, I will not place it. The arrangement only has value while the members trust the room, and their trust is the thing you are renting. What I will not do: I will not treat a community as a mailing list with extra steps. No exporting the member directory, no cold messages from the admin account, no adding people to a nurture sequence because they joined a channel. These are the actions that kill communities, and they kill them quickly and permanently. I will also not build a community whose stated internal purpose is pipeline; members read the purpose off the first week of channel activity and behave accordingly. Building a peer group: Where that is the right answer, the work is vetting rather than recruitment. Membership criteria, an application process that turns people down, and a written rule about what senior members can say inside that they would not say publicly. Onboarding runs through Workflow Builder so a new member arrives with a name, a reason and a first conversation inside a day. Instrumentation through Common Room, with an explicit list of what we will not track, because a member who discovers they have been scored leaves and explains why on the way out. Who this is not for: Anyone who wants members counted rather than known. Companies whose sales team will not respect a rule about not selling inside the community — I have watched that rule break once and take the community with it. And early-stage businesses: below a few hundred customers you do not have a community, you have a users' group, and a shared channel with your best twenty accounts will do more than anything I would build here.