Turn Customer Interviews Into Decisions Your Team Can Use
Turn interview notes into a reviewable decision log without treating a model summary as customer research.
Start with evidence, not a request for themes
This is an interview-synthesis evaluation playbook. First complete the linked Serverless Inference request setup in a server-side client approved by your team. The examples below define what to send and how to review it; they do not deploy a research application.
A pile of call notes is not a research finding. Give each interview a stable ID, the customer segment, the question asked, the exact answer or timestamp, and any limitation. Remove names and details your team does not need before sending a copy to an AI workflow.
Ask the workflow to return a claim, the supporting interview IDs, a short quote, and a confidence note. A claim without a source stays a hypothesis. That single rule keeps a tidy summary from becoming invented certainty.
- Verify the linked setup returns a response for a harmless sample before adding interview data.
- In the same request, replace the sample user message with the synthesis instruction below followed by five approved, anonymized extracts labeled INT-001 through INT-005. Keep the model key in the client’s secret configuration.
- Save the returned text with the five inputs. Parse and inspect the requested JSON; an instruction to return JSON does not guarantee valid JSON. Reject missing IDs, invented quotes, or unsupported findings. Record a human decision only after this check.
Run one small, reviewable synthesis
Serverless Inference fits a small server-side request when interviews arrive unevenly and you do not want to operate an inference endpoint. Put the model access key in your secret manager, send only the approved extracts, and retain the input and response with the study record.
Begin with five interviews from one segment. Compare every proposed theme against the original notes before you add it to a roadmap or a sales deck.
Return JSON only with finding, evidence_ids, supporting_quotes, counterevidence_ids, sample_count and follow_up_question. Report counts only within these five extracts. Do not infer population prevalence. Say insufficient evidence when a claim is unsupported.[
{
"id": "INT-001",
"segment": "operations",
"question": "What happens when you export a report?",
"answer": "I exported twice because I could not tell whether the first run finished."
},
{
"id": "INT-002",
"segment": "operations",
"question": "What happens when you export a report?",
"answer": "I ask support whether my report is still exporting."
},
{
"id": "INT-003",
"segment": "operations",
"question": "What happens when you export a report?",
"answer": "A completion indicator would help me avoid starting another export."
},
{
"id": "INT-004",
"segment": "operations",
"question": "What happens when you export a report?",
"answer": "Our webhook tells us when an export finishes; that works for us."
},
{
"id": "INT-005",
"segment": "operations",
"question": "What happens when you export a report?",
"answer": "I rarely export reports. My problem is editing chart labels."
}
]Separate a pattern from a decision
The model can group language. It cannot decide whether a request fits strategy, contract obligations, or the cost of building it. Keep a decision log with the finding, owner, decision, date, and reason. That makes later reversals understandable instead of embarrassing.
Review disconfirming evidence on purpose. If one customer reports the opposite experience, show it beside the dominant pattern rather than burying it in a summary.
{
"finding": "Three operations leads could not tell which export had failed",
"evidence_ids": ["INT-001", "INT-002", "INT-003"],
"counterevidence_ids": ["INT-004"],
"decision": "Prototype an export-status panel",
"owner": "Product",
"decision_reason": "Repeated operational cost; scope is small",
"review_date": "2026-10-01"
}Compare the notes with the proposed finding
Use a deliberately small before-and-after review before you trust a larger synthesis. The example below is fictional; its job is to show the traceability standard, not to stand in for evidence from your customers.
A reviewer should be able to open the cited notes, see why the finding was proposed, and identify the counterexample without reading the full study again. If the wording becomes stronger than the notes, edit or reject it.
BEFORE — note INT-001
"I exported the report twice because I could not tell whether the first run finished."
PROPOSED FINDING
"Export completion is hard to verify for operations leads."
REVIEW
Supported by INT-001, INT-002, INT-003.
Counterevidence: INT-004 uses an existing webhook successfully.
Decision: investigate a status panel; do not claim all customers need it.Know when this is the wrong tool
Do not use a quick synthesis for regulated interviews, raw call recordings, or a high-stakes customer commitment unless your privacy and legal review permits that data flow. A local or approved research system may be the right answer.
The first successful test is modest: a product manager can trace each proposed finding back to an interview in under a minute. If they cannot, improve the evidence format before increasing volume.
Check your result
- Expected result
- Each proposed pattern links back to source interviews and separates observation from the roadmap decision.
- Stop if
- Reject invented quotes, unknown source IDs or population claims inferred from this small sample.
- Next step
- Review the evidence with the product owner and record the decision separately from the synthesis.