{"id":46760,"plugin_id":"plugin_asdk_app_6abed98cf9b08191b2c40cc2c305459b","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:31:01.860Z","digest":"1f0f0e08a7b9a156025c8afc7f40bd498868afb049efb3a25d178587ac2f746c","against":null,"payload":{"description":"Use with the Great Question tools when sourcing candidates for a study, shortlisting them, or sending screener invitations. How we recruit from our panel without over-messaging people or inviting the wrong ones.","included_files":[],"name":"recruiting-participants","skill_md_contents":"---\nname: recruiting-participants\ndescription: \"Use with the Great Question tools when sourcing candidates for a study, shortlisting them, or sending screener invitations. How we recruit from our panel without over-messaging people or inviting the wrong ones.\"\n---\n\n# Recruiting Participants\n\nIf your Great Question workspace has its own skill for this, follow that instead.\n\nUse this when finding candidates for a study, shortlisting them, or inviting them to a screener. Recruitment spends panel goodwill, and that budget is finite.\n\n## Find the right pool first\n\n- Start from a saved segment when one fits. Segments already encode eligibility our filters don't know about.\n- When no segment fits, search the panel on the criteria that actually matter for the study, and say which criteria you used.\n- Look at how many candidates match before you propose a batch. A pool barely larger than the target means the screener will not have room to disqualify anyone.\n\n## Sizing a batch\n\n- Invite three to five times your target participant count. Most screener recipients never respond, and some who respond won't qualify.\n- Prefer one well-sized send over a series of top-ups. Repeated small sends to the same segment read as spam.\n- If the pool can't support the target, say so before sending rather than inviting everyone available and hoping.\n\n## Respect the panel\n\n- Don't invite anyone who was invited to another study in the last 30 days unless the researcher explicitly overrides it.\n- Don't invite people who already participated in a closely related study, their responses are no longer naive. Shortlisting and sending filter differently, and the difference matters.\n- Shortlisting reports back who was already on the study, unreachable, ineligible, or outside your team access. Sending only filters unreachable people, it will not tell you someone is a repeat or ineligible. Don't rely on the send step to catch a mistake in who you chose.\n- Treat those filters as a backstop, not as your own. Surface who you intended to invite and who was dropped, rather than letting skips pass silently.\n\n## Sending\n\n- Always show the researcher the actual recipient count and the message that will go out, and get an explicit yes immediately before sending.\n- A researcher approving a shortlist has not approved a send. Ask again at the moment of sending.\n- Treat an ambiguous answer as a question to clarify, not as approval.\n- Both shortlisting and sending cap out at 500 candidates per batch. Split anything larger, and tell the researcher you're splitting it so the batches aren't a surprise.\n- If something fails partway through, stop. Report what was shortlisted, whether anything was sent, and the current state. Don't retry a send.\n\n## Guardrails\n\n- Never send to a list you assembled outside the study's segment or search without saying so explicitly.\n- Never work around a candidate the platform declined to contact. That flag exists for a reason, surface it instead.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}