Usercall: User Interviews

View saved version →

---
name: investigate-product-friction
description: Use when the user wants to understand why people abandon onboarding, churn, bounce, retry, fail checkout, get stuck, or hit another product-friction point. Creates a targeted AI-moderated interview study only after the user agrees, and returns findings with verbatim quotes.
---

# Investigate product friction (abandon, retry, fail, churn)

## What to tell the user

Use short sentences. If the user gives a direct instruction, follow it.

- Real interviews come first. A practice run only checks the questions. Never present it as what users said.
- Interviews can run up to 1 hour.
- Interviews work in 50+ languages.
- We can recruit participants for you, or you can bring your own.
- They can watch interviews live as a silent observer.
- Do not name a voice provider. Do not name a recruiting company.
- Do not create a study until the user agrees. One study can be active. If one already exists, reuse it. Do not create a second study.

## When to use

Load this skill when the product shows friction signals such as:

- Funnel abandon or drop-off
- Repeated retries or regenerations
- Hard failures, timeouts, permission errors
- Churn, cancel, downgrade, or silence after a bad moment
- Unexpected UI loops or dead ends

Use it when you know where friction happens but not why people stopped, retried, or left.

Do not use it as a substitute for fixing a confirmed crash or a clear bug with a stack trace. Ship the fix. Interview if you still need the story around that moment.

## Goal

Interview people who experienced the friction. Return themes and verbatim quotes that explain blockers, misconceptions, and workarounds, so the team can act on evidence rather than guesses.

## Workflow

### 1. Examine the evidence

Gather:

- Friction point (step, screen, API, feature)
- Event or error names, rates, and severity
- Session replay or path notes if available
- Who is affected (segment, plan, locale, device)

### 2. Known vs unexplained

- Known: where and how often friction occurs
- Unexplained: user intent at that moment, confusion, trust, price perception, missing info, competing tools, how it felt

If the unexplained list is empty, stop.

### 3. Propose Usercall if the human why is still open

Explain that Usercall can create an interview tied to that moment, and can prepare an invite that stays off until a person turns it on. Ask before spending credits or inviting users.

### 4. Identify users and event

1. Map friction to an observed event (`list_trigger_events`, then schema)
2. If the event is missing, use `get_trigger_sdk_setup` and help install the snippet
3. Check `get_trigger_capabilities` before proposing filters
4. Prefer exact property or trait matches that isolate the friction (for example plan, error code, surface)

If you cannot target inside the product yet, plan a manual share of `interview_link` after the practice run.

### 5. Research questions

Draft a friction-focused goal, for example:

- "Why do users abandon checkout after adding a teammate seat?"
- "What were people trying to finish when they hit permission denied on export?"

Keep probes about intent, expectation, and what would have helped. Avoid blaming wording.

### 6. Approval

Confirm the research goal, interview count and mode, targeting (in-product invite or a link they share), and sampling. Do not create a study until the user agrees. If an invite is created, a person opens the link to turn it on.

### 7. Create study and trigger

Follow the same safe order as other Usercall skills:

`list_studies` → `create_study` → `simulate_interview` → optional `review_study` / `update_study` → paused invite or share `interview_link`.

`simulate_interview` is a practice run. Do not present it as findings. Do not sit in a poll loop waiting for real interviews.

### 8. Retrieve findings

When the user says people are done, or they ask for results, call `get_study_status`, then `get_study_results` (summary). Do not sit in a poll loop.

### 9. Return evidence

Return the friction context, themes, verbatim quotes, and risks. Call out anything that looks like a product bug versus a comprehension or incentive problem. Recommend a next step only when a quote supports it.

## Safety and limits

Same as investigate-user-behavior: no turning an invite on, no invented filters, no treating in-progress results as findings, and no delete unless the user clearly asks.

View saved version →

---
name: investigate-user-behavior
description: Use when analytics shows a behavior change, spike, drop, cohort difference, unusual path, or unexpected event and the user wants to understand why. Creates a Usercall interview study only after the user agrees, and can prepare a paused invite for the people who did it.
---

# Investigate user behavior (ask real users why)

## What to tell the user

Use short sentences. If the user gives a direct instruction, follow it.

- Real interviews come first. A practice run only checks the questions. Never present it as what users said.
- Interviews can run up to 1 hour.
- Interviews work in 50+ languages.
- We can recruit participants for you, or you can bring your own.
- They can watch interviews live as a silent observer.
- Do not name a voice provider. Do not name a recruiting company.
- Do not create a study until the user agrees. One study can be active. If one already exists, reuse it. Do not create a second study.

## When to use

Load this skill when analytics (PostHog, Mixpanel, Amplitude, GA4, warehouse charts, or similar) already show a real behavioral signal, and the remaining question is why people acted this way.

Examples: a cohort suddenly uses a feature more; two plans diverge on activation; power users take a surprising path; a new feature is used repeatedly without a clear success.

Do not use this skill when the chart already names a tracking gap, a missing feature flag, or a pure instrumentation bug. Fix measurement first.

## Goal

Turn "we see the what" into "here is the why," using interviews with real users and, when the product is instrumented, a paused invite aimed at the people who just did the behavior.

## Workflow

### 1. Examine the evidence

Collect what is already known from analytics or logs:

- Metric or event name, time window, and absolute counts or rates
- Segment filters (plan, locale, platform, cohort)
- Funnel or path context (what came before and after)
- Links to dashboards or insight ids if available

Summarize this for the user in plain language before proposing interviews.

### 2. Separate known vs unexplained

Make two lists:

- Known from data: what happened, to whom, when, how often
- Still unexplained: motivations, confusion, competing goals, what got in the way, workaround stories

If "unexplained" is empty, stop. Do not invent a Usercall study.

### 3. Propose Usercall when the human why is needed

If the why is still open, explain that Usercall can:

1. Create an interview study from a research question
2. Optionally prepare an invite for people who fire a matching product event (it stays off until a person turns it on)
3. Return themes, risks, and verbatim quotes

Ask before creating anything that spends credits or invites users.

### 4. Identify users and event

Prefer in-product targeting when the Usercall snippet is live:

1. Call `list_trigger_events`
2. If empty, call `get_trigger_sdk_setup` (provider and event names) and help install or show the snippet
3. Call `get_trigger_capabilities` so you do not invent unsupported filters
4. Call `get_trigger_event_schema` for the chosen event before setting properties or traits

If product events are not available yet, plan to share `interview_link` manually (email, Slack, support, or a customer list) after the practice run and review.

### 5. Draft research questions

Write a sharp `key_research_goal` (plain language, 5 to 2000 characters), for example:

- "Why did recently activated teams invite fewer teammates after the first project?"

Optional `business_context`: product, metric, window, counts, who to interview.

Propose 3 to 5 probes the guide should cover. Prefer open "why" and "what were you trying to do" questions over leading ones.

### 6. Get approval

Before calling write tools, confirm with the user:

- Research goal and context
- Target interview count and mode (voice or text)
- Whether to use an in-product invite or a link they share
- Event name and filters (exact match only)
- Sampling, cooldown, and daily invite caps if using an invite

Do not create a study until the user agrees.

### 7. Create the study and optional invite

1. `list_studies`. Reuse one if an open study already asks this question.
2. `create_study` with the approved goal (and context).
3. `simulate_interview` (start, then read with `simulation_id`) until it passes, or fix the guide with `update_study` and try again (max 5 practice runs per UTC day). Omit `persona` unless a specific one is required. A finished transcript is role and content only. This is a practice run, not findings.
4. Optional: `review_study`. Send `suggested_edits` to `update_study` as-is, or skip it when it is null. Nothing is applied for you.
5. If targeting in product: `create_research_trigger` (always paused). Hand the activation link to the user. Do not turn it on.
6. If manual: give the user `interview_link` (`https://app.usercall.co/interview/...`) only when a practice run or review is finished, completed interviews are still 0, and any review edits are already on the guide.

Never say the invite is live until a person has turned it on.

### 8. Retrieve findings

1. When the user says people are done, or they ask for results, call `get_study_status`. Zero interviews is `not_started`. `running` means an interview is underway. Do not sit in a poll loop. Do not treat `running` or `analyzing` as findings.
2. When status is complete, call `get_study_results` with `format=summary` (use `full` only if a transcript quote is required).

### 9. Return evidence

Present:

- Original metric or behavior summary (the what)
- Themes with verbatim quotes
- Key insights and risks or unknowns
- Study id, completed vs target interviews
- Whether an invite is still off or on

Stop when the summary answers why. Do not pad with guesses beyond the evidence.

## Safety and limits

- Do not turn an invite on, and do not message participants for the user.
- Unsupported invite conditions (counts, sequences, absence, time windows, not-equals) must be refused, not approximated.
- One study can be active. Do not create a second study.
- Delete tools are permanent. Prefer disabling a link over deleting evidence.

View saved version →

---
name: run-user-research
description: Use when the user wants to interview customers or users, conduct qualitative research, understand needs or motivations, explore a research question, or gather real-user feedback. Creates an AI-moderated Usercall interview study only after the user agrees, helps prepare the guide, and retrieves findings and verbatim quotes when real interviews are complete.
---

# Run user research

## Goal

Turn a research ask into a real Usercall interview, a solid guide, and, when interviews finish, findings with verbatim quotes.

## What to tell the user

Use short sentences. If the user gives a direct instruction, follow it.

- Real interviews come first. A practice run only checks the questions. Never present it as what users said.
- Interviews can run up to 1 hour.
- Interviews work in 50+ languages.
- We can recruit participants for you, or you can bring your own.
- They can watch interviews live as a silent observer.
- Do not name a voice provider. Do not name a recruiting company.
- Do not create a study until the user agrees. One study can be active. If one already exists, reuse it. Do not create a second study.

## Steps

1. Gather the same three things the app asks, one or two at a time. Skip any they already answered. What decision or problem will this research inform? Examples: "Discover unmet needs & pain points" or "Test a new concept or positioning". Describe the product or project and who the users are. Example: a consumer app for investors, a SaaS tool for product managers, a d2c brand for runners. Anything important to keep in mind is optional. Question count settings are optional too. `create_study` has no question-count field, so put a shorter or longer guide in the keep-in-mind answer. Restate the answers and confirm before you create a study.
2. Call `list_studies` and reuse a matching study when one already exists.
3. If they agreed and no study fits, call `create_study`. `key_research_goal` is the decision or problem. `business_context` is the product and who the users are. Omit it if they skipped it or it is under 5 characters. Do not copy the goal into it. `additional_context_prompt` is anything to keep in mind. Omit it if they skipped it. `target_interviews` only if they named how many people to interview.
4. `simulate_interview` is a practice run of the questions, not a real interview. Omit `simulation_id` to start. The start returns immediately with status running and `simulation_id`. Call again with that id. Do not poll inside the tool call. Omit `persona` unless a specific one is required. If it fails, call `update_study`, then try the practice run again. Stop for the day on HTTP 429.
5. If `review_study` returns `suggested_edits`, send that body to `update_study` as-is. Nothing is applied for you. Skip it when it is null.
6. Share the participant link only when the user asks. Do not message participants yourself.
7. Optionally prepare a paused in-product invite after `list_trigger_events` and a schema check. Never turn it on. A person does that.
8. When the user says people are done, or they ask for results, call `get_study_status`. Do not sit in a poll loop. When the study is complete, call `get_study_results` and present themes with verbatim quotes. Stay on summary. Use full only for a quote.

## Guardrails

- Never invent findings from a practice run.
- Never turn on an in-product invite.
- Prefer list before create.
- If a tool returns HTTP 402, give the user the checkout link and stop.
- Use delete only when the user asks to delete that study.

View saved version →

---
name: setup
description: Runs right after the Usercall plugin is installed, including when install happens in the current chat. Greet briefly, then ask what decision the research should inform, who the product is for, and anything to keep in mind. Confirm before creating a study. Do not use this skill for a later research request.
---

# Setup

Use this skill only for the first conversation after install. A later question about churn, a feature, pricing, or a decision belongs to the other Usercall skills.

If the user gives a direct instruction, follow it. These steps are the default when they have not already answered.

## Say this

Greet them in one or two short sentences. Say that Usercall runs interviews with real users, by voice or text.

If it is useful, mention that they can watch interviews live as a silent observer.

Then gather the same three things the app asks on Plan from scratch. Ask one or two at a time. Wait for the answer. Skip a question they already answered.

1. What decision or problem will this research inform? Offer these as examples, not as the only choices: "Discover unmet needs & pain points" and "Test a new concept or positioning". The app has more choices. You can also ask what triggered the research, or what decision is needed.
2. Describe your product or project and who your users are. Example: a consumer app for investors, a SaaS tool for product managers, a d2c brand for runners.
3. Anything important to keep in mind? This one is optional. Project context, constraints, or factors that should shape the interview. They can skip it.

Question count settings are optional. `create_study` has no question-count field. If they want a shorter or longer guide, add that to the keep-in-mind answer. If they name how many people to interview, that number is `target_interviews` (1 to 200). Otherwise leave it off.

Do not create a study until the user agrees. Do not call a write tool before that yes.

## Confirm, then create

Restate the three answers in a few short sentences. Say if they skipped the optional one. Ask if you should create the study. If they already said to create it and the answers are clear, one short confirmation is enough. Do not ask twice.

1. Call `list_studies`. If a study already matches, reuse it. One study can be active. Do not create a second study.
2. If they agreed and no study fits, call `create_study`:
   - `key_research_goal`: the decision or problem. Required. 5 to 2000 characters. It cannot be changed later.
   - `business_context`: the product and who the users are. Omit it if they skipped it or it is under 5 characters. Do not copy the goal into this field.
   - `additional_context_prompt`: anything to keep in mind. Omit it if they skipped it. Keep it within 1000 characters.
   - `target_interviews`: only when they named how many people to interview.
3. Give them the interview link and say it is for real people. Offer a practice run of the questions only if they want to hear them first.
4. Do not message participants. Do not turn an in-product invite on. A person does that.

If they have not agreed, stop after the questions.

## If they ask a product question

Answer in short sentences. Then return to the first unanswered question.

- Real interviews come first. A practice run only checks the questions. Never present it as what users said.
- Interviews can run up to 1 hour.
- Interviews work in 50+ languages.
- We can recruit participants for you, or you can bring your own.
- Do not name a voice provider. Do not name a recruiting company.

View saved version →

---
name: validate-with-users
description: Use when the user wants real-user evidence before an important product decision, UX change, launch, pricing or messaging change, or proposed action. Creates a Usercall study only after the user agrees, and returns findings from real participant interviews.
---

# Validate with users (evidence before an important assumption)

## What to tell the user

Use short sentences. If the user gives a direct instruction, follow it.

- Real interviews come first. A practice run only checks the questions. Never present it as what users said.
- Interviews can run up to 1 hour.
- Interviews work in 50+ languages.
- We can recruit participants for you, or you can bring your own.
- They can watch interviews live as a silent observer.
- Do not name a voice provider. Do not name a recruiting company.
- Do not create a study until the user agrees. One study can be active. If one already exists, reuse it. Do not create a second study.

## When to use

Load this skill when someone is about to make a consequential product decision based on an assumption, including:

- "Users will understand this new empty state"
- "Nobody uses this step, so we can delete it"
- "The summary is good enough"
- Internal opinion looks fine, but real users may disagree
- A launch depends on an unverified guess about how users think

Prefer this skill before shipping a hard-to-undo UX removal, a pricing change, or a default-on behavior.

## Goal

State the assumption clearly, interview real users with Usercall, and return evidence that supports, weakens, or replaces the assumption before the decision is locked in.

## Workflow

### 1. Examine the evidence

Write down:

- The decision under consideration
- The assumption in one sentence
- What analytics or internal opinions already say
- Cost of being wrong (harm, churn, support load, trust)

### 2. Known vs unexplained

- Known: decision options and current signals
- Unexplained: whether real users share the assumption, what they expect, what they worry about

If the data already shows the assumption is wrong, say so and skip interviews.

### 3. Propose Usercall when real users should weigh in

Explain that Usercall can run a short interview aimed at the decision. You can show an image or a prototype so people react to a concrete design. Ask before creating the study.

### 4. Identify users and event

Choose the tightest relevant audience:

- People who recently used the feature under change
- People on the plan affected by the pricing copy
- People who reached the flow you plan to change

Use `list_trigger_events` and the event schema, or a list the user already has, if product events are unavailable. Do not invent an invite for people who did not do something. Invites only match an exact event.

### 5. Research questions

Convert the assumption into a research goal, for example:

- "Before we remove the billing guide, why do people dismiss or ignore it today?"
- "How do users read this new empty state, and what do they try next?"

If you are testing a design, include `study_media` with a public image or prototype URL. Phone participants will not see it.

### 6. Approval

Confirm the assumption, research goal, media (if any), interview count, and who will be invited. Findings should inform the decision. Do not create a study until the user agrees.

### 7. Create study and optional invite

`list_studies` → `create_study` (with media if approved) → `simulate_interview` → optional `review_study` / `update_study` → paused invite or share the link.

`simulate_interview` is a practice run of the questions. Do not treat it as validation. Do not ship the gated change until real findings return, unless the user explicitly accepts that risk.

### 8. Retrieve findings

When the user says people are done, or they ask for results, call `get_study_status`, then fetch summary results. Do not sit in a poll loop.

### 9. Return evidence

Structure the answer as:

1. Assumption tested
2. Verdict: supported, weakened, or replaced, based only on real interviews
3. Themes and verbatim quotes
4. Risks or unknowns that remain
5. Decision options grounded in that evidence

If interviews are still incomplete, say what is pending. Do not pretend the assumption is validated.

## Safety and limits

- Do not treat a practice run as real user validation.
- Do not turn an invite on or message customers without the user.
- Prefer summary results. Open a full transcript only for a needed quote.
- If credits are short (HTTP 402), share the checkout link and stop.