sales-skills/sales-respondent

Respondent Platform Help

Respondent (respondent.io) is a participant-recruitment marketplace — it recruits, screens, schedules, and pays real research participants from a 4M+ verified panel (150+ countries), with a strength in B2B / hard-to-reach professional audiences (phone + work-email verified; <1% fraud, ~95% show rate per Respondent). Incentives are paid via Tremendous.

Its place in the landscape is recruit-only: you run the interview in your own tool (Zoom/Meet) and keep findings in your own repository. Direct twin: User Interviews. Contrast the recruit+run+repository suite Great Question (/sales-great-question).

Not respond.io — that's a separate chat/messaging platform with a different API. This skill is about respondent.io (research recruitment).

Two things to say almost every time:

• Real people to talk to ≠ demand. Recruiting real B2B users for interviews is a strong signal (the "talk to 10 users" rung) — but a recruited participant saying "I'd pay" is still not a purchase. Keep the why/objections/language; take the go/no-go to a real behavior test (/sales-idea-validation).
• Total cost is recruit fee + incentive (+ ~5% fee) per participant, not the sticker per-session price. Present all pricing as best-effort and point to respondent.io/pricing.

Step 1 — Gather context

If references/learnings.md exists, read it first for accumulated platform knowledge.

Ask only what you can't infer:

1. What do you need?
   • A) Recruit / screen — targeting, screener design, qualifying the right people, quotas
   • B) Scheduling / no-shows — booking, reminders, over-recruiting, marking no-show vs attended
   • C) Incentives / payouts — setting incentives, marking attended, triggering Tremendous payout
   • D) Automate / integrate — the Partner API, webhooks, embedding recruitment in your product
   • E) Choose / price — pay-as-you-go vs credit bundle vs large volume; Respondent vs a peer
2. B2B/professional or consumer audience? (Respondent's edge is B2B — that shapes screener + incentive.)

Skip-ahead: if the user wants to compare research tools across the market or the validate-before-building method, that's /sales-idea-validation — route in Step 2.

Step 2 — Route or answer directly

| If the user's question is about… | Route to | |---|---| | Comparing research/recruitment/idea tools across the market, or the validate-before-building method | /sales-idea-validation {question} | | An all-in-one recruit + run + repository research suite (not recruit-only) | /sales-great-question {question} | | A pure AI-moderated real-human interview tool (the interview is run for you, self-serve API) | /sales-userintuition {question} | | Running a real behavior demand test (smoke-test page, waitlist, pre-sale) after research | /sales-idea-validation or /sales-funnel {question} | | Analyzing existing NPS/CSAT/VoC feedback (post-launch, not new recruits) | /sales-customer-feedback {question} |

When routing, give the exact command: "This is a {domain} question — run: /sales-idea-validation {original question}"

Otherwise, answer Respondent-specific questions using Step 3.

Step 3 — Respondent reference

Read references/platform-guide.md for the full reference — the capability/automation-surface table (API vs webhook vs UI-only), best-effort pricing/plan gates, the Project → Screener → Response → Participant data model, integrations, and quick-start recipes (create+screen+publish, webhook recruit pipeline, reconcile poll). Read references/respondent-api-reference.md for the verbatim API surface (two-header auth, base URLs, rate limits, full endpoint catalog, webhooks). Answer using only the relevant section — don't dump the full reference.

Step 4 — Actionable guidance

• Say the caveat: recruiting real users is not demand. Whatever the user asks, make explicit that Respondent gets real people on the call (a strong signal — genuine reasoning/objections/language) but a recruited "I'd pay" is not observed demand. Keep the why; take the go/no-go to a real behavior test (pre-sale, smoke test) → /sales-idea-validation.
• Attack no-shows directly — it's the #1 researcher complaint. Tell the user to over-recruit (invite more than the target), lean on automated reminders + calendar/Zoom integration, and mark no-shows (Mark as no-show) so they don't get paid. Respondent cites ~95% show rate — plan for the other ~5%.
• Fix "participants don't fit the brief" with screener design, not the panel. Write behavior-based screener questions (ask about the last time they did X, not "are you a good fit"), add a hidden disqualifier and skip logic, avoid leading/obvious-answer questions, and use quotas to balance the sample. Use the review / report / hide actions on bad applicants (Report participant).
• Budget the true cost. Total per participant = recruit fee (~$40 PAYG / ~$34 bundle, min ~63) + the incentive you set (B2B often $50–$150/hr) + ~5% fee. Default to unmoderated (~-38%) where the method allows to cut cost. Present all figures as best-effort — confirm at respondent.io/pricing.
• Payouts are researcher-controlled and gated on attendance. A participant is paid only after you Mark as attended then Trigger manual payout (via Tremendous, typically 7–10 business days). For automation, wire "attended → pay" but keep the no-show path so you never auto-pay an absent person.
• The API is a partner/embed API — provisioned, two-header auth. Credentials are Client ID + Client Secret sent as x-api-key + x-api-secret (not Bearer), requested via the Quickstart + a demo-video checklist (no instant self-serve key). Build against staging first (test participants are staging-only). Verify the webhook signature/HMAC and event-type names on the live Webhooks Overview page (they're not on the fetchable docs) and add a status-filtered reconcile poll since retry behavior isn't documented.

If you discover a gotcha or tip not in references/learnings.md, append it there with today's date.

Gotchas

Best-effort from research (2026-07) — pricing (~$40/session PAYG, ~$34 bundle min ~63, unmoderated ~-38%, ~5% fee), panel size ("4M+"), the two-header API, and webhook specifics all move; verify at respondent.io/pricing and developers.respondent.io.

• respondent.io ≠ respond.io. Different companies. respond.io is chat/messaging with a Bearer API and heavy Zapier presence — don't apply its docs here. Respondent uses x-api-key + x-api-secret.
• Recruit ≠ demand. Real interviews reveal the why, but a recruited "I'd pay" is not a purchase — the go/no-go belongs to a real behavior test.
• No-shows are the top researcher-side complaint. ~95% show rate means ~1 in 20 doesn't appear — over-recruit, use reminders, and mark no-shows so you don't pay them.
• "Participants don't fit the brief" happens on any incentivized panel. It's a screener-design problem, not a bad panel — behavior-based questions, hidden disqualifiers, skip logic, and quotas fix it. Report/hide off-brief applicants.
• Cost is easy to under-budget. The per-session price is only the recruit fee — the incentive (often $50–$150/hr for B2B) and ~5% fee are on top. Surveys are custom-priced only.
• Payouts are manual and researcher-controlled. Mark attended → trigger payout (Tremendous, ~7–10 business days). If you forget, the participant isn't paid — a frequent participant-side complaint.
• The API is partner-provisioned, not self-serve. You request Client ID/Secret (demo-video checklist); no instant key. Webhook HMAC/retry specifics aren't on the public pages — verify live and reconcile with polling.
• Reviewers flag a confusing UI and variable support. Set expectations; the strength is panel quality + B2B reach, not polish.

Related skills

• /sales-idea-validation — The validate-before-building method + the full research/recruitment/validator tool landscape (a research "yes" is not demand). Install: npx skills add sales-skills/sales --skill sales-idea-validation -a claude-code
• /sales-great-question — The all-in-one recruit + run + repository suite (Respondent is recruit-only; Great Question also runs the study and stores it). Install: npx skills add sales-skills/sales --skill sales-great-question -a claude-code
• /sales-prolific — Prolific: the developer-native online research panel peer — recruit + screen + pay vetted participants at scale for surveys, online tasks, and AI human-data collection via a self-serve public REST API (instant Token key) + webhooks + MCP + CLI. Reach for it over Respondent for broad/representative online samples and a programmatic pipeline (Respondent's edge is hard-to-reach B2B professionals + moderated interviews). Install: npx skills add sales-skills/sales --skill sales-prolific -a claude-code
• /sales-userintuition — Pure real-human AI-moderated interviews with a self-serve REST API + webhooks + MCP — the pick when you want the interview run for you, not just a recruit. Install: npx skills add sales-skills/sales --skill sales-userintuition -a claude-code
• /sales-funnel — Build the smoke-test / fake-door landing page that turns a research hypothesis into a real demand test. Install: npx skills add sales-skills/sales --skill sales-funnel -a claude-code
• /sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do -a claude-code

Examples

Example 1: "How do I embed Respondent recruiting in my product and auto-pay attendees?" (developer/automation)

User says: "I'm building a research platform and want to create studies and pay participants through Respondent's API." Skill does: Explains the Partner API is a partner/embed API — request Client ID + Client Secret, send them as x-api-key + x-api-secret (not Bearer), build against staging first. Sketches the flow: POST /v1/projects → add screener questions → publish → subscribe to response.status_changed webhooks → on attended, call Mark as attended then Trigger manual payout (Tremendous). Flags that webhook HMAC/retry specifics aren't on the public docs — verify the signature live and add a status-filtered reconcile poll — and that production access needs the demo-video checklist. Result: The user builds a webhook + reconcile pipeline behind their own UI with the payout gate correct.

Example 2: "My Respondent participants keep not matching what I asked for"

User says: "Half the people I recruit don't actually fit the profile — am I on a bad panel?" Skill does: Reframes it as a screener-design problem, not a bad panel (Respondent is phone+work-email verified, <1% fraud). Prescribes behavior-based screener questions (last time they did X), a hidden disqualifier, skip logic, and quotas; tells the user to report/hide off-brief applicants and tighten targeting. Notes reviewers do report occasional off-brief participants on incentivized panels — the fix is the screener. Result: The user rewrites the screener and gets qualified B2B participants.

Example 3: "Is Respondent's $40/session the whole cost, and how do I keep it down?"

User says: "I need 8 B2B interviews — what will this actually cost?" Skill does: Breaks down total = recruit fee (~$40 PAYG or ~$34/session on a ~63-session bundle) + the incentive you set (B2B often $50–$150/hr) + ~5% fee — so the sticker price is not the whole cost. Suggests unmoderated (~-38%) where the method allows and a credit bundle for volume, and that surveys are custom-priced. Presents all figures as best-effort — confirm at respondent.io/pricing. Result: The user budgets recruit + incentive + fee and picks the cheaper methodology where possible.

Troubleshooting

"Too many participants no-show / I paid for empty slots"

Symptom: Booked participants don't join the call. Cause: No-shows are the top researcher-side complaint even at ~95% show rate; and payouts are manual, so a mis-marked attendee can get paid. Solution: Over-recruit past your target, enable automated reminders + the calendar/Zoom integration, and Mark as no-show for absentees so they aren't paid. Only run Trigger manual payout after Mark as attended.

"My API calls 401 / where's my API key?"

Symptom: Requests fail auth, or you can't find a key. Cause: Respondent uses two headers — x-api-key (Client ID) + x-api-secret (Client Secret) — not a Bearer token, and credentials are partner-provisioned (Quickstart + demo-video checklist), not instant self-serve. (You may also be reading respond.io's Bearer docs by mistake.) Solution: Request Client ID/Secret via the Quickstart, send both headers, and test on staging (api-staging.respondent.io) with a test participant (staging-only) before production.

"A participant says they never got paid"

Symptom: Attendance happened but no incentive arrived. Cause: Payouts are researcher-triggered and gated on attendance — if you didn't **mark attended

• trigger payout**, nothing is sent; Tremendous payouts also take ~7–10 business days. Solution: Mark as attended then Trigger manual payout; check View credit and incentive balance to confirm funds, and use Retrieve payout counts to audit. Automate "attended → pay" but keep a manual review for disputes.