> For the complete documentation index, see [llms.txt](https://docs.pulselabs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pulselabs.ai/participants/participant-recruitment-and-management.md). # Participant Funnel and Management Every participant moves through a structured funnel — Recruited → Verified → Enrolled — before they can participate in your study. This page covers the verification steps you can configure, managing the funnel, and the built-in messaging channel for communicating with participants. ## How the funnel works Every participant in Pulse Labs moves through a structured funnel before they can participate in your study. The funnel ensures participants meet your criteria and have completed any required verification steps before they access your capture methods. The stages are: **Recruited → Verified → Enrolled** ### Stage 1: Recruited The participant has been introduced to your study but hasn't completed any verification steps yet — either through a direct email invitation, a CSV upload, a panel listing, or an external recruitment link. ### Stage 2: Verified The participant has passed all verification steps you've configured (see below). They've met your screening criteria and are confirmed eligible. ### Stage 3: Enrolled The participant is verified and actively assigned to capture methods within your project. They can now access surveys and evaluation tasks. You can see how many participants are at each stage from the project dashboard's **Recruitment** and **Enrolled** tabs. ## Verifications You configure which verification steps are required for your study. Participants must complete every enabled step before they move from Invited to Verified. All steps are optional — enable only the ones relevant to your research. ### Location verification Confirms the participant is in (or not in) a specific geographic area. **Two location modes:** * **Current location** — Uses real-time location data to verify where the participant is right now. Useful for studies that require participants to be in a specific location during the research. * **Permanent address** — Verifies the participant's home address. Useful for studies targeting specific regional markets or demographics. **Supports complex criteria:** You can set rules like "within the United States but not in Texas" or target specific cities, states, or countries. ### Identity verification Confirms the participant is who they say they are using third-party identity verification through **Persona**. **How it works** 1. The participant takes a photo of their government-issued ID. 2. They take a selfie from multiple angles. 3. Persona matches the ID photo to the selfie and verifies the ID information. 4. Results are returned automatically. **Good to know** Many participants on the Pulse Voices panel are already ID-verified. Newly invited participants will complete this step if required by your study. **When to use it** * As an escalation when participants fail passive checks. * High-stakes research requiring verified identities. * Regulated industries that require participant authentication. ### Phone verification Confirms the participant controls the phone number provided via a one-time password (OTP) using a third-party identity verification through **Persona**. **How it works** 1. The participant enters their phone number capable of receiving text messages. 2. A one-time code is sent to the participant at that number. 3. The participant enters the code into their app. 4. If the code matches they are phone-verified. **Good to know** Many participants on the Pulse Voices panel are already phone-verified. Newly invited participants will complete this step if required by your study. **When to use it** * As an escalation when participants fail passive checks. * When phone communication is critical to workflow. * Regulated industries that require participant authentication. ### Document signature Requires participants to review and digitally sign documents before proceeding. These are typically consent forms, NDAs, or participation agreements. **How it works** 1. Documents must be shared to the Pulse Labs team to review and port into the e-signature platform. 2. Participants review and sign them digitally via the integrated e-signature system. 3. Signed documents are reported as completed tasks on the participant dashboard. **When to use it** * Your IRB or legal team requires signed consent. * Participants will be exposed to confidential information. * Regulatory requirements mandate documented consent. ## Managing the funnel ### Approving and rejecting participants For verification steps that require **manual** review (screener surveys with manual review mode, tech verification photos), you'll see pending participants in the Recruitment tab. For each participant you can: * **Approve** — Move them to the next verification step (or to Enrolled if this was the last step). * **Reject** — Remove them from the study. ### Bulk operations For large studies, you can: * **Bulk invite** — Upload a CSV/Excel file with email addresses to invite many participants at once. * **Bulk enroll** — Enroll multiple approved participants simultaneously. ### Monitoring progress The Recruitment tab shows each participant's current position in the funnel and which verification steps they've completed or are pending. Use the Enrolled tab to see your fully qualified, active participant pool. *** ## Communicating with participants Pulse Labs gives every project a built-in two-way messaging channel between the research team and participants. All study communication happens inside the platform, so it's centralized, auditable, and available to anyone on the project team — not buried in one researcher's email inbox. Participants access messages through the Pulse Voices web app and mobile app. Researchers access them through the project's **Messaging** tab and from contextual actions across the platform. ### How messaging threads work Each participant has **one messaging thread per project** they're invited to or enrolled in. The thread opens automatically when the participant is invited to a screener or, if there's no screener, when they're invited to join the project. The first message in a thread is the screener invitation (as a marketing card) or the project join link, so the thread always has context from the moment the participant becomes aware of the study. Threads are **1:1 between the participant and the project**, not between the participant and an individual researcher. Any team member with Editor or Manager access on the project can read and reply to the thread. From the participant's side, messages appear to come from the project itself rather than from a named person — so multiple researchers can share the workload without confusing the participant. If you want a participant to know specifically who they're talking to (for example, in a longitudinal study where rapport matters), sign your messages by typing your name in the body. There's no automatic "sent by" attribution rendered to participants in this release. ### What appears in a thread Both researchers and participants see the same content in a thread, and in chronological order. | Message type | Examples | | ------------------- | ----------------------------------------------------------------------- | | Researcher messages | Direct messages from the project team to the participant | | Participant replies | Messages the participant sends back | | Automated messages | New task notifications, survey invitations | | System notices | Indication that a conversation has been escalated to Pulse Labs Support | Automated messages render with a quieter visual treatment so they're easy to distinguish from messages typed by a researcher. Links inside any message — survey URLs, task links, etc. — render with inline previews automatically. ### Sending messages as a researcher You can start a message from several places on the platform. The compose experience is the same in each case — only the pre-selected recipients differ. | Entry point | What happens | | ----------------------------------- | ----------------------------------------------------------- | | **Messaging** tab | Open compose with a participant picker (single or multiple) | | **Recruitment** tab — row action | Compose pre-filled with that participant | | **Recruitment** tab — bulk select | Compose pre-filled with all selected participants | | **Enrolled** tab | Same as Recruitment — single row or bulk select | | **Data** tab — viewing a submission | Compose pre-filled with that participant | | Participant profile panel | Compose pre-filled with that participant | #### Bulk messages When you select participants via checkboxes in the Recruitment or Enrolled table, only the rows currently loaded are selected. If your active filters match more participants than are loaded, you'll see a prompt: **"X selected. Select all Y matching participants?"** Choosing that selects every participant matching your filter, even rows you haven't scrolled to. A bulk send creates an individual 1:1 message in each recipient's project thread. From the participant's side, it looks like a personal message — they don't see that it was sent to a group. #### Formatting The composer supports basic rich text: **bold**, *italic*, underline, strikethrough, ordered and unordered lists, and links. Tables can't be built in the composer, but if you paste table-formatted content from a spreadsheet, the formatting is preserved. ### Email notifications When a new message arrives — researcher-sent or automated — the participant receives an email letting them know. The email prompts them to open the Pulse Voices app to read and reply; participants can't reply directly to the email. Email is the only notification channel in this release. ### Participant-initiated messages Once a thread is open, participants can message the research team at any time without initiating a separate "Contact Researcher" flow. Anything they send appears in the project's Messaging tab and is visible to every team member on the project. ### Escalating to Pulse Labs Support If a conversation involves a technical or platform issue — login problems, app crashes, recording failures, etc. — researchers can hand it off to Pulse Labs Support without leaving the thread. To escalate: 1. Open the conversation and select **Send to Support** in the composer area. 2. Choose an issue **category** and **sub-code** from the popup window. The available options are scoped to issue types that qualify for support intervention. 3. Submit the escalation. When you submit, three things happen: * A HubSpot ticket is created containing the full thread history up to that point, the participant's identifier, the project, and the category and sub-code you selected. * The participant receives an email letting them know their conversation has been forwarded to support and asking for any additional context that might help (screenshots, device and OS version, app version, etc.). * An automated message is posted in the thread itself, indicating the conversation was escalated. The participant sees the notice; researchers also see a link to the HubSpot ticket. The thread remains open after escalation. You can keep messaging the participant normally, and you can escalate again later if a new issue comes up — each subsequent ticket includes the full thread history, including any prior escalation markers. ### Tips * **Sign your messages** if it matters that the participant knows who's talking to them. Otherwise, expect them to read the project as a single voice. * **Watch for participant replies in the Messaging tab.** There's no per-researcher inbox or assignment, so anyone on the team can pick up a reply. * **Don't escalate everything to Support.** The category and sub-code list is narrow on purpose. For research-related questions or clarifications, just reply in the thread. * **Use bulk send for reminders and announcements**, not for personal-feeling outreach. The "Select all matching" prompt is designed to help you reach an entire filtered segment in one action. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.pulselabs.ai/participants/participant-recruitment-and-management.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.