What a Skool community operator actually does all day

Before I built CommunityHQ I would have told you that running a community is basically posting. You make a place, people come, you put up good stuff, and the thing grows. That's what it looks like from inside as a member, which is the only side of it I'd ever been on.

That picture is wrong in a way that matters, and getting it corrected is most of why the product looks like it does. CommunityHQ has a co-founder, Kishia Ward, and a decent share of what I know about this job I know because I didn't have to guess at it by myself.

So here's the actual shape of the work, as best I understand it. It's useful whether or not you ever touch my software, because the thing I found most surprising is how little of the job is the part everyone thinks is the job.

The posting is maybe a tenth of it

The visible layer — the posts, the lives, the lessons — is the part that looks like work from outside and is genuinely the smallest slice of the calendar. Underneath it is a continuous operational grind that produces no artifacts and that nobody thanks you for, and it runs every single day whether or not you had anything to say.

Roughly, it breaks into these:

Onboarding, one person at a time, forever. Members don't arrive in a cohort. They arrive on a Tuesday, individually, at some random point in your community's life, having read a sales page and nothing else. Every one of them needs to be welcomed, oriented, and pointed at a first thing to do. And it's relentless in a specific way: the work doesn't accumulate into anything. You do it perfectly for the person who joined today and tomorrow you start from zero for someone else.

The first-day cliff. This is the one that reframed the whole product for me. A member who doesn't do something early — post, comment, complete a first module, anything — mostly never does. They don't quit. They just stay signed up and never open it again. Which means the highest-leverage hours in a member's entire lifecycle are the first ones, and they're the hours when the operator is least likely to notice they exist.

Keeping the feed from going quiet. A community that's silent for a few days reads as dead, and reading as dead makes it dead — people who were going to post see nothing to post into and don't. So somebody has to keep putting up prompts, questions, threads. Constantly. Whether or not they feel like it, and long past the point where it feels natural.

Answering the same six questions. The FAQ that never quite becomes an FAQ, because writing it down is a project and answering it again is thirty seconds. So you answer it again. Roughly forever.

Noticing who's drifting. Nobody announces they're leaving a community. There's no cancellation email, no goodbye post. They just open it less, then not at all, and the operator finds out at the renewal date. It's exactly the silent-failure shape I keep running into everywhere else — the thing that would tell you it's going wrong is the person who has already stopped showing up.

Setting the tone. Small, constant, entirely judgment. How a slightly-off comment gets handled. Whether the room is warm or performative. This is a thousand micro-decisions and it is the actual product.

Look at that list and the pattern is hard to miss: it's formulaic enough that you could write down the steps, and heavy enough that doing the steps burns people out. That gap is the whole reason the tool exists.

The line: automate the preparation, never the presence

Here's where I had to be careful, because "AI runs your community" is a product I could have built and would have been bad.

The stuff that's safe to automate is the scaffolding. The structure of the community — what categories exist, what the onboarding sequence should be, what a sensible content calendar looks like for this kind of group. That's genuinely formulaic, it's the part that takes an operator a week of staring at a blank page, and a model that's read a lot of communities is legitimately good at proposing a starting shape. That's what CommunityHQ's blueprint engine does: it generates the structure, the content, and the automations a community needs, so the operator starts from a draft instead of nothing.

Drafts. That word's doing a lot of work.

Because the stuff that is not safe to automate is the presence. The reply to the member having a hard week. The judgment call on the borderline post. Being visibly, personally there — which is not a feature of the product, it is the product. People don't pay for a forum. They pay to be in a room with a specific person and the people that person attracts.

And there's a nastier version of this: automated engagement is actively worse than silence. A quiet community reads as small. A community full of obviously-generated prompts that nobody answers reads as fake, and fake is not recoverable. You can grow out of small. You can't grow out of the moment your members work out that the warmth was scheduled.

So the rule I landed on is the same one I keep landing on: the machine does the preparation and a person does the last inch. Same instinct as the outreach bot that drafts but never sends. Draft the welcome sequence — don't be the welcome. Surface the member who's gone quiet — don't send them an automated we-miss-you. Propose the week's prompts, let the operator pick the three that sound like them and throw the rest away.

The test I use: if a member found out this part was automated, would they feel served or would they feel conned? Nobody minds that your content calendar was drafted by a machine. Everybody minds that your check-in was.

What that means for how you spend your week

If you're operating one of these, the practical read of all the above is that your time is going almost entirely into the invisible layer, and the invisible layer is mostly work you'd never choose to do.

Which suggests the reasonable order of business: get the repeatable structure off your plate first — the onboarding path, the calendar skeleton, the prompt bank — because that's where the automation is both safe and worth the most hours. Then spend every hour you just bought on the first day of a member's life and on the people going quiet, because those are the two moments where a person being genuinely present changes the outcome, and no amount of good tooling substitutes for it.

That's not a clever insight. It's just what falls out of the list once you write the list down, which is roughly why writing the list down was the useful part.

Where this actually stands

Honest status: the MVP is built and verified, and what it needs now is pilot communities — real operators running it on real members. A tool about operations only proves itself in the mess of actual operations, and mine hasn't been through that mess yet.

So treat everything above as a well-informed model of the job rather than a report from a year of running one. I've described the shape of the work carefully because getting the shape right is what a product is; whether my answer to it holds up is a question that only gets settled by people who do this every day. That's the same shelf problem I've got everywhere — a thing that works, waiting on the only test that counts.

This one's auto-drafted from my notes on a schedule. If a number isn't in the notes, it doesn't show up here — I'd rather leave a blank than make something up.