Decision-ready output

After a run completes, Debriefer produces analysis: themes across the transcript, sentiment, and verbatim quotes. Plus structured responses captured at the node level for any form or question node that asked for them. None of this makes the decision for you. The point of this chapter is to design the blueprint so the analysis can support the decision the objective chapter named - and to be honest about the things the analysis still won't do.

What analysis produces

Three outputs:

• Themes. Cross-respondent patterns in the open-ended responses. The platform clusters semantically and ranks by frequency or salience. Useful when you have 5+ runs on the same blueprint.
• Sentiment. Per-run and per-node valence (positive / neutral / negative). Useful for trend tracking; less useful for individual run interpretation, where the verbatims tell you more.
• Verbatim quotes. Top representative or anomalous quotes from the transcript. The thing most worth reading. Themes and sentiment compress; verbatims preserve the texture.

What it doesn't produce:

• Decisions. "Customers want lower prices" is a theme. "We should lower prices" is a decision - and one the analysis can't make for you.
• Causal inference. Themes correlate; they don't explain. If you need to know why something is true, the interview itself has to ask.
• Statistical claims at low N. With 5 runs, treat themes as hypotheses. With 50, treat them as patterns. With 500, treat them as findings.

Structured responses vs free-text analysis

A blueprint produces two distinct streams of output:

• Free text - open-ended question nodes. Goes into the transcript and the theme/sentiment/verbatim analysis.
• Structured responses - form nodes and any node that captures a specific typed value. Comes back as a typed field on the run, available for direct query, CRM sync, or downstream branching.

Reach for structured responses when:

• You need to filter, aggregate, or join the result on a specific value (rating, choice, yes/no).
• The decision the interview informs depends on that value being typed.
• You'll graph or chart the response over time.

Reach for free text when:

• The shape of the answer is part of the data - you don't know what categories will emerge.
• The respondent's framing matters more than their classification.

Most blueprints want both.

Designing for analysability

Three concrete patterns:

1. Always fill the objective field on open nodes.

The node's objective tells the analyser what this node was for - which makes its themes more useful in cross-run aggregation. Without it, themes from one node bleed into themes from another. Don't skip it.

2. Use form node type when you need typed output downstream.

If the answer needs to drive branching, sync to a CRM, or appear in a chart, capture it as a form node, not a free-text node followed by post-hoc parsing. Post-hoc parsing of free text is brittle; structured capture is not.

3. Name keys for the long term.

Use stable, lowercase snake_case keys (satisfaction_rating, cancellation_reason, would_recommend). Survives CSV export, joins cleanly to other data, doesn't break when the question wording changes. Avoid q1, q2, q3 - they're meaningless once a node is renamed or moved.

These three patterns are the difference between an interview that produces a transcript and one that produces a dataset.

Re-running analysis

Analysis can be re-triggered on a completed run. Use this when:

• You change the question you're asking of the data (different cohort, different theme cut).
• The platform's analysis improves and you want to backfill old runs.
• A theme that didn't seem important at run time becomes important later.

Don't re-run analysis to "get a different answer". The analysis surfaces what's in the transcript. If the data won't support the claim, no amount of re-running will fix that - the interview itself has to be redesigned.

Webhooks and downstream systems

For piping completed runs into downstream systems - warehouse, CRM, BI - use webhooks. See the run-tools reference for the surface. The integrator pattern is straightforward: a webhook fires on run.completed, your service ingests the transcript, structured responses, and analysis identifiers from the payload, and joins the result to your existing pipeline.

What to read next