Five ways to lock a room, and the second setting everyone forgets
The first week of running a community is mostly deciding who can see what. It looks like a small job. It is where most communities acquire the problem they still have a year later, which is that everything is either wide open or invisible, and there is no shape in between.
Klaas splits the decision into two settings that people routinely conflate.
Access: can they get in?
Every channel carries one of five access levels.
| Level | Who gets in |
|---|---|
| Open | Any member of the community |
| Private | Only people invited or approved individually |
| Paid members | Anyone with an active paid membership |
| By plans | Only the specific tiers you pick |
| By segment | Only members in a named group |
Courses, events and library items use the same idea with one substitution: instead of private they offer one-time fee — buy this single thing, no subscription. Which is exactly right, because "invite one person to this course" is a job for an enrolment, and "let anyone buy this workshop without joining a tier" is a job nothing else does.
Most people reach for paid members and stop. The two worth learning are the other two.
By plans is how you make tiers mean something. If you sell Standard and Pro and the only difference is a number on a pricing page, nobody upgrades. Point two channels and one course at Pro and the tier becomes a place rather than a claim.
By segment is the one that unlocks cohorts. A segment in Klaas is a static list of members with a recorded reason for being on it — added manually, by an import, by a workflow, by buying a plan, by an invite. So "the March cohort" is a real, durable list, and the channel for the March cohort points at it. When April starts, you make another one. You are not re-plumbing permissions every eight weeks.
Visibility: do they know it exists?
This is the setting people miss, and it is orthogonal to the one above. Every channel has three:
- Community — visible to members, who can see it is there even if they cannot enter.
- Public — visible to logged-out visitors, so a search engine and a curious stranger can both see it.
- Hidden — only appears for members who already have access.
The reason these are separate settings is that "locked" and "secret" are different products.
A locked but visible channel is a sales surface. A free member sees #pro-critiques, sees the padlock, and now has a reason to upgrade that no pricing page could give them. This is the single most under-used setting in community software.
A hidden channel is genuinely private. The moderators' room. The channel for one client. If somebody who cannot enter can see it in the sidebar, you have created a small ongoing social problem for no benefit.
Getting this backwards is common in both directions. Hiding everything paid means your free members never learn what they are missing. Making the moderators' channel merely locked-but-visible means every member knows there is a room where they are being discussed.
The lock screen is a product surface, not an error
Here is the thing I would most like people to take from this post.
When someone hits something they cannot access, the software has to say something. The default in most tools is a 403, a bounce to a pricing page, or the item quietly not rendering. All three are decisions, and all three are bad ones.
In Klaas a lock screen carries your title, your explanation, and your button with your label and destination. That is a small feature with a disproportionate effect, because that screen is being read by the most qualified person you will ever have: somebody who went looking for the thing.
Two things worth doing with it:
- Write the copy per item, not once. "Upgrade to Pro to unlock" is what everyone writes and it is nearly useless. "This is the Tuesday critique room — Pro members post work for feedback every week. It's the reason most people upgrade." is the same padlock doing actual work.
- Make the button go somewhere true. If the path forward is really "ask a human", say that. A button that files a request nobody reads is worse than a sentence that tells them to email you.
We learned the second one the hard way: we once shipped a request-access flow where the member could ask, the host got a notification, and the notification pointed at a page with no approvals surface on it. Every test passed. Nothing errored. The feature was end-to-end inert, and it took a fresh reader to spot it.
Which is why there is a rule now: for a channel, "Request access" is a real button that files a real request you can approve or decline, and the member sees a pending state and can withdraw it. For a course, event or library item, there is no such flow, so the copy tells them to contact a host instead of drawing a button we cannot honour. An honest sentence beats a hopeful control.
A setup that works
If you want a default to start from:
#announcements— open access, community visibility, posting restricted to admins. Everyone in, nobody shouting.#general— open, community, members can post. The room the community actually lives in.- A paid channel — by plans, community visibility so free members can see it and want it, with lock-screen copy that describes what happens inside rather than what it costs.
#hosts— private access, hidden visibility. Nobody needs to know.- Cohort channels — by segment, hidden, created per intake.
Then check your work the only way that counts: open your community in a private window, signed out, and again as a free member. What you can reach as those two people is your actual configuration. The admin panel shows what you intended.