Creating a crowd job takes a single step. You attach a survey template (which defines the task UI and the questions workers will answer) and, optionally, a data set that controls what each worker sees. From there you set a handful of simple options: how many credits a worker earns per accepted answer, how many total accepted answers you want to collect, the window of time during which the job should stay open, and how many different workers are allowed to answer the same item before it's considered covered.
Once created, a job starts out unpublished. Publishing makes it assignable, meaning it becomes visible to eligible workers. From there a job moves through a simple lifecycle: assignable, then paused or unpublished if you take it down, out of tasks once every slot has been filled, and finally finished when it's closed — either by you or automatically. At any point you can check live progress: how many task slots remain and which workers are currently active, right from the job dashboard.
Before publishing to real workers, it's worth running a dry run first: mark the job as a test, list a handful of email addresses that are allowed to see it, and optionally share a private link for testers. A dry-run job behaves identically to a live job in terms of task assignment and answer collection, but it stays invisible to the general worker pool. This is the right way to validate your survey and reward settings without polluting production data.
Workers reach jobs through their own dashboard. Registered workers have accounts where they can check their balance, request payouts, and upload files alongside their answers. Anonymous participants can take part too, through guest sessions that let us track their submission history without requiring them to create an account.
When a worker picks up a task, that task slot is marked as assigned and given a deadline. The worker then sees the survey populated with whichever item they've been assigned. If the worker doesn't submit before the deadline, the slot times out and returns to the pool for someone else to pick up. Workers can also explicitly hand a task back if they change their mind. Either way, the slot becomes available again, so your target number of accepted answers is a bound on completed, accepted work — not on every attempt made along the way.
Submitted answers land in a review queue with a pending status. You can pull a paginated list of every answer for a job, each one including the full submission content, which item the worker was responding to, and metadata like when it was submitted. Any files a worker uploaded as part of their answer are available for review and download alongside it.
For a higher-level view, the same live dashboard used for tracking progress also shows how many answers are pending review, how many have been accepted, how many rejected, and which workers are currently active. In the platform UI this drives a near-real-time job dashboard, refreshing every few seconds while the job is open. For the exact calls behind this, see the API reference at docs.crowdee.ai.
Each pending answer can be accepted or rejected individually. Rejecting an answer lets you attach an optional reason, which is stored and can be shown to the worker as feedback. Rejected answers don't count against your target number of accepted answers, so they effectively free up space for a replacement submission.
Credits only transfer on acceptance. A worker's earnings for a given answer stay unset until that answer is accepted, at which point the credits are applied and the worker's balance is updated accordingly. Credits are set aside as soon as a task is assigned, then either released back if the answer is rejected or transferred to the worker if it's accepted. This reserve-then-settle approach keeps both the job owner and the worker in a consistent state even when a job is paused mid-run.
Once you have a set of accepted answers, you have several downstream options. You can export all answers as JSON or CSV, which is useful for offline analysis, quality audits, or feeding results into an external system. Full details on the export options are in the API reference.
For workflows that stay inside the platform, two shortcuts skip the export step entirely. You can package accepted answers — along with any attached files — directly into a new dataset, ready to be cleaned or verified. Or you can convert textual answers into a new input set that feeds a follow-up crowd job — useful for multi-stage annotation work where one crowd's output becomes the next crowd's input.
Finally, you can clone a job's configuration into a new draft at any time. The clone starts out unpublished and inherits the survey, data set, reward settings, and all other configuration — but not the answers already collected. Cloning is the fastest way to run a repeat batch with tweaked parameters.
Share this article:
