Recruiting User Research Participants on Autopilot

Build an always-on pipeline that finds, screens and schedules interview participants from your customer base so weekly discovery never stalls.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The most common reason product teams abandon weekly customer interviews is not a lack of desire, it is recruitment friction. Someone has to find the right people, send emails, follow up, schedule calls, and do it all over again next week. When that work depends on one person, the cadence slips to biweekly, then monthly, then quietly dies. Automating participant recruitment turns a manual, repetitive chore into a system that runs in the background, surfacing qualified customers and putting them on your calendar without anyone sourcing them by hand.

In Continuous Discovery Habits, the bar is, at a minimum, weekly touch points with customers by the team building the product, and those interviews fuel everything else: building opportunity solution trees, mapping customer opportunities and running assumption tests. Practitioner notes on the book reduce the logistics to one instruction, book weekly interviews on repeat. The aim is regular contact with users throughout the product development cycle, not just during research sprints. The recruitment pipeline is the infrastructure that makes that contact reliable rather than heroic. Without it, discovery becomes a project with a start and end date. With it, interviews become as automatic as your daily standup.

Concretely, this skill teaches you to design and deploy a pipeline with four components: a behavioral trigger (the customer does something in your product that signals relevance), a screening filter (they match your target segment, are not excluded for a business reason, and have not been contacted recently), a recruitment message (in-app prompt, email, or both), and a scheduling mechanism (a self-service link that books time on your team's research calendar). It also covers the supplementary channels you need when product triggers cannot reach the right people, which is common in enterprise B2B and regulated settings.

The artifact you produce is a documented recruitment pipeline, a diagram or spec showing the trigger, filter, message and scheduling flow, plus a working implementation in your existing tooling. Once live, the pipeline should consistently deliver enough participants that your team rarely has to source an interviewee by hand again.

How It Works

Automated recruitment works by intercepting customers at moments of high relevance and converting that relevance into a scheduled conversation. The core insight is that recruiting user research participants is a conversion funnel, and it responds to the same levers as any other funnel: targeting, timing, messaging and friction reduction.

The trigger identifies the moment a customer becomes relevant to your current research question. This is usually a product event: completing onboarding, hitting a usage milestone, encountering an error, upgrading or downgrading, or using the specific feature you are investigating. Keep the trigger as close as possible to the experience you want to discuss, because recency improves both willingness to talk and recall quality. A customer who abandoned checkout moments ago can tell you exactly what happened; one contacted weeks later gives you a reconstructed narrative.

The filter is your screener. At minimum, it enforces a cooldown so no customer is contacted for research too often, checks that the customer is not in an active sales cycle or support escalation, and verifies they match the segment you are studying. Filters are where cross-functional agreements live: they encode the rules your go-to-market, legal and compliance teams need you to respect.

The message is the recruitment touchpoint itself: an in-app modal, a triggered email or a banner. Effective messages reference the specific action the customer just took ('We noticed you just set up your first dashboard...'), frame the ask as helping improve the product rather than doing a favor, and make a short time commitment explicit. Contextual messages sent right after a relevant action generally beat cold blasts to a customer list, but measure your own rates rather than borrowing someone else's benchmarks.

The scheduler removes the final friction point. Instead of a back-and-forth email thread, the message links to a self-service booking page with pre-configured slots. The booking should automatically send a calendar invite, reminders and a context note to the interviewer explaining which trigger fired and which segment the participant belongs to, so the interviewer can prepare.

Product triggers are the primary channel, not the only one. Where the product cannot reach the people you need, feed the same filter and scheduler from other channels: introductions from customer success managers, a research opt-in panel collected at signup or in settings, follow-ups on closed support tickets, and posts in your customer community. This matters most in the contexts where one review argues weekly interviewing is hardest: regulated industries, enterprise B2B settings with limited user access, and organizations under intense delivery pressure. In B2B, the account owner often controls access, so add a notification and veto step for the account's CSM. In regulated settings, restrict the pool to customers who have given explicit research consent and keep recordings and notes in approved tools.

The system works sustainably because it decouples recruitment from any single person's effort. A product manager leaving, a busy sprint or a holiday week does not break the pipeline; it keeps running. That is what turns regular contact with users throughout the product development cycle from an intention into a default. And because it is event-driven, it adapts: as you shift research questions, you update the trigger events, and the pipeline starts surfacing a different slice of customers.

Step-by-Step Guide

Step 1: Define Your Recruitment Criteria and Weekly Target

Start by specifying exactly who you need to talk to and how many conversations per week your team needs. Review your current opportunity solution tree or research plan and write down a few qualifying attributes: segment (for example, 'free-tier users in their first two weeks'), behavior (for example, 'created at least one project') and exclusions (for example, 'enterprise accounts managed by sales'). Torres's floor is interviewing at least one customer per week, so set a weekly target at or above that. Because not everyone who books will show up, schedule more slots than your target, for example double it until you know your own show rate.

Document these criteria in a shared doc that your PM, designer and engineer can all reference and update as research questions evolve.

Pro tip: Don't over-narrow your criteria at the start. A pipeline that targets recent free users who used one feature repeatedly and belong to one persona will have almost no candidates. Start broad, with one segment and one recency filter, and tighten only after you see response volume.

Step 2: Identify and Instrument Behavioral Triggers

Choose a small number of product events that signal a customer is experiencing something relevant to your current research question, and verify those events are tracked in your analytics or event system. Good triggers are moments of high engagement or friction: completing a key workflow, using a feature for the first time, encountering a known pain point, or reaching a usage threshold. Confirm the events fire reliably and carry the properties you need for screening, such as user ID, account plan and signup date; if they do not exist yet, adding them is usually a lightweight engineering task. Test the trigger by having a teammate perform the action and confirming the event reaches your pipeline promptly.

Latency matters: if events take a day to propagate, your recruitment message arrives too late to feel contextual.

Pro tip: The highest-converting trigger is usually a 'moment of reflection', right after a customer completes a meaningful task (finishing onboarding, publishing their first item, exporting a report). They're still engaged, still thinking about the experience, and far more likely to say yes to a short conversation than someone you catch mid-workflow.

Step 3: Build Screening and Cooldown Filters

Create the logic layer that sits between your trigger and your recruitment message. For every candidate it answers three questions: does this person match the segment criteria, have they been contacted for research within your cooldown window (for example, 60-90 days), and are they excluded for a business reason such as an active sales deal, an open support escalation or a research opt-out? Implement this as a filter step in your messaging tool or a segment condition in your analytics platform, backed by a 'last research contact' attribute that updates every time someone enters the pipeline. Meet with your customer success and sales leads to agree on exclusion rules; skipping this almost always causes friction when a sales rep discovers their prospect got a research email mid-negotiation.

In regulated settings, add a consent check so only customers who have opted in to research pass, and confirm the rules with legal or compliance before launch.

Pro tip: Create a shared 'research contact log', a simple spreadsheet or CRM custom field, that records every customer who enters the recruitment pipeline and when. This is your source of truth for cooldown enforcement and prevents the 'wait, we already talked to them last month' problem.

Step 4: Craft Your Recruitment Message

Write the message that qualified candidates will receive. The most effective recruitment messages are short, contextual (they reference what the customer just did), transparent about the ask (how long, what format) and explicit about the value exchange (helping shape the product, a gift card or early access to a feature; pick one). Write two variants: one for in-app delivery shown right after the trigger event, and one for email sent soon after the trigger, with the in-app version cut to a couple of sentences and a single button. For email, use a plain-text style from a real person's name (the PM or designer), not a marketing template, with one prominent link to your scheduling page.

Subject lines that reference the customer's specific action ('Quick question about the dashboard you just built') feel more relevant than generic ones, so test them if your tool supports it.

Pro tip: Never say 'user research' or 'interview' in your recruitment message; these words trigger anxiety. Say 'a quick conversation about your experience with [specific feature]' instead. You're asking for a chat, not putting them in a lab.

Step 5: Set Up Self-Service Scheduling

Configure your scheduling tool with dedicated research interview slots under a friendly event type such as 'Product Feedback Chat', with a fixed short duration and buffer time between slots. Spread slots across different days and times to accommodate time zones. Enable automatic calendar invites with a video call link embedded, and a confirmation email that restates what the conversation is about and how long it will take. Configure reminders, for example one the day before and one shortly before the call.

Most importantly, pass the trigger event and segment data through a hidden field or URL parameter in the scheduling link, so the interviewer sees which trigger brought this person in and can prepare without a separate lookup.

Pro tip: Set your scheduling page to auto-close once bookings reach a cap, for example twice your weekly interview target. This prevents over-recruitment and means you don't have to monitor flow by hand. Most scheduling tools support a maximum-bookings-per-week setting.

Step 6: Connect the Pipeline End-to-End and Test

Wire the trigger, filter, message and scheduler into a single automated flow, usually a workflow in your messaging platform that listens for the trigger event, applies the filter conditions and sends the message with the scheduling link. Run three end-to-end tests with internal accounts: one that should qualify (it receives the message and can book), one that should be blocked by the cooldown, and one that should be blocked by segment. Check that the scheduling link works, the calendar invite fires and the reminders go out. Note any lag between the trigger and message delivery, decide whether it is acceptable, and fix broken handoffs before going live.

Add a simple alert, even a chat notification, that fires every time someone books a research slot so the team sees pipeline health from day one.

Pro tip: During testing, use a personal email address that isn't connected to your internal tools so you experience the flow exactly as a customer would, including inbox rendering, spam filter behavior and calendar invite formatting.

Step 7: Launch to a Small Segment and Calibrate

Don't launch to your entire user base on day one; start with a slice of eligible customers or a single trigger event to calibrate volume. For the first couple of weeks, track each stage: how many candidates enter, how many pass the filter, how many open and click, how many book, and how many show up. If too few candidates enter, your trigger is too narrow or your filter too aggressive; if plenty enter but few book, your message or scheduling flow has friction; if many book but few show, your reminders or incentive need work. Adjust one variable at a time and give each change a full week of data before judging it.

Once the pipeline reliably delivers your weekly target, expand to the full eligible population and additional trigger events.

Pro tip: Track your trigger-to-booked conversion rate as the single health metric for the pipeline. Set your own baseline over the first few weeks; a falling rate usually means your message or targeting needs work, while a steady surplus of bookings means you can afford tighter filters.

Step 8: Establish the Weekly Review and Rotation Ritual

Automation doesn't mean set and forget, so hold a short weekly review, ideally alongside your product trio sync, of pipeline health and upcoming bookings. Check how many interviews are booked this week, whether cancellations or no-shows need backfilling, and whether the participant mix matches your current research focus or has drifted toward a segment you've already saturated. Share the stage-by-stage numbers where the whole trio can see them, so anyone can flag a drop early. Whenever your research focus moves, rotate the trigger events to match: if you've shifted from onboarding to retention, swap the 'completed onboarding' trigger for an inactivity trigger and update the message.

This keeps the pipeline aligned with your opportunity solution tree instead of delivering the same type of participant long after your focus has moved on.

Pro tip: Keep a running 'participant profile log' that records each interviewee's segment, trigger and key takeaway. After a batch of interviews, review it for coverage gaps; if most participants are power users and your research question is about activation, your triggers are misaligned.

Best Practices

• Enforce a hard cooldown between research contacts for any individual customer, for example 60 days. Without it, your most engaged users, the ones most likely to respond, get contacted repeatedly and either stop responding or become 'professional participants'. If your eligible population is small, lengthen the cooldown and add other recruitment channels rather than re-contacting the same people.
• Co-create your exclusion rules with customer success and sales before launching the pipeline. The most common internal conflict is a research email arriving during an active sales negotiation or a sensitive support case, so keep a shared, living list of exclusions (for example, accounts with an open renewal or customers with an active high-severity support ticket) and review it quarterly. One angry escalation from a sales leader can get the whole pipeline shut down.
• Use contextual, trigger-specific messaging rather than a generic research recruitment template. A message that says 'We noticed you just exported your first report, we'd love a few minutes to hear how that went' gives the customer a concrete reason to reply, where 'We're looking for feedback on our product' does not. This means maintaining one message variant per trigger event, which is worth the extra setup.
• Always pass trigger and segment metadata through to the interviewer via the scheduling tool's custom fields or confirmation email. If the interviewer doesn't know why a participant was recruited, they spend the opening of every call re-establishing context the pipeline already captured. This transfer is what turns automated recruitment from a scheduling convenience into research infrastructure.
• Cap weekly bookings slightly above your interview target and auto-close scheduling when the cap is hit. Over-recruitment creates interviewer burnout and scheduling chaos, while a modest buffer absorbs normal no-shows. Adjust the cap once you know your own show rate.
• Rotate your trigger events whenever your research questions change, and check alignment in every weekly review. The most common failure mode of automated recruitment is a pipeline still running an old trigger while the team has moved to a different area of the product. Tie trigger rotation to movement on your opportunity solution tree so the system follows the research.
• Add non-product channels where triggers can't reach the right people. In enterprise B2B and regulated industries, where one review notes weekly interviewing is harder because user access is limited, route CSM introductions, a consented research panel and support follow-ups through the same screener and scheduler. That keeps one set of rules and one calendar regardless of where a participant came from.

Common Mistakes

• Building the pipeline before agreeing on contact rules with sales and customer success: You launch, it works, and a few weeks later a sales leader escalates because a strategic prospect received a 'research survey' during contract negotiation, and the pipeline gets shut down. Restarting it then requires executive sponsorship you didn't need before. Meet with CS and sales leads before writing a single automation rule, bring a draft exclusion list and let them add to it. A short meeting up front saves months of political recovery.
• Recruiting from a static customer list instead of using real-time behavioral triggers: A one-off export of everyone who used a feature last quarter fails twice: the experience is no longer fresh in their memory, and you select for people who answer email rather than people who had the relevant experience recently. Recruit within minutes or hours of the relevant behavior instead. If your tooling can't support real-time triggers, a daily batch that picks up yesterday's events is still far better than a one-time list pull.
• Setting triggers too narrowly and then wondering why the pipeline delivers zero candidates: Stacking plan, persona, signup recency, repeat feature use and day-of-week conditions shrinks the eligible population with every clause until nothing is left. Start with one behavioral trigger and one segment filter, watch volume for a week, and add conditions one at a time only when you have more candidates than you need. A week with zero candidates almost always means your filters compounded into an empty set, not that your users went quiet.
• Using marketing-style email templates instead of plain-text personal messages: Messages with branded headers, multiple calls to action and stock photos get mentally filed as promotional and ignored, and they are more likely to land in spam. The signal you want is 'a real person from the product team wants to talk to you', which a plain-text email from a named PM or designer conveys best. In-app messages are the exception, since a clean branded modal fits the context of someone already using your product.
• Not tracking show rates and failing to notice the pipeline is leaking at the last mile: A team sees a full calendar of bookings, assumes the pipeline is healthy, and compensates for empty calls with manual recruiting instead of fixing attendance. Low show rates usually trace to missing reminders, too long a gap between booking and interview, or a confirmation that didn't restate the time, duration and call link. Diagnose which step the drop happens at (never confirmed, confirmed but absent, or last-minute cancellation) and fix that stage.
• Running the same triggers for months without rotating to match evolving research questions: The pipeline becomes a participant factory delivering the same persona every week after the team has moved to a new area, interviews feel less useful, and the team concludes continuous interviews don't work for them. The root cause is stale targeting, not the interview practice. When your opportunity solution tree shifts to a new branch, update your triggers the same week so the pipeline follows the research.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Continuous Discovery Habits

Related Skills

• Building Opportunity Solution Trees
• Conducting Weekly Customer Interviews
• Defining Product Outcomes Over Outputs
• Mapping and Prioritizing Customer Opportunities
• Running Assumption Tests
• Story Mapping Customer Experiences
• Comparing Solutions with Compare-and-Contrast Decisions

Sources

• Everyone Can Do Continuous Discovery - Even You!
• Continuous Discovery Habits: Discover Products that Create
• Continuous Discovery: Talk to Users Every Week (Guide)
• Continuous Discovery Habits by Teresa Torres | Axis Seven Library

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.