Channels, consent, identity
Voice, chat, embed - and who the respondent is.
The blueprint and agent decide what the interview is. Three more decisions decide how the respondent experiences it: which channel they meet the agent on, what they consent to, and how they're identified. None of these are configuration afterthoughts - channel choice changes what depth you can run, consent shapes the data you can keep, and identity choice constrains your analysis.
Channel decision
Three channels: voice, chat, embed. They're not interchangeable.
| Attribute | Voice | Chat | Embed |
|---|---|---|---|
| Environment | Anywhere a phone works (in the car, on the floor, while walking) | Anywhere typing is OK | Inside another product |
| Data richness | Highest - tone, pace, hesitation, real-time emotion | Medium - text only, lower disclosure than voice | Varies - mirrors the channel of the embed |
| Respondent effort | Low for the talker; demanding for accents and noisy contexts | Medium; requires a keyboard moment | Lowest - context already in the host product |
| Accessibility | Good for low-literacy and visually impaired; harder for hard-of-hearing | Good for hard-of-hearing; harder for low-literacy | Inherits from the host product |
| Best for | Discovery, churn, sales debrief, field work | Quick pulse checks, async research, anything time-shifted | In-app feedback, onboarding, churn-on-cancel |
| Watch out for | Background noise, accents the model handles poorly, respondents who feel performative | Lower depth tolerance - chat respondents disengage faster | Dependence on the host product's UX - if the host is broken, the interview is too |
Voice is the differentiated channel. Most competitors run chat. Voice is where Debriefer's hosted interface earns its keep - accent handling, modality switching, real-time probing on tone and hesitation. Pick voice unless you have a specific reason not to. The depth budget in voice - follow-ups a respondent will tolerate before disengaging - is roughly twice what chat allows, and that compounds with every node.
Embed is the integration story. Use it when the interview should feel native to your own product: in-app feedback, churn-on-cancel, onboarding completion. The respondent stays in your context and you control the surrounding chrome. See the React components and hooks for the embed surface and the run-tools reference for how a run is launched against a chosen channel.
Consent
settings.consent: true on the blueprint. Treat it as table stakes when:
- The channel is voice and you're recording - explicit consent is required in most jurisdictions.
- The use case touches regulated sectors (healthcare, finance, public sector, employment).
- The interview is for research that will be published, attributed, or shared externally.
- The respondent might reasonably expect not to be recorded (employee feedback, customer support follow-up).
When consent is on, the agent prompts for explicit acknowledgement before any node fires. The acknowledgement is logged on the run and is part of the durable record.
A short note on what consent does not solve: it doesn't make low-trust framing legitimate. If respondents agree to be recorded but feel coerced, the data is still poor. Consent is necessary, not sufficient - the persona and intro_message do the rest of the work.
When in doubt, turn it on. The cost of explicit consent is one extra interaction; the cost of an ambiguous record is high.
Participant identity
Three patterns:
- Anonymous. No identifier on the run. Respondent fully untraceable. Use for sensitive topics - whistleblower channels, mental health, exit interviews where blowback is a real risk. Trade-off: you can't follow up with the respondent, and you can't join the data to anything else you know about them.
- Pseudonymous. A hashed or tokenised identifier on the run - typically a one-way hash of email or user ID. Use for research where you want to dedupe respondents and group runs across time without exposing identity to analysts. The default for most research work.
- Identified. The respondent's actual identity is on the run. Use for sales debriefs, performance reviews, support escalations - anywhere the identity is part of the data, not a privacy concern.
Implication for analysis: anonymous runs can't be cohort-grouped on demographics. Pseudonymous can if the cohort attributes were captured on the run. Identified runs can be joined to anything else you have on the respondent. Pick the weakest identity that still lets you answer the question you're running the interview to answer.
intro_message and outro_message
The first and last thing the respondent sees. Both are blueprint settings, both are trust instruments - not throwaway copy.
A good intro_message:
- Names who is asking and why.
- States how long it'll take and what the respondent is consenting to.
- Sets the conversational register the agent will hold to.
A bad intro_message:
- Marketing copy.
- Vague ("we'd love to hear your thoughts").
- Asks the respondent to do work before the interview starts.
A good outro_message:
- Confirms what happens next - results, follow-up, or nothing.
- Gives a way to reach a human if the respondent wants to.
A bad outro_message:
- Asks for a survey rating of the interview itself.
- Goes silent - respondents finish the interview and feel orphaned.