How to Evaluate a Discord Community Manager: The Five Documents Audit

📌 How to evaluate a Discord community manager without guessing: ask for five documents instead of five metrics. The channel map, onboarding sequence, coverage schedule, escalation ladder and weekly report are the written form of work you cannot see from inside the app. How many exist tells you whether you hired an operator or handed one person a job nobody scoped.

---

How to evaluate a Discord community manager in one afternoon

Ask for five documents, then read what comes back.

1. The channel map
2. The onboarding sequence
3. The coverage schedule
4. The escalation ladder
5. The weekly report Give a week to produce them. Count how many exist, check when each was last touched, and notice how much of each one still lives only in the writer's head. Four or five present and current means you have an operator. Two or three means you have a capable person in a role nobody scoped. Zero or one after three months means the community is running on memory. That is the whole audit. It works because those five documents are the written form of the work you cannot see from inside the app, and because anyone who has been building systems already has most of them in rough form. Anyone who has been holding the room together by hand has none of them, and the gap is the finding. The rest of this covers what each document proves, what its absence causes, how to read the score fairly, and where the audit stops.

Why the visible signals mislead you

Open your server on a weekday and you can see messages, replies, an announcement, a busy general channel. All of that is output.

Everything visible inside the server is output. The routines that produce it live somewhere else, in documents or in one person's head.

Because the routines are invisible, evaluation drifts toward feel. Busy looks like health, quiet looks like decline, and neither reading survives contact with reality. A server can look lively while nobody has checked the support queue in two days. A server can look slow during the week its owner finally wrote the moderation policy. There is a second reason the signals mislead. Most people hire for this role without writing down what the role does. The job description says community manager, the interview covers tone and Discord experience, and the actual work turns out to be four jobs stacked into one: moderation, engagement, member support, and operations. Nobody agreed which of the four came first. Six months later the founder is frustrated and cannot name what is missing, because the thing that is missing was never asked for. The five document audit fixes both problems at once. It makes the invisible work visible, and it exposes the parts of the role nobody ever assigned.

The five documents, and what each one proves

Document	The question it answers	What its absence causes
Channel map	What is each room for, and who answers in it	Channels open, nobody owns them, members stop asking
Onboarding sequence	What does a new member meet in the first week	Arrivals never become participants
Coverage schedule	When is a human actually watching	Moderation collapses in the uncovered hours
Escalation ladder	What happens when something goes wrong	Every incident becomes an argument between stressed people
Weekly report	Is the community improving or drifting	The only available signal is opinion

1. The channel map. Every channel in the server on one line each: what it is for, who answers in it, and what happens if nobody does. A server with #general, #support, #feedback, #bugs and #introductions is making five separate promises, and each promise implies a person. Without the map, channels get created because someone asked for one and then quietly die because nobody was assigned. Members learn that some rooms answer and some do not, and they stop working out which is which. A good version is a short table with columns for channel, purpose, owner, and expected response time, updated the last time a channel was added. 2. The onboarding sequence. What a new member sees at minute one, hour one, day one, and day seven, written as steps with owners and triggers. A welcome message is one step inside this. The first 48 hours decide most of what happens next, because that is the window where a new member is still paying attention and still willing to try. If entry is unclear or the first question goes unanswered, the person is gone and no re engagement campaign brings them back. A good version numbers the steps, names the trigger for each one, and states the single action you want the member to take before they close the app. 3. The coverage schedule. The hours of the week when a named human is genuinely watching, with the uncovered hours listed rather than glossed over. Moderation rarely collapses because moderators are careless. It collapses at 3am in a community whose members span twelve time zones and whose team spans one. Written coverage turns that from a mystery into a scheduling problem, and it tells you precisely which hours automation has to hold. A good version is a weekly grid with names in the cells, gaps marked plainly, and a line describing what runs during the gaps. 4. The escalation ladder. What happens at each level of trouble, who decides, how fast, and where the record goes. Level one might be a heated argument between regulars. Level three might be a coordinated raid, a doxxing attempt, or a legal threat. The absence of this document is what produces the drama founders lose sleep over, because without it every incident becomes a live negotiation between people who are stressed, and the outcome depends on who happened to be online. A good version lists three or four severity levels, the action at each, the named decider, a time expectation, and the place incidents get logged. 5. The weekly report. The same handful of numbers every week, defined the same way, with a short note on what changed. Highlight reels do not qualify. Anything you can only compare against a feeling is not a report. A good version holds four or five numbers constant for months: new members, the share of new members who post in their first week, median time to first response in support, open incidents, and active contributors. The definitions are written down so they cannot quietly drift when the numbers get uncomfortable.

How to score what comes back

Four or five present and current. You have an operator. The right response is more scope, more budget, and a second pair of hands before this person burns out.

Two or three present. You have a capable person in a job nobody scoped. The documents that exist usually cluster around whatever they personally care about, and the missing ones are the parts of the role that were never assigned. Fix the scope first, then judge the work.

Zero or one after three months. The community is running on memory. This is not automatically a firing. It is a warning that your operating knowledge walks out of the building the day that person does.

Two things make the score fair. Check the dates: a channel map written in month one and never touched since is a historical document, not a working one. And read for honesty over polish. A coverage schedule with three gaps openly marked is worth more than a tidy one that pretends the server is watched around the clock.

The three failures this audit exposes

Scope failure. One person was hired to do four jobs. Moderation runs on a different clock than engagement. Support needs product knowledge. Operations needs documentation time that nobody scheduled. When the audit comes back with two documents, the two that exist tell you which job the person believes they were hired for, and the three missing ones tell you what you have been silently expecting. Coverage failure. Communities do not go bad during business hours. They go bad in the hours when nobody with authority is present, and the fastest read on that risk is a coverage schedule with the gaps written down. Once the gaps are visible you have real options: staggered hours, a second moderator in another region, tighter automated rules on the risky channels overnight, or a slower mode during unwatched hours. Escalation failure. The stories founders tell about Discord going wrong are almost always escalation stories. A conflict grew for three days because nobody was sure they had the authority to act. A ban was reversed publicly because nobody had agreed who decides. Those are not people problems. They are the predictable result of an undocumented decision path.

How to ask without turning it into an interrogation

The request lands badly when it arrives as a test. It lands well when it arrives as an attempt to support the role, which is also the honest framing, because half of what you find missing was never assigned.

Hey, I want to get better at supporting this role, and to do that I need to see the operating side of it.

Could you send me whatever exists of these five, in whatever state they are in:

1. Channel map: every channel, what it is for, who answers in it
2. Onboarding sequence: what a new member sees at minute one, hour one, day one, week one
3. Coverage schedule: the hours a human is watching, and the gaps
4. Escalation ladder: what happens at each level of trouble, who decides, how fast
5. Weekly report: the numbers you would track every week if you had the time

Rough notes are completely fine, I am not looking for polish. If one of these does not exist yet, just say so and tell me what would need to be true for you to write it.

Take the week.

Most people return two of the five and then tell you exactly which three they have been meaning to write. That conversation is more useful than any performance review, because it produces a work plan instead of a verdict.

Where this audit stops

These five documents cover two slices of a community operating layer: what is written down, and who is watching. The rest of that layer is worth naming so you know what the audit does not touch. Role and channel architecture. Onboarding and the first 48 hours. First response time. Support routing. Moderation load. Engagement rhythm. Automation coverage. Escalation paths. Documentation. Community reporting. The audit tells you which of those exist in written form. It says nothing about whether the design underneath them is any good. A channel map can exist and describe a badly structured server. A coverage schedule can be honest and still leave your busiest hours uncovered. Reading the five is how you find out which of those deeper questions you actually have, and in what order they need answering.

What to do this week

Send the message. Give the week. When the documents come back, count them, date them, and write one sentence for each one describing what it would take to bring it to a usable state. Then decide, and be specific about which decision you are making. Widening the scope of someone who is already building systems is a different act from rewriting a role that was never defined, and both are different from accepting that your community currently runs on one person's memory. All three are legitimate. Only the third one is dangerous when you do it without noticing.

*The best operators in this work leave behind a server that a stranger could run on a Tuesday. Everything else is performance. *danieljeong.org