{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-05T09:54:29.026Z"},"content":[{"type":"documentation","id":"14d191ad-a9d9-41a8-854b-5a683d4ba1ba","slug":"recruiting-participants-communities-events","title":"Recruiting Research Participants from Communities, User Groups and Events","url":"https://www.koji.so/docs/recruiting-participants-communities-events","summary":"Communities, user groups, and events are the fastest source of research participants and the most biased. They deliver highly engaged, articulate, product-literate people at near-zero recruiting cost, which makes them excellent for depth and dangerous for prevalence — community members are systematically your most invested users. The channel-specific mechanics that matter are permission from moderators, disclosure of who you are, incentive norms that differ sharply by channel, and asynchronous capture at events where scheduling is impossible. The methodological fix is not to avoid these channels but to label the frame, quota against your owned panel, and never report a community-recruited percentage as a customer-base percentage. Koji makes event and community recruiting practical because an AI-moderated interview link works at any hour without a scheduled moderator, so a conference conversation converts into a full interview that evening rather than a calendar invite that never gets booked.","content":"**Communities, user groups, and conferences are the cheapest participant source you have, and the most biased. Use them for depth, never for prevalence, and always record which channel each participant came from.** A Discord thread can fill twelve interview slots in an afternoon at zero recruiting cost — but the twelve people who answered are, almost by definition, the twelve most invested users you have. That is a fantastic sample for understanding an advanced workflow and a terrible one for estimating how many customers hit a bug.\n\nThis guide is about the channels you do not own outright: other people's communities, industry user groups, meetups, and events. For recruiting inside your own product see [Recruiting from Your Product](/docs/recruiting-from-your-product), and for running a persistent research community of your own see the [MROC guide](/docs/market-research-online-communities-mroc-guide).\n\n## The channels, honestly compared\n\n| Channel | Speed | Cost | Bias risk | Best for |\n|---|---|---|---|---|\n| Your own Slack/Discord community | Hours | Near zero | Very high | Advanced workflows, feature depth, beta feedback |\n| Third-party industry community | Days | Low | High | Competitor switching, category-level attitudes |\n| Regional user groups | 1-2 weeks | Low | Medium-high | Practitioner reality, deployment and admin pain |\n| Meetups | 1-2 weeks | Low | Medium-high | Adjacent roles you cannot reach through your product |\n| Conferences and trade shows | Same day | High (travel) | Medium | Volume, breadth of company types, competitor users |\n| Partner and reseller communities | 2-4 weeks | Medium | Medium | Channel dynamics, implementation and buying process |\n| Open-source repos and issue trackers | Days | Near zero | Very high | Developer-tool research, integration and API work |\n\nTwo patterns are worth reading out of that table. First, the cheapest channels carry the highest bias — the relationship is close to mechanical, because engagement is what makes someone both easy to reach and unrepresentative. Second, conferences are the only channel that delivers **breadth** at speed, which is why they are worth the travel cost despite being the least controllable environment on the list.\n\n## Getting permission without getting banned\n\nThe single most expensive mistake in community recruiting is posting first.\n\n- **Read the rules, then ask a moderator anyway.** Most communities have a stated policy on research and vendor participation. Even where the rules permit it, a short direct message to a moderator explaining who you are, what you are researching, how long it takes, and what participants get converts you from an intruder into a sanctioned guest.\n- **Disclose your affiliation in the post itself.** Not in a bio, not in a follow-up — in the first two lines. Undisclosed vendor research discovered later is the fastest way to lose a community permanently, and community bans are rarely reversed.\n- **Offer the community something back.** An aggregate summary of what you learned, shared publicly in the same channel, is the currency that buys you a second study. Teams that do this get invited back; teams that extract and vanish get one shot.\n- **Post in the right place at the right time.** Most communities have a dedicated channel for surveys and research. Using the main channel instead reads as a lack of respect for the space, whatever your intentions.\n- **Never DM members cold off a member list.** This is the behaviour that gets research programmes banned, and in some jurisdictions it raises direct-marketing questions on top of the etiquette problem.\n\nFor user groups and meetups, the equivalent is the organiser. A five-minute slot at the end of a meeting, offered honestly as \"we are researching X and would love twenty minutes with anyone willing,\" consistently outperforms a table at the back.\n\n## Incentive norms differ sharply by channel\n\nApplying one incentive policy everywhere is a common and costly mistake.\n\n| Channel | What works | What backfires |\n|---|---|---|\n| Your own user community | Early access, direct product-team contact, visible follow-through | Cash, which can read as transactional and sometimes lowers response |\n| Third-party professional community | Standard market-rate incentive, paid promptly | Under-market offers, which read as disrespect for professional time |\n| User groups and meetups | Sponsoring food or venue; small on-the-spot gifts | Individual cash payments, which can compromise the organiser |\n| Conferences | Immediate, small, physical incentives | Promised post-event payments, which have terrible follow-through |\n| Open-source communities | Contributing back; fixing the issue they filed | Money, which frequently reads as inappropriate |\n\nThe unifying rule: in communities built on **reciprocity**, pay in reciprocity. In communities built on **professional exchange**, pay the professional rate. Getting this backwards is more damaging than not recruiting there at all.\n\n## Events: stop scheduling, start capturing\n\nConference recruiting fails for one structural reason. The conversations happen in ninety-second bursts between sessions, and the traditional next step — \"can we get thirty minutes on your calendar next week?\" — has a conversion rate somewhere near the floor. The person is interested now and unreachable later.\n\nThe move that actually works is to **decouple the conversation from the interview**:\n\n1. Have the short conversation. Qualify in one or two questions.\n2. Hand over a link or QR code that opens a full interview the person can complete whenever they like — that evening, on the flight home, the following week.\n3. Let the interview itself do the depth, including follow-up questions.\n\nThis is where an AI moderator changes the arithmetic outright. A researcher at a booth can personally run maybe six interviews across three days. The same researcher can have sixty qualifying conversations and hand out sixty links, and Koji's AI interviewer will run all sixty as voice or text conversations, at whatever hour each person opens them, with real follow-up probing on every open-ended answer. There is no scheduling, no time-zone problem, and no moderator bottleneck — the constraint becomes how many people you can talk to in a hallway, which is the constraint you actually want.\n\nPractical details that raise event conversion:\n\n- Put the QR code on something the person keeps: a sticker, a card, the badge holder.\n- Say how long it takes, out loud, and be accurate.\n- Send the link the same evening as well; people lose cards.\n- Use a distinct study link per event so you can segment results by source later.\n- Ask your channel question as a structured single-choice screener at the start rather than trying to reconstruct provenance afterwards.\n\nThe same pattern works for user groups: present for five minutes, share a link on the group's Slack, and let people respond over the following week rather than trying to book sessions with volunteers.\n\n## Correcting the enthusiast bias\n\nEverything above makes recruiting easier. This section is what keeps the research honest.\n\nCommunity and event participants are not a random sample of your users. They are the people who joined a community, showed up to a meetup, or travelled to a conference — which correlates with tenure, seniority, budget, product literacy, and enthusiasm. They have workarounds for problems that would make an ordinary customer churn silently.\n\nFour corrections, in order of value:\n\n1. **Label the frame in every deliverable.** \"Twelve interviews with members of our user community\" is a true and useful statement. \"Twelve customer interviews\" is neither.\n2. **Cap the channel.** Community-sourced participants should be a quota — often a quarter to a third of a study — with the rest drawn from your product, your CRM, or a panel. See [Recruiting from Your Product](/docs/recruiting-from-your-product) for the counterweight channel.\n3. **Measure the gap instead of assuming it.** Record the source channel as a structured field, then compare the community subgroup against the rest on your key measures. If community members rate a feature 8.1 and product-recruited users rate it 6.2, you have measured your enthusiast bias rather than argued about it — and that 1.9-point gap is itself a finding.\n4. **Never report a community percentage as a customer percentage.** If prevalence is the question, community recruiting is the wrong instrument. Use it to discover *what* the problem is, then size it on a representative sample. If the sample ends up skewed anyway, the [survey weighting guide](/docs/survey-weighting-guide) covers how much of that skew you can actually repair — the honest answer is: less than you would hope.\n\n## Making channel data usable\n\nAll of the above depends on knowing where each participant came from, which is a data-capture problem solved at study design time, not at analysis time.\n\nKoji's [structured questions](/docs/structured-questions-guide) give you six types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — and the practical move is a single_choice screener at the top of the interview capturing source channel, plus a scale question on tenure or usage frequency. Those two fields turn every subsequent analysis into a segmentable one. Because they are machine-readable rather than buried in transcript prose, filtering the enthusiast subgroup out of a finding takes a click rather than a re-read.\n\nA second advantage matters specifically for these channels: community and event participants answer at unpredictable times. Someone opens your link at 11pm in a different time zone, from a conference hotel. A scheduled moderated session cannot serve that; an always-available AI interviewer can, and it still asks the follow-up questions a survey never would. This is the concrete difference between sending community members a SurveyMonkey or Typeform form — which collects flat answers and no probing — and sending them a conversation that adapts to what they say.\n\n## When not to use these channels\n\n- **Prevalence and sizing questions.** Wrong instrument. Use a representative sample.\n- **Anything commercially sensitive.** Public communities are public. Assume screenshots.\n- **Research on churned or dissatisfied users.** They left the community first. This is the single largest blind spot of community recruiting, and it is invisible from inside the community.\n- **Regulated populations** — patients, minors, financial-advice recipients — where consent and eligibility need controls a public thread cannot provide.\n- **When you have burned the community recently.** One study per community per quarter is a reasonable ceiling, and less is often better.\n\n## Related Resources\n\n- [Finding Research Participants](/docs/finding-research-participants) — the full channel landscape\n- [Recruiting from Your Product](/docs/recruiting-from-your-product) — the in-product counterweight to community bias\n- [Recruiting B2B Participants](/docs/recruiting-b2b-participants) — reaching buyers and admins who are not in communities\n- [Market Research Online Communities (MROC) Guide](/docs/market-research-online-communities-mroc-guide) — running a research community you own\n- [User Research Recruitment Email Templates](/docs/user-research-recruitment-email-templates) — wording for the follow-up\n- [Reducing No-Shows](/docs/reducing-no-shows) — why asynchronous capture beats scheduling at events\n- [Structured Questions Guide](/docs/structured-questions-guide) — capturing source channel as a segmentable field\n\n## Frequently asked questions\n\n**Is it okay to recruit research participants from a Slack or Discord community I did not create?**\nOnly with the moderators' permission, obtained before you post. Every established community has either a stated policy on research and promotion or a moderator who will tell you one. Asking first costs a day; posting first can get you and your company banned permanently, and community bans are rarely reversed.\n\n**Why is community recruiting biased?**\nPeople who join and stay active in a product community are systematically your most engaged, most product-literate, and most invested users. They have workarounds for problems that would make an ordinary customer churn, and they know vocabulary your average user does not. That makes them excellent for depth and unreliable for prevalence — never report a community-recruited percentage as a customer-base percentage.\n\n**Should I offer incentives for community recruiting?**\nIt depends on the channel. Paid incentives are expected in third-party panels and professional communities, but in your own user community a cash incentive can look transactional and sometimes reduces response. Early access, a direct line to the product team, and visibly acting on what you heard often outperform money there. In conference and user-group settings, small on-the-spot incentives work better than promised payments.\n\n**How do I run user research at a conference?**\nDo not try to schedule sessions. Have short conversations at the booth or between talks, then hand over a link that lets the person complete a full interview asynchronously that evening or on the flight home. A QR code that opens an AI-moderated voice interview converts a 90-second hallway conversation into a complete, transcribed, analysed interview without either party finding a shared calendar slot.\n\n**How many participants should come from communities?**\nTreat it as a quota, not a total. A common approach is to cap community-sourced participants at a quarter to a third of a study and fill the rest from your product, your CRM, or a panel — then check whether the community-sourced subgroup answered differently. If it did, that gap is your enthusiast bias, measured rather than assumed.\n\n**Can Koji interview participants recruited from a community link?**\nYes. You publish a study and share its link anywhere — a community thread, a QR code on a conference badge, a user-group Slack channel — and Koji's AI interviewer runs the voice or text conversation whenever the participant opens it, asking its own follow-up questions. Structured screener questions at the start let you capture which channel each participant came from so you can segment on it later.","category":"Participant Recruitment","lastModified":"2026-08-02T03:18:07.991801+00:00","metaTitle":"Recruiting Research Participants from Communities & Events","metaDescription":"A channel-by-channel guide to recruiting participants from Slack/Discord communities, user groups, meetups and conferences: how to ask permission, what to offer, and how to handle the enthusiast bias these channels build into your sample.","keywords":["recruiting research participants from communities","community user research recruiting","conference user research","recruit participants slack discord","user group research recruiting","meetup participant recruitment","event intercept research"],"aiSummary":"Communities, user groups, and events are the fastest source of research participants and the most biased. They deliver highly engaged, articulate, product-literate people at near-zero recruiting cost, which makes them excellent for depth and dangerous for prevalence — community members are systematically your most invested users. The channel-specific mechanics that matter are permission from moderators, disclosure of who you are, incentive norms that differ sharply by channel, and asynchronous capture at events where scheduling is impossible. The methodological fix is not to avoid these channels but to label the frame, quota against your owned panel, and never report a community-recruited percentage as a customer-base percentage. Koji makes event and community recruiting practical because an AI-moderated interview link works at any hour without a scheduled moderator, so a conference conversation converts into a full interview that evening rather than a calendar invite that never gets booked.","aiPrerequisites":["A defined research question and target participant profile","Familiarity with your organisation's incentive and disclosure policy"],"aiLearningOutcomes":["Choose the right community or event channel for a given research question","Approach moderators and community owners without getting banned","Set incentives appropriate to each channel's norms","Run event intercepts that convert into completed interviews","Diagnose and correct the enthusiast bias these channels introduce","Decide when community recruiting is the wrong choice entirely"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}