How to write AI prompts that summarize interview transcripts accurately

The best AI prompt for summarizing interview transcripts asks the model to extract evidence before writing, keep quotes verbatim, preserve speaker labels, separate stated facts from inference, and mark missing information instead of guessing. Use a fixed output schema for themes, decisions, and action items, then verify every quote against the source.

What is the best prompt to summarize an interview transcript?

The prompt puts the transcript above the instructions and makes the model pull exact passages before it writes anything, which follows Anthropic’s published guidance to place long documents near the top of the prompt and ask for relevant quotes before the main task. Paste it as written, replace the two bracketed placeholders, and leave the section headings alone. The review steps later in this article depend on those headings.

You are a research analyst summarizing a recorded interview for a team that was not in the room. You work only from the transcript below. You never add facts, names, numbers, or opinions that do not appear in it.

<transcript>
[PASTE TRANSCRIPT HERE. Format: one speaker turn per line, each prefixed with a speaker label such as INTERVIEWER: or PARTICIPANT_1: and a timestamp if available]
</transcript>

Interview context: [one sentence: who was interviewed, why, and what decision this summary feeds]

Before writing anything, extract every passage you intend to rely on as an exact quote, with its speaker label and timestamp. Use only those extracts in the steps that follow.

Produce the following sections, in this order, using these exact headings:

1. Summary
Three to five sentences covering who spoke, what was discussed, and the single most consequential thing said. No interpretation beyond what a speaker stated.

2. Key themes
Three to six themes. For each: a one-line name, a two-sentence description, and the speaker label(s) who raised it. Tag each theme "stated" if a speaker said it directly or "inferred" if you are reading it into their words.

3. Verbatim quotes
Five to ten quotes, copied character for character from the transcript. Format: [SPEAKER_LABEL] [timestamp]: "exact words". Do not fix grammar, shorten, merge two passages, or remove filler inside the quotation marks. If you must shorten, use [...] and never cut words that change meaning.

4. Decisions
Any decision a speaker stated as made or agreed, with the speaker label and the quote it rests on. If none, write "None stated."

5. Action items
One line per item: owner (a speaker label or a role named in the transcript) / task / due date if stated / source quote. If no owner was named, write "Owner not stated."

Constraints:
- If the transcript does not contain what a section asks for, write "Not in transcript." Never fill a gap with a plausible guess.
- Never attribute a quote to a speaker unless the label appears on that turn. If attribution is ambiguous (crosstalk, unlabeled turn), write [UNCLEAR SPEAKER].
- Total length: 400 to 700 words excluding the quotes section.
- Output plain Markdown. No tables. No preamble or closing commentary.
- Finish with one line: "Sections marked Not in transcript: [list]" so a reviewer can see the gaps at a glance.

The “stated” versus “inferred” tag and the closing gap line are the two pieces people cut first when they trim this prompt. Keep both. The tag is what separates participant evidence from model interpretation when you review, and the gap line tells you which sections need a second read of the source before you trust them.

What does every transcript summary prompt need?

Each part of the master prompt fixes a specific failure, so you can adapt any one of them once you know what it is guarding against.

• Role: “Research analyst writing for people who were not in the room” sets a report register instead of a chat register and makes missing information an expected outcome rather than an awkward one. Swap in “recruiter”, “reporter”, or “chief of staff” for the variants below, but keep the analyst framing.
• Input: The transcript sits inside delimiters, above the instructions, with one labeled turn per line. Delimiters stop the model from reading an interviewee’s “so summarize what I said” as a command, and placing the document first is the placement Anthropic’s docs recommend for long inputs.
• Output schema: Five numbered sections with exact headings mean you can diff two runs, or two models, line by line. A free-form summary can only be compared by feel.
• Quote rule: Extract first, then summarize from the extracts. In Anthropic’s long-context testing, pulling relevant quotes into a scratchpad before answering helped in every head-to-head comparison and lifted Claude 2’s accuracy from 0.939 to 0.961, a 36% cut in errors.
• Length limit: 400 to 700 words excluding quotes. With no ceiling the model pads with restatement. With a ceiling set too low it drops the decisions section first, because decisions are the shortest section and look expendable.
• No-invention clause: “Not in transcript” gives the model a sanctioned way to say nothing. Without a permitted empty answer, an action-items section with no action items tends to acquire plausible ones.

The roster format, the glossary, the role tags, and the rubrics you build for the variants below are context artifacts: store them once and paste the prompt as the invocation point.

How should the prompt change by interview type?

The master prompt handles any interview, but each interview type has one constraint the generic version leaves loose, and the swaps below tighten it.

How should you summarize hiring interviews?

Hiring transcripts need scored dimensions tied to STAR components, with a hard rule that the model scores only what it can quote. Replace sections 2 through 5 of the master prompt with the two sections below (Decisions and Action items are dropped for hiring) and paste your rubric where indicated.

2. Competency evidence
For each competency in the rubric, list the Situation, Task, Action, and Result the candidate described, each with an exact quote and timestamp. If a STAR component is missing, write "Not described." Do not infer it.

3. Scores
Score each competency 1 to 4 using only the rubric anchors supplied. Every score must cite at least one quote from section 2. Do not score fluency, confidence, accent, hesitation, tone, or emotion. Do not penalize hedged phrasing.

Rubric: [paste competencies with a behavioral anchor for each score level]

How should you summarize user research interviews?

User research needs pain points in the participant’s own words, a voice-of-customer list you can lift into copy, and a strict stated-versus-inferred split on themes. Replace section 2 and add a sixth section.

2. Pain points
For each pain point: the participant's exact words (quote, speaker label, timestamp), the workflow moment it occurred in, and any workaround they described. Tag each "stated" or "inferred".

6. Voice of customer
Ten to fifteen short exact phrases the participant used for the problem, the product category, or competitors, one per line with timestamp. Do not normalize their vocabulary.

How should you summarize journalistic interviews?

Journalistic transcripts need three things the generic prompt does not separate: quotes that survive a check against the audio, a list of factual claims to verify, and candidate angles clearly labeled as the model’s inference. Replace section 4 and add a sixth section.

4. Factual claims to verify
Every checkable assertion the subject made (numbers, dates, names, events), each with the exact quote, speaker label, and timestamp. Do not assess whether the claim is true.

6. Angles
Two or three possible story angles, each pointing to the quotes in section 3 that support it. Label this section as your inference.

The BBC’s test of AI assistants found 13% of quotes the assistants attributed to BBC articles were altered or absent, and 51% of answers had significant accuracy problems. Anything you plan to publish inside quotation marks goes back to the recording, not the transcript, before it runs.

How should you summarize meeting transcripts?

Yes, the master prompt works on meeting transcripts with three changes: drop sections 2 and 3, tighten section 5, and add open questions. Meetings typically state decisions and action items out loud, which suits the schema.

5. Action items
One line per item: owner (must be a speaker label or a name spoken in the transcript) / task in the owner's words / due date if stated / exact quote. Never assign an owner the transcript did not name.

6. Open questions
Anything raised and left unresolved, with who raised it and the quote.

Meeting summaries fail when the model resolves “someone should look at that” into a name. The owner rule prevents the person who never agreed to the task from finding it on their list Monday.

Should you clean the transcript before summarizing it?

Yes, clean the transcript before you summarize it, because a summary prompt faithfully summarizes whatever errors the raw ASR output carries. Those errors fall unevenly across speakers. Across five commercial ASR systems, word error rate averaged 0.35 for Black speakers against 0.19 for white speakers, and diarization errors routinely hand one speaker’s sentence to another. Run this pre-prompt first, then feed its output to the master prompt.

You are a transcript editor. Edit the transcript below for readability without changing meaning.

1. Remove filler ("um", "uh", "you know", "like" used as filler), false starts, and immediate repetitions. Keep hedges ("I think", "maybe", "sort of") because they carry meaning.
2. Fix a speech-recognition error only when the correction is unambiguous from context or appears in the glossary. Otherwise leave the word and append [?].
3. Normalize speaker labels to the roster. If a turn's speaker is unclear, label it [UNCLEAR SPEAKER]. Never merge two speakers' turns.
4. Replace every personal name, company name, email address, phone number, and location with the role tag from the roster. For names not on the roster, use [PERSON_1], [PERSON_2], and list them at the end.
5. Add punctuation and sentence breaks. Do not paraphrase, reorder, or delete any sentence.
6. Output the edited transcript, then a change log of every rule-2 correction and every [?] added.

Glossary: [product names, acronyms, job titles]
Roster: [Speaker 1 = INTERVIEWER, Speaker 2 = PARTICIPANT_1 (head of ops, 40-person logistics company)]

<transcript>
[PASTE RAW TRANSCRIPT]
</transcript>

Rule 2 is deliberately conservative. Asked to “fix errors,” a model will produce grammatical sentences that drift from what was said, and you have no audio in the prompt to catch it. Flagging with [?] pushes the doubtful spans back to you for an audio check.

Rule 4 is a backstop, not the redaction step. Once a name has been pasted into a consumer chat tool the model has already seen it, so do the primary name replacement locally with find-and-replace and keep the name-to-tag mapping in a file the model never receives. The pre-prompt catches the names you missed.

How do you keep quotes exact and speakers attributed?

Quote fabrication is the highest-risk failure in AI transcript summaries, so the quote rule is a constraint on the entire output rather than one section of it. In a controlled study, Copilot fabricated quotes in 44.5% of cases and modified them in another 9.3%, while human researchers quoted accurately 79% of the time. The master prompt’s extract-first step and character-for-character rule target that number directly.

Take a made-up excerpt from a cleaned user interview, with the role tags and timestamps the pre-prompt leaves in place:

PARTICIPANT_1 [00:14:22]: So the export thing, we gave up on it. It worked, but it took, I don't know, forty minutes every Friday and half the time the file was missing the last week's rows. So now [OPS_ANALYST] does it by hand.
INTERVIEWER [00:14:41]: By hand meaning?
PARTICIPANT_1 [00:14:43]: Copy paste out of the dashboard into a sheet. Which is insane, but it's faster.

The fabrication pattern the studies describe looks like a summary line such as: the participant said the export “took about 40 minutes and frequently dropped rows,” so an analyst now exports manually. Nothing inside those quotation marks appears in the transcript. Two passages have been blended, “half the time” has become “frequently,” and the speaker who does the manual work has lost their tag.

Under the master prompt, the same passage comes out as two entries in section 3:

[PARTICIPANT_1] [00:14:22]: "it took, I don't know, forty minutes every Friday and half the time the file was missing the last week's rows."
[PARTICIPANT_1] [00:14:43]: "Copy paste out of the dashboard into a sheet. Which is insane, but it's faster."

Every turn needs a label and timestamp because the model can only copy attribution that exists in the input. Verify each quote with a text search in the source file. It takes a few seconds per quote and catches blends that read plausibly.

How should you compare ChatGPT, Claude, and Gemini?

No published benchmark tests current flagship ChatGPT, Claude, and Gemini models on interview transcripts. The useful comparison is to run the master prompt yourself on one transcript and check three provider-level differences, covered below in order: faithfulness to the source, preferred prompt layout, and how accurately each output handles quotes, speakers, and gaps.

The providers also disagree on prompt layout. Anthropic’s guidance puts the document at the top with instructions below, while Google’s long-context guidance recommends putting the question at the end of the prompt in most cases. The master prompt satisfies both by leading with the transcript and closing with the constraints.

To run your own side-by-side, pick one cleaned transcript you have read in full and score each tool’s output on four counts:

• Quotes not found: Count every quote that a text search of the transcript fails to match.
• Blended quotes: Count every quote that merges two separate passages into one.
• Misattributed labels: Count every quote whose speaker label differs from the label on the matching turn.
• False gaps: Count every section that said “Not in transcript” when the information was there. This count matters as much as the fabrications. A model that refuses too often is a model you stop trusting on the gaps it does flag.

Run each tool with identical prompt text and the same cleaned transcript, and repeat the comparison when a provider ships a new flagship model.

Can AI summarize a transcript accurately or does it make things up?

Current models produce accurate transcript summaries most of the time and unfaithful claims some of the time, and no prompt gets the second number to zero. The failure modes cluster in three places: quotes that blend or drift, attributions that shift between speakers, and summaries that overgeneralize what one participant said into what participants think.

Overgeneralization is harder to catch than quote drift. A Royal Society Open Science study found LLM summaries of scientific papers were nearly five times more likely than human summaries to contain overgeneralizations, and adding an “accuracy” instruction roughly doubled the generalization rate. Telling the model to be accurate does not work. Telling it to tag “stated” versus “inferred” and write “Not in transcript” gives it a mechanism instead of an aspiration.

Verification is a fixed step after every run, with four checks:

• Quote search: Paste each quote from section 3 into a text search on the cleaned transcript. Anything that returns no match is fabricated or blended.
• Attribution spot-check: For each quote, confirm the speaker label on the matching turn. Diarization errors upstream will have moved lines between speakers.
• Owner check: Every action-item owner must appear as a speaker label or a name spoken in the transcript.
• Gap line: Read the “Sections marked Not in transcript” line and reread the source for each listed section.

Summarize manually when verification would cost more than the summary saves. Nielsen Norman Group’s review of AI research tools makes the point that fact-checking AI output gets harder as datasets grow, and in some cases a human doing the task is faster than a human verifying the machine’s version. A 20-minute transcript you have already listened to twice is one of those cases. So is any hiring decision, and any interview with a source who could be harmed by a misattributed line.

What should you redact before pasting an interview into an AI tool?

Every consumer chat tier from the three major providers uses pasted content for training by default, so the redaction step and the settings step both happen before the first paste. Strip names, employers, email addresses, phone numbers, street addresses, account numbers, and any health, political, religious, union, or sexual-orientation detail unless it is the subject of the research. Those last categories are GDPR special-category data, and France’s data regulator advises never sharing personal data through a public generative AI service. Your organization is the controller for the interviewee’s data, the AI provider is at best a processor under a signed DPA, and consumer terms do not give you one.

Consent is the other half. Tell interviewees in the consent form that an AI tool will process the transcript, and disclose it in the research write-up.

The provider settings, as of their current policy pages:

• ChatGPT: Turn off “Improve the model for everyone” under Settings, then Data Controls, or use Temporary Chat, which is excluded from training and auto-deletes within 30 days.
• Claude: Consumer inputs moved to an opt-out training model in July 2026. Turn off “Help Improve our AI models” under Settings, then Privacy, or use Incognito chats, which are held 30 days and never trained on.
• Gemini: “Keep Activity” is on by default for adults with an 18-month auto-delete, and a sample of uploads is used for training while it is on. Toggle it off at myactivity.google.com/product/gemini, or use Temporary Chat.

Business, Enterprise, Workspace, and paid API tiers from all three providers do not train on customer data by default. Gemini’s unpaid API tier does use content to improve Google products. If you run interviews regularly, a paid team plan with a DPA removes the training risk, but redaction still applies because data minimization does not depend on the tier.

When is a generic summary prompt the wrong tool?

A generic summary prompt fails at two jobs that look like summarization and are not. The first is vertical analysis: scoring one transcript against defined dimensions, as in hiring, sales-call QA, or a rubric-based usability test. The second is horizontal synthesis: finding what twenty transcripts say together.

Vertical analysis needs a codebook or rubric with examples, supplied in the prompt, and the model scores only against it. Research on GPT-3 found that a human-defined codebook and coding examples improved deductive coding accuracy. The hiring variant above is the pattern. Build the rubric once as a context artifact and reuse it across every transcript in the batch.

Horizontal synthesis runs on the structured outputs of the master prompt, never on a pile of raw transcripts. Run each interview through the prompt with participant tags intact, then feed the section 2 and section 3 outputs from all of them into a synthesis prompt that counts how many participants stated each theme, lists the supporting quotes with participant tags, and flags themes only one participant raised. This is the step where the model’s weakness at latent meaning bites hardest, so the human reads the cross-participant themes as candidates and pulls the quotes to confirm or kill each one.

If you do neither of those jobs, the master prompt is the tool. If you do either, the master prompt is the first pass that produces the inputs, and the rubric or the synthesis prompt is where the judgment call lives.

The rubric, the codebook, the roster, and the synthesis prompt are the pieces you build once and reuse across every interview you run. The Vault has the template that operationalizes this: the Prompting Playbook is built on the same context engineering approach and drops into your existing stack, alongside a community of operators running the same workflows.