Structuring Interview Notes So a Model Can Query Them Later

Each finding becomes one row. Four fields carry the evidence, and a few optional fields make the rows easier to manage.

Four optional fields repay the effort. date lets you answer "what did we hear first." segment (for example enterprise or mid-market) lets you compare groups. prompt records the question that produced the quote, which journalists note as standard practice when verifying a line (convertaudiototext on extracting quotes). strength is a one-word judgment of whether the quote is about past behavior or a future intention, which matters more than it sounds (see the next section).

What you must not put in the quote field: a paraphrase, a summary of three sentences glued together, or your inference. The AP standard is blunt: "We do not alter quotations, even to correct grammatical errors or word usage," and if a quote is flawed, the reporter paraphrases it faithfully instead (AP News Values and Principles, cited by ParrotNotes). Academic style allows an inserted bracket for clarity, but never a silent rewrite (APA on changes to quotations, cited by ParrotNotes). For your store, treat the quote as read only and put your interpretation in a different field.

A fixed topic list is the part teams skip and later regret. Ten to twenty labels that match how you actually ask questions beats an open text field, because "spreadsheet workaround" and "manual spreadsheet process" will never match each other in a search.

The biggest distortion in discovery notes is recording your own strategic interpretation as though it were customer feedback. That is the exact failure the four-layer architecture exists to prevent (Ember).

There is a second reason to keep the quote raw: what people say about the future is a weak signal. Stated-preference research predicts actual purchase behavior with only about 34% accuracy, while behavioral methods reach as high as 89% when properly implemented, and roughly 38% of online shoppers act differently from the behavior they previously stated (Koji on stated vs revealed preferences). Economists have long drawn the same line: reported preference is what people tell a survey, revealed preference is what they actually do, and reported answers can mislead when respondents misremember or mispredict their own behavior (CEPR on reported versus revealed preference). Stated preference remains the only option for products that do not exist yet, and it is the best way to learn the "why" behind a behavior (Koji).

So the decision rule for your store: favor quotes about what the customer did last week over quotes about what they would do with your product. Interviewers are taught not to talk about their idea at all, because the moment it enters the room your interpretations skew toward validation (Customer Dev Labs on customer interviews). A good question set covers the current process, the challenges in it, why they bother, and what they have already tried (Alisa Works on five customer interview questions). Those answers produce past-tense quotes, which are the ones worth storing.

One worked example with numbers. A 60-minute interview typically produces 8 to 15 quote candidates, which a reporter cuts to 4 to 6 final quotes, and full extraction takes most reporters 25 to 35 minutes (convertaudiototext). Run 12 interviews and you have roughly 48 to 72 final quotes. At four fields each, that is a file you can read end to end in an hour and query forever. The alternative, 12 transcripts and a deck, gives you a number on a slide with no way back to the sentence behind it.

Before any row can point to a source, the source has to be navigable. Two things make a transcript usable: real speaker names and timestamps.

A transcript that says "Speaker 1 / Speaker 2" is almost unusable for quote work, so rename speakers immediately while you still remember who spoke (convertaudiototext). Speaker mapping in interview processing tools exists precisely because attribution errors are the common failure (theydo help center on speaker mapping). Timestamps are your verification link: every quote needs one so you can find the audio moment in seconds if the wording is disputed (convertaudiototext).

Then verify. Find the timestamp, play 10 seconds before and after, confirm the words match exactly, note the question that prompted the statement, and decide whether the quote fairly represents the point (convertaudiototext). The most dangerous transcription error is an inverted negative, where "I did not say that" becomes "I said that" (convertaudiototext). If the transcript and audio disagree, the audio wins.

How deep should the transcript go? The GOV.UK guidance, as summarized by Ember, sets out three tiers:

Pick intelligent verbatim for anything that will feed the store, and keep the original audio as your record. For B2B calls, also decide consent and retention up front, since a quote store is personal data about named people (Ember on consent and retention).

A flat file is enough to start. JSON Lines keeps one record per line, which makes diffing and appending easy.

{"speaker":"Dana Whitfield, VP Finance, Northgate Logistics","quote":"We reconcile the invoice export in a spreadsheet because the portal won't export line items.","topic":"spreadsheet_workaround","source":"dana_whitfield_interview.txt#L412","date":"2026-02-11","segment":"enterprise","prompt":"What does your current process look like?","strength":"past_behavior"}

If you prefer SQL, the same row maps cleanly:

CREATE TABLE evidence (
  id INTEGER PRIMARY KEY,
  speaker TEXT NOT NULL,
  quote TEXT NOT NULL,
  topic TEXT NOT NULL,
  source TEXT NOT NULL,
  spoken_on DATE,
  segment TEXT,
  prompt TEXT,
  strength TEXT CHECK (strength IN ('past_behavior','future_intent','opinion'))
);

Then give the model a tool, not a pile of text. In practice that means exposing two functions: search_by_topic(topic) and search_by_speaker(name), both of which return the full rows including the quote. A query like "who mentioned a spreadsheet workaround" becomes a topic filter, and the answer is whatever is in the quote field, untouched.

The prompt matters as much as the schema. Tell the model three things: answer only from the quote field, quote the sentence in full with the attribution, and return the source pointer on every line. Instruct it that if no row matches, it says so rather than guessing. That last instruction is what turns a summary machine into an evidence retrieval machine.

For fetching the model itself, a single endpoint across text and embedding models removes a layer of plumbing: Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which is handy when the same store needs a text model for answers and an embedding model for fuzzy search over quote text.

A useful pattern is a hybrid: exact filter on topic, then embedding search over the quote column for questions like "where did anyone describe a workaround." Exact match gives you precision, vectors give you recall.

You want to know who mentioned a spreadsheet workaround and what they said.

1. A product manager asks the assistant: "Who mentioned a spreadsheet workaround? Give me the exact quote and where it came from."
2. The model calls search_by_topic("spreadsheet_workaround").
3. The tool returns three rows: Dana Whitfield, Tomas Reyes, and a third from a mid-market call.
4. The model answers with each verbatim quote, the speaker's name and role, and the file-and-line pointer.

Expected output shape:

Dana Whitfield (VP Finance, Northgate Logistics), dana_whitfield_interview.txt#L412:
"We reconcile the invoice export in a spreadsheet because the portal won't export line items."

Tomas Reyes (Ops Manager, Halden Freight), tomas_reyes_interview.txt#L188:
"I keep a shadow sheet with the line items, because by the time the portal updates I've already been asked twice."

Note what the model did not do: it did not write "customers want better exports." That sentence is a finding, and findings belong in a separate layer built on top of these rows (Ember). If someone challenges the export roadmap later, you open line 412 and play the audio.

The same store answers harder questions: how many speakers across how many segments raised the same topic, which is a count over rows rather than a remembered impression. One caution: a count of quotes is not a count of demand. Stated enthusiasm overstates action, and the store should label strength so a reader can see whether a quote describes something the customer did or something they said they would do (Koji).

• Paraphrasing inside the quote field. Check by searching for quotation marks that do not appear in the transcript.
• Free-text topics. If your topic column has 40 unique values across 50 rows, the list is not fixed. Collapse it.
• Pointers that do not resolve. Run a script that opens each source file and confirms the line exists.
• Merging two customers into one row ("several users said..."). Split it.
• Letting the model summarize. Read the prompt, not just the output.
• Storing only the quotes you liked. The negative cases are the ones you will need next quarter, and the discipline of capturing evidence is what turns a discussion into something a new teammate can interrogate (Ember).
• Ignoring the say-do gap. Tag future-intent quotes and treat them as hypotheses, not proof (CEPR).

If building the loader, the schema migration, and the query tool is the part that keeps slipping, that is a concrete build with a clear spec. You can describe the store you want and a specialist will build it with you at Quanta. And if you would rather have someone run the synthesis and hand back the review-ready evidence file, an expert will read your context and deliver the finished artifact through Quanta Experts.