Running an auto-interview

An auto-interview runs a guide against your synthetic participants in parallel and produces a synthesis at the end. This article walks through the launch, the run page, the chips and badges, and how to read what comes back.

Getting to an approved guide

Runs start from an approved interview guide, and a guide comes from a research plan. Building one is four screens: what you want to learn (one free-text answer, which drives everything after it; you stay on this screen, with a note under the box, if the answer has nothing to research or is entirely about how a design or screen looks, because participants read and respond in words and cannot see designs), the research to run (Candor works out which of the four approaches your question needs, and the order, when it needs more than one; the later steps are shown to read, not to click, and a multi-step plan says in a sentence which step to start with and that those later steps are separate research plans to set up on their own; a note can also appear above the plan suggesting research the plan does not contain, which you act on by going back and rewording your answer; and when only part of your question needs participants to see a design, a note says the plan covers the rest), your inputs (what participants react to for concept testing, which solutions to price for price testing, what problems to test for problem validation, or optional assumptions for problem discovery), and review your research plan (everything shown back, with the learning goals editable). Generating the guide from that last screen also approves it and drops you on the guide, ready to launch. That page is titled Research plan: followed by the plan’s name, which starts as its version and approach (“v3 · Concept testing”); the pencil beside the title renames it at any time, and the name never changes what the interviews ask or what the report says. Full detail is in the Building a research plan article.

Launching a run

From an approved guide, the launch flow is one screen. By default, Launch all interviews is checked, which runs the guide against every participant in the project. Uncheck it to pick a subset: participants arranged by group, with tri-state checkboxes per group.

Once you click Launch interviews, the run kicks off and you’re redirected to the run page. Up to 12 sessions execute in parallel; the rest queue.

On the Free plan, automated interviews are billed per interview, so the launch checks that your workspace has a card on file. If it doesn’t, you’ll see an Add a card to run interviews prompt that links to Billing settings; add a card there and launch again. You’re only charged for interviews that complete, once the report is ready. Subscription plans already have a card on file, so they skip this check.

Industry context on a run

Every participant carries a snapshot of recent developments in their industry, captured when the audience was generated, so they can speak plausibly about what’s been happening rather than answering from a blank slate. In an auto-interview you see it as a muted Industry Context line with a date and an information icon. Click the icon and a panel opens with the industry it focused on, the key themes it picked up, and links out to the sources it read.

It appears in three places, and the date means something slightly different in each. On the last step before you launch it reads Industry context for this run and shows the snapshot the upcoming sessions will use, alongside a Manage on project page link if you want to refresh it first. On the run page header, and again inside each expanded transcript, it reads Industry Context and shows the snapshot those sessions were actually run against.

Sessions freeze their snapshot the moment they are created, so refreshing industry context mid-run changes nothing about the sessions already in flight. It applies to future ones only. That is deliberate: it means every session in a run answers from the same picture of the world, so a difference between two participants is about the participants rather than about when their session happened to start.

The run page

Top of the page: a status card showing how many sessions are complete, how many failed, and a progress bar split between the interview phase and the synthesis phase that follows it. Below that is a list of session cards, one per participant.

Session cards

Each card shows the participant name on the left. On the right, in one row: a status label (Queued, Interviewing, Interview complete, Failed, or Abandoned), the chips described below, and a turn count. When a session fails, the reason reads as a sentence under the participant name. Cards are clickable once they have at least one turn. Click to expand the transcript inline.

The chips

On the right of each session card you’ll see chips summarising what happened. The set you see depends on the interview type.

  • Learning goals (all interview types). Three forms. While the interview is still running it reads 2 of 5 learning goals so far and is a progress count, nothing more. Once the session finishes it becomes 4 of 5 learning goals answered, and turns yellow when a goal was never reached. A session that failed or was abandoned reads 2 of 5 learning goals covered and stays neutral, because the goals it missed were ones it never got the chance to reach. Hover for the breakdown.
  • The card sort (problem validation and concept testing, on card-sort runs). Reads Sorted 8 problems (or concepts), and hovering gives you the spread across the buckets, like “2 very challenging, 3 somewhat challenging, 2 not challenging, 1 doesn’t apply”. Some sorts turn the chip yellow. That is a prompt to open the transcript and read the per-item table, not a verdict on the session.
  • Concept understanding (concept testing, on runs that aren’t card sorts). Three states. All 3 concepts understood (green) means the participant was asked about every concept and understood each one. 2 of 3 concepts understood in muted grey means a concept was never reached. The same wording in yellow means a concept was explained and the participant still didn’t understand it. The count is always out of the concepts in your study, so a concept nobody got to still shows in the total. Hover for which concept.
  • Concept appeal (concept testing, on card-sort runs). Replaces the understanding chip on those runs, because we only check understanding for concepts the participant showed interest in. Reads 2 of 6 concepts appealed, counting the concepts the participant put in the top bucket, and 0 of 6 concepts appealed when they rated the concepts but put none in the top bucket, which is not an error.
  • Consistency with profile (all interview types). We check every answer for the participant inventing a product or a price they never mentioned, answering at a technical level they wouldn’t use, or speaking as someone other than themselves. Concept tests add two more checks, for contradicting something they established earlier and for instant enthusiasm from a participant whose profile says they’re wary of new things. The chip reads Consistent with profile when nothing was flagged, or 2 inconsistencies when something was. One answer can trip more than one check, so the hover gives you both numbers, plus each flagged answer with its turn number and an excerpt.

Reading a transcript

Click a session card to expand. You’ll see the full interviewer/participant turn-by-turn transcript, with two kinds of marker on the turns. An answer that clashes with something the participant said earlier, or with their own profile, is marked Contradicts themselves. An answer the character check caught is marked Inconsistent with profile. Those are two separate checks: the first runs on every interview type, while the character chip above counts only what the second one found.

On card-sort sessions a table appears at the top headed How they sorted the problems (or concepts), listing each item with how they rated it, their ranking, what kind of follow-up it got, and how many questions were spent on it. A follow-up reads either Full follow-up, which is several rounds of questions digging into that item, or Asked what was missing, a single question about what would have to change for it to appeal more. Which one a participant gets depends on how they sorted: the lighter one runs when nothing landed in the top bucket. A dash under Follow-up means the run recorded no follow-up for that item, though the participant may still have been asked about it elsewhere in the session. The Questions asked count covers both kinds of follow-up, so a dash there means the run recorded no follow-up questions for that item.

Once a session completes, an auto-generated session summary sits above the transcript. Skim summaries first if you have many sessions. Full transcripts are for the ones whose chips made you curious.

Exporting transcripts

Click Export transcripts in the run header to download every session as a single Markdown file. Inside an expanded session, Export transcript grabs just that one. Files contain the full Q/A history with no truncation, so you can feed them to another tool or LLM for offline analysis.

When sessions stop

Each session has stopping criteria built into the guide. Sessions end when learning goals are sufficiently covered, the participant is going off-profile (degradation detection), or section budgets are spent. You’ll see this reflected in the final coverage chip. A clean ending shows good coverage, an early stop will show in the chip with yellow styling.

After the run

Once every session is in a terminal state (complete or failed), Candor automatically kicks off synthesis. The progress bar shifts to the synthesis phase. When synthesis finishes, a green banner appears with a View report link. That’s where the structured findings live.

If synthesis fails, the run page surfaces an error and a link to the report page where you can read the failure reason and retry.

A note on what happens to memory

Auto-interview sessions write to the same participant memory as live interviews. If you run an auto-interview against a participant you’ve already had a live conversation with, the auto-interviewer knows what you discussed and the participant references it. This is why session ordering matters; running a guide twice produces two distinct sessions, both retained.

Where to go next

Common questions

By default, all of them. A study builds between 6 and 24 synthetic participants, the number depending on how many groups your audience breaks into and how much of the audience each one covers, and the launch flow ticks Launch all interviews for you. That is usually the right call, because the synthesis reads across the whole set, so every session you drop is signal the report cannot use. Uncheck the box when you have a reason to narrow, such as a follow-up on a single group. The picker arranges participants by group with tri-state checkboxes, so a subset can still span the audience instead of clustering in one corner of it. Narrow too far and the report tells you: two or fewer completed sessions puts a yellow banner at the top saying nothing in it can be called a pattern.

The coverage chip counts how many of the guide's learning goals this synthetic participant actually got to. While a session is still running it reads "2 of 5 learning goals so far" and is a plain progress count, not a warning. Once the session finishes it reads "4 of 5 learning goals answered" and turns yellow when a goal was never reached, with the breakdown in the hover. A session that failed or was abandoned stays neutral, because it never got the chance to reach the rest. The character chip is the other half. We check every answer for the participant stepping outside their profile or inventing products or prices they never mentioned, and those two checks run on every interview type. Concept tests add two more, for contradicting something they established earlier and for instant enthusiasm from a participant whose profile says they're wary of new things, so a self-contradiction is only counted as an inconsistency on a concept test. The chip either reads "Consistent with profile" or counts the inconsistencies, with the kinds and the number of answers involved in the hover, and it appears on every interview type, not just concept tests. Separately from the chip, every interview type runs a consistency check on each answer, and a turn it catches is marked "contradicts themselves" in the transcript. That fires when an answer clashes with something the participant said earlier, or with a belief, a decision, or a biographical fact in their profile. It is not counted by the character chip, so a session can read "Consistent with profile" and still show that marker on a turn. A session with every goal answered and no inconsistencies is clean. A session with yellow coverage or several inconsistencies is worth opening to read the transcript before trusting the synthesis. Use the chips to prioritise which sessions to actually read.

Three common reasons. First, a synthetic participant was going off-profile and degradation detection ended the session to protect transcript quality. Second, section budgets were exhausted (the guide capped how many turns can be spent in each section). Third, an LLM or infrastructure timeout occurred and the session was retried but couldn't complete. The run page surfaces the cause on each session card. Retry usually works for the third case. The first two cases are signal: the participant isn't a great fit for the guide.

Yes, if the live conversations and the guide are about the same topic, since the synthetic participants will reference what you discussed before. If the live session covered different ground, also yes, since the auto-interviewer can extend coverage in directions you didn't go. The one case to avoid: don't run an auto-interview that asks a participant to "discover" something they already discussed with you. They'll skip it as known. Auto-interviews work best on fresh ground or on participants you haven't talked to yet.

They flag an option that doesn't fit the kind of test you're running. Candor reviews each candidate name, value proposition, or message against the concept it's attached to, at two levels. A clear wrong-kind option in a value-proposition or message test — a bare product name, or a whole product description, where a benefit or a headline belongs — stops generation until you replace it, because it would waste the run. A softer issue — a vague benefit, a feature stated instead of a benefit, a price, or an option that just reads oddly — shows a note that does not block, and often offers a one-click rewrite of your own wording. Name tests only ever warn, never block. Fixing or editing a flagged option clears its note right away. A different yellow note, "Reads like a research brief," can show under any concept or option description that talks about what you want to learn, the study, or the participants instead of the thing being tested. Participants read that description word for word, so describe what you're testing there and put what you want to learn in "Is there anything else you want to explore?" It never blocks, and it skips the optional note beside a candidate name, which participants never hear.

As soon as every session is in a terminal state (complete, failed, or abandoned). You don't have to launch synthesis manually. The progress bar shifts to the synthesis phase and a green "View report" banner appears when it's done. If a session is still running and others have failed, synthesis waits. If synthesis itself fails, the run page surfaces the error with a retry button. Most synthesis failures are transient and a retry succeeds.

More FAQs →

Bring evidence to your next decision.

Start with a free project, or walk through Candor with us first.