How to Delegate Community Tasks Without Hiring More Moderators

Who this is for: the founder or community lead whose review queue is growing faster than the team, staring at a few thousand pending submissions and wondering whether the answer is a second moderator, a third, or a resignation letter.

Short answer: Probably not another person — but not for the flattering reason. Most of the queue should not exist. In Zealy, five task types are built to require a human to read the answer — and the date task joins them on its default setting — while everything else settles itself the moment a member claims it. Delegation to a rule beats delegation to a person, which beats delegation to a machine, in that order, because only the first one deletes work instead of moving it.

Disclosure: Zealy publishes this and Zealy sells the platform described in it. Every claim about what Zealy does was read out of Zealy's own source code on 16 August 2026, not from Zealy's marketing pages or documentation. That includes the parts where Zealy is missing something obvious, and two pages of Zealy's own documentation that are wrong, which we are correcting in the same change as this post.

Last verified: 16 August 2026.

Do you need to hire more moderators?

Probably not yet. In Zealy, five task types are built to reach a human reviewer: text, URL, number, file upload and poll — and the date task joins them on its default setting. Everything else verifies itself and never enters a queue. Before you add people, audit which of your quests actually need a person to read the answer.

Almost every "we are drowning in submissions" conversation starts at capacity — how many reviewers, how many hours, how fast each clears an item — when the size of the queue was decided weeks earlier in the quest editor, by whoever chose the task type. A quest that asks for a screenshot creates a queue. A quest that asks someone to join a Discord server does not, because the answer is checked against Discord on the spot. Same campaign, same reward, wildly different operational cost.

So the honest sequence is: remove the work, delegate what remains, automate what is left. Teams reliably do it in reverse, which is how you end up paying for a plan upgrade to speed up work you could have deleted.

The three ways to delegate a review queue

You can delegate a review queue three ways: to a rule, by making the task self-verifying; to a person, using Zealy's reviewer role; or to a machine, using AI review or an MCP agent. Rules remove the work, people apply judgement, machines apply a written prompt at volume.

Route one: design the review work away

Start here: it is the only route that removes work rather than moving it. Five Zealy task types are built to require a human — text, URL, number, file upload and poll — and date behaves the same way by default. Everything else resolves when a member claims it. Rewriting a text task as a link check empties the queue.

We checked this by reading the function that decides whether a quest is auto-validated, then cross-checking every runtime validator in the quest service. Those five — text, url, number, file, poll — each return a pending review status unless the task is explicitly set to auto-validate. The others return success or an error synchronously, so there is nothing to wait for and no queue to wait in.

Two honest exceptions, because the code contradicts itself and we would rather say so than tidy it up:

• Date tasks. One list treats them as always automatic, while the validator that actually runs honours the task's auto-validation setting, which the editor leaves off by default. We will not tell you date tasks are automatic when the code disagrees with itself. Test one before you rely on it.
• Proof of Humanity. It resolves automatically at runtime but appears in neither list — as does the partnership-quest type — so a quest containing only that task is reported as not auto-validated. It behaves better than it advertises. (What it catches is covered in how to run an airdrop that doesn't get farmed — it is a bot filter, not a sybil filter.)

The rewrite that actually shrinks the queue

Look at your text tasks first. Most ask a question with one right answer, phrased as an essay. Tell us what you learned from the docs is a queue. Paste the transaction hash is a text or URL task with a correct answer, and it clears itself. Screenshot your position is a queue, and a file task does no content check at all, so a reviewer opens every image. Which of these three is our fee model is a quiz, and quizzes never reach a human.

The rule of thumb we would defend: if you can write the answer down in advance, the task should not be in the queue. If you cannot, staff it rather than pretend a prompt will do it.

The footgun: an empty correct answer approves everything

This is the paragraph in this article most likely to save you a bad week. Auto-validation on text, URL, number and date tasks compares a member's submission to a correct answer that you configure, and all four comparisons short-circuit when that correct answer is empty. It does not fail closed and it does not warn you. It approves everything.

Two related behaviours to know before you flip switches in bulk. A poll with auto-validation on approves everything by design — not a bug, since a poll has no wrong answer, but toggling auto-validation across a module to clear a backlog hands out the poll rewards to everyone. And auto-validating a file upload approves the upload, not the contents; any file passes.

If you take one operational habit from this post, make it this one: after enabling auto-validation, claim the task yourself with a deliberately wrong answer and confirm it fails.

One duplicate control removes work; the other only annotates it

Reviewer alerts flag a submission as duplicate (another member sent the same content for the same task) or reused (this member sent it before), on text and file tasks only, looking back 180 days. They are advisory — nothing in the code path that records a verdict reads them. They tell a human something; they decide nothing. And on file tasks the matching is weaker than it sounds: uploads are compared by their stored URL, and every upload gets a fresh key, so re-uploading the identical file never registers as a duplicate at all.

Duplicate rejection at submission is a separate, opt-in setting that rejects a repeated text answer with an error before it reaches your queue. It is off by default on text and URL tasks, normalises by trimming, collapsing whitespace and lowercasing — so a paraphrase walks past it — and it blocks any member from reusing that text, including whoever wrote it first. That is the one that shrinks a queue.

Route two: delegate to a person with the reviewer role

Zealy's reviewer role is a narrow delegation: it opens nine of the 225 role-gated route surfaces in Zealy's API, all of them about reviewing, and a reviewer cannot approve their own claims. You hand it out with an invitation link that carries a role, an expiry and a maximum number of uses.

There is no role called moderator in Zealy. The role is reviewer, and there are five roles in total: admin, editor, reviewer, guest and banned. (Zealy's own member-management documentation says there are four. It omits banned, which is a real role that the change-role endpoint accepts. That page is corrected in the same change as this post.)

The five roles sit on a strictly linear ladder — admin above editor above reviewer above guest above banned — and every permission check in the product asks one question: is this member's role at least this level? So the honest description of Zealy's permission model is that there isn't one. No permission sets, no custom roles, no way to scope a role to one quest, module or campaign. We searched the model and database definitions for permission, ability and grant concepts; the only matches were unrelated OAuth columns.

Here is what the ladder distributes across those 225 role-gated surfaces:

Because the ladder is linear, a reviewer also gets everything gated at guest level. But those nine surfaces are the whole of the delegation and they are all review work, which is why promoting someone to reviewer is a far better answer than promoting them to admin so they can help out.

Note the editor row. Editor is a much wider grant than reviewer: it carries everything a reviewer can do, plus quest, module and sprint configuration, visibility of unpublished quests, and claim resetting. Zealy's own member documentation describes it as configuring quests, sprints and members and seeing all pages, which reads narrower than it is; that page is corrected in the same change as this post. Promote someone to editor when they are building campaigns, and to reviewer when they are only reading submissions.

How to hand out the role, and what it costs you

Role changes are admin-only, and an admin cannot change their own role. The mechanism worth using is the invitation link, which carries a role, an expiry and a maximum number of uses. Use all three: an invite that expires in 48 hours with a maximum of one use is a very different object from a link sitting in a Telegram group for eight months.

Then be honest about the cost. A reviewer can attach up to 20,000 bonus XP to each claim they approve, no role check restricts it, and a single bulk action can carry 1,000 claims — so one approval sweep can mint up to 20 million XP. Delegating review delegates XP-granting power. For most communities that is fine and even desirable, since bonus XP is how a reviewer rewards an excellent submission — but if your XP feeds a leaderboard that pays out tokens, you have handed that person a lever on the payout. Zealy records a full per-verdict audit trail, so this is detectable after the fact rather than preventable. If your candidate came out of a contributor programme, how to run a crypto ambassador program covers what that role costs you.

Reviewers cannot review their own claims — silently

A reviewer's own claims are excluded from what they can approve, enforced in the service layer and again in four separate SQL guards. Good. The caveat is the interesting part: the filter is silent. A reviewer who bulk-selects a batch containing their own claim gets no error. That claim is dropped from the batch and stays pending, and nobody is told. If a reviewer swears they approved something that is still sitting in the queue, check this first.

Two reviewers on one queue will collide

There is no claiming, locking or assignment in Zealy's review queue. We searched the repository for reviewer locks, claim-taking, review assignment and assignee concepts across the API, the backend and the webapp; the assignment search returned nothing at all. The only lock in the system is a short write mutex that prevents a double-write, not a queue reservation.

The consequence is not the one you would guess. Two reviewers on the same queue see the same claims and both read the same submission. If they agree, the second one gets an error, because Zealy refuses to set a claim to the status it already holds, and that reading time is gone. If they disagree, there is no error at all: the second verdict replaces the first, rewards are cleaned up or re-granted accordingly, and nobody is told a colleague had already decided. The silent case is the disagreement, which is the one you would most want flagged. There is also no way to assign a reviewer to a specific quest or module — you cannot express "Ana handles design submissions, Ben handles on-chain proofs" in the product.

Coordinating reviewers is a human problem in Zealy today. Say it to your team out loud rather than letting them find out in a Discord argument. Partition the queue in a pinned message: by module, by day, or one person oldest-first while the other works newest-first — the crudest possible split, and it still cuts collisions.

Bulk review: one verdict for up to 1,000 claims

Zealy's bulk review accepts up to 1,000 claims in a single call, and the constraint is what that call carries: one status, one comment, one mark and one bonus-XP value for the entire batch. There is no per-item verdict inside a bulk action. That makes it excellent for a homogeneous set — every submission on a broken quest, every claim on a task you have voided — and dangerous for a mixed one, since the comment 1,000 members read is the same sentence. Sort ruthlessly before you select.

Route three: delegate the verdict to a machine

Zealy's AI review runs Google Gemini 2.5 Flash Lite against a prompt you write, per quest, on the Plus and Enterprise plans as of 16 August 2026. It does not recommend a verdict for you to confirm. It writes the verdict, and its justification becomes the comment the member reads.

Read that twice, because Zealy's own review documentation described AI review as providing intelligent recommendations to help you process reviews. That is wrong, and it is corrected in the same change as this post. There is no human confirmation step in the code path: the model returns a result, Zealy records an approval or rejection from a dedicated system account, and the model's justification lands in the member's inbox.

That is a genuinely different product decision from AI-assisted review, and it deserves a different level of care from you:

• Turn it on per quest, by enabling AI review on the quest and writing a non-empty prompt. It is not a community-wide switch, which is the right granularity: you can automate one high-volume task without automating your judgement calls.
• Write the prompt as a rejection standard, not a vibe. The model is producing a member-facing rejection message, so anything vague in your prompt becomes a vague and therefore infuriating comment on someone's submission.
• A cron re-queues stragglers every 15 minutes, picking up AI-review claims that have sat pending for over an hour with no reviewer. A backlog does not silently rot.

One measurement caveat if you use it. AI verdicts are attributed to a system account that carries an admin role, so on a community using AI review it appears in the top-reviewers analytics like any other reviewer. Before you tell your team how many claims your humans processed, exclude it.

Plans, checked on 16 August 2026

AI review is included on the Plus and Enterprise plans, and Zealy's pricing page lists it as not included on Free or Standard. On a free community we checked through Zealy's own capability API on 16 August 2026, it reported unavailable with the reason requires_plus_or_enterprise. Check the capability on your own community rather than assuming from the plan name.

Plus is $359 per month billed annually, and Enterprise is custom, billed annually. The Free plan is $0 with 1,000 quest claims per month and unlimited members; Standard is $149 per month billed annually. Prices exclude VAT and other applicable sales taxes, and all of them come from Zealy's pricing page, checked 16 August 2026.

The decision that matters: at 200 claims a week, upgrading to automate them is a bad trade against an afternoon spent converting text tasks into checkable ones. At thousands of open-ended submissions a week, with the standard written down, it is a good one.

Delegating to an agent over MCP

The other machine route is an agent. Zealy exposes review through its MCP server, and the shape of that delegation is deliberately more restrictive than the human one.

• An agent can submit up to 1,000 claims in one call, the same cap as bulk review, with the same one-verdict-for-the-batch constraint.
• An agent needs the admin role, where a human reviewer needs only reviewer. The public review route rejects an MCP review decision from anything less, so there is no agent-sized version of the narrow grant — which is the inverse of the least-privilege model you would expect.
• Every write needs a fresh human confirmation token. Not a session, not a prior approval — a new confirmation per call.
• Money is off-limits. A check on every public-admin review blocks any claim carrying an NFT, token, USDC or Zaps reward from being transitioned by an agent. An agent can clear your XP queue; it cannot move a claim that pays out. If you are running distributions, how to distribute tokens to active community members covers who actually sends what.
• Agents can only mint guest invites, never reviewer invites. An agent cannot staff your queue for you.

When the answer genuinely is another person

Hire or recruit when the judgement is the product: subjective quality, community norms, appeals, edge cases and anything where a wrong rejection costs you a contributor. Add a person when your queue holds real disagreement rather than volume. Volume is a design problem; disagreement is a staffing one.

The test we would apply before adding a reviewer: take 20 pending claims and have two people review them independently. If they agree on 19, your queue is volume, and volume is solved by rules and prompts. If they agree on 13, your queue contains real judgement, and no auto-validation setting or model prompt will make that disagreement disappear — only invisible.

Three situations where a person is the correct answer and we would not try to talk you out of it:

Creative and long-form submissions where quality is the reward criterion. If you are paying for good work rather than completed work, someone has to decide what good means, repeatedly, and defend it.

Anything with an appeal path. A rejected member who complains needs a human who can reverse the decision, and reversing a review is also what removes a Discord role already granted by an approval — a reviewer flipping a claim from success to fail does it too. Nothing else re-checks those grants; they are one-time.

High-value payouts. If a verdict decides who receives tokens, put a person on it. Zealy's own agent rules already encode that opinion: a machine cannot transition a claim carrying a financial reward.

What Zealy measures, and what it does not

Zealy shows a pending review count, a per-verdict audit trail, top reviewers by volume and by approval rate, per-member star and flag totals, and a CSV export of up to 10,000 rows. It computes no time-to-review, no queue latency, no SLA and no throughput metric. We searched the codebase for those names and found none.

We are being exact because the version of this article we originally planned was built on review-queue timing data, and that data does not exist. We searched Zealy's packages for time-to-review, review latency, average review time, review duration, review throughput and reviews-per-hour. Zero hits, no ageing buckets, no throughput dashboard. So when a vendor tells you its customers cut review time by some percentage, ask which system produced the number. We could not produce ours, and we are not going to invent one.

Two more things to read correctly:

"Top reviewers by approval rate" is an approval rate, not an accuracy rate. It tells you what share of a reviewer's verdicts were approvals. It says nothing about whether those verdicts were right. A reviewer who approves everything scores 100%.

Time-to-review is derivable, just not reported. The review CSV carries each claim's created and updated timestamps but not the review events, so for a claim reviewed once and left alone the gap between the two is your time-to-review, and a median is a spreadsheet away. Claims that were re-reviewed need the per-claim history to be accurate. That is a genuine gap in Zealy and we would rather write it down than route around it.

The arithmetic, clearly labelled as arithmetic

There is no Zealy data here, so here is a frame to fill with your own numbers. Every input is an assumption you supply, not a measurement we made.

weekly human-review load
  = claims per week
  × share of claims on text / URL / number / file / poll tasks
  × share of those not auto-validated
  × your own seconds per review

Assume 2,000 claims a week, a third on task types that need a human, none auto-validated, 40 seconds each: about 7.4 hours a week, built entirely from numbers you supplied. The point is not the answer. It is that the second and third factors become visible, and those are the two you can change without hiring anyone.

Where other tools beat Zealy at this

Zealy's Discord bot does no moderation. It never kicks, bans or times anyone out, and it ships no welcome messages, reaction roles, ticketing or logging. Discord's own moderation tools and the Discord-native bots built around them own that job. Zealy's API keys are also far more granular than its human roles.

On the first point, we searched Zealy's Discord bot source for kick, ban, timeout, bulk-delete, guild-ban, AutoMod, moderate-members and audit-log calls, and for welcome messages, reaction roles, voice channels, tickets and logging. The only matches were lines that disable caching. Its install even offers a restricted permission set alongside the full-Administrator option — Manage Roles, Mention Everyone and Send Messages — which is exactly the permission set of something that will not be moderating anything. If your problem is people misbehaving in your Discord server, Zealy is the wrong tool: our guide to Discord engagement and growth tools is the better starting point — it covers the moderation bots and the native Discord settings that handle much of this for free — and the Discord integration docs describe what Zealy's bot actually does.

On the second point, the comparison is embarrassing and internal. Zealy's API-key model has 40 distinct capabilities, including separate ones for reading reviews, exporting reviews and writing reviews, and its two quest-building presets carry no review capability at all. That is a real least-privilege model: a machine talking to Zealy can be given permission to read the review queue and not to decide it.

A human cannot. A human gets a position on a five-rung ladder, so if you want someone to triage and flag without approving, there is no way to express it. The API knows how; the role model does not. When people ask us for custom roles, this is the gap they have hit, and pointing at our own API-key model is the fairest way to admit it. And once more, because it is the operational one: any tool built as a work queue solves multi-person throughput with assignment. Zealy solves it with a pinned message in your team channel.

How to set this up in Zealy, in order

Audit which quests use the five human task types. Convert what you can. Set correct answers carefully, because an empty one approves everything. Then invite one or two reviewers on a capped, expiring link, agree who works which module out loud, and only then decide whether AI review is worth a plan upgrade.

1. Count your queue by task type, not by size, then convert what converts. What matters is how many pending claims sit on text, URL, number, file and poll tasks, and of those, how many ask a question with a knowable answer. A question with one right answer becomes a quiz or a text task with a correct answer; a prove-you-did-it screenshot becomes an on-chain, link or integration task wherever the action leaves a trace Zealy can check.

2. Test every auto-validation you enable, then turn on duplicate rejection where copy-paste is the failure mode. Claim the task yourself with a wrong answer and confirm it fails; that two-minute habit catches the empty-correct-answer footgun. Duplicate rejection is off by default on text and URL tasks and will not catch a paraphrase.

3. Promote reviewers, not editors, on a capped invite link. Set an expiry and a maximum number of uses, and tell the person in writing that the role can grant up to 20,000 bonus XP per claim, across as many as 1,000 claims in one action, and that you can see every verdict.

4. Partition the queue in a pinned message. By module, by day, or oldest-first versus newest-first. The product will not do it for you, and two people on one undivided queue will duplicate work.

5. Only now consider AI review. If the standard can be written down, the volume is high and you are on Plus or Enterprise, write the prompt as the rejection message you would be comfortable sending, because that is what it becomes. Start on one quest and read the first fifty comments it writes before enabling it anywhere else.

6. Export monthly and work out your own time-to-review. Zealy will not compute it. Subtract each claim's created timestamp from its updated one in the CSV export; that is accurate for claims reviewed once, and re-reviewed claims need their review history. Ten minutes in a spreadsheet tells you whether any of this worked.

The through-line is that "do I need to hire" is nearly always the wrong question, asked one design decision too late. Delegate to a rule first, since it is the only route where the work disappears rather than moves. Delegate to a person second, and be honest with them about the XP power and the collisions. Delegate to a machine last, and only when you can write the standard down. For the wider context, the community management basics module is the companion piece and Zealy's review documentation covers the queue mechanics. And if you have not settled on the tooling yet, our survey of community management software prices the wider category, moderation labour included.