Meeting Transcript to Action Items JSON Prompt Template

This prompt is designed for productivity tool builders who need to extract decisions, action items, owners, and deadlines from meeting transcripts. It converts unstructured or semi-structured transcript text into a clean JSON array of action items with normalized assignee names and standardized dates. Use this prompt when a prior model call or transcription service has produced narrative text instead of structured data, and you need a reliable repair step before inserting records into a task management system, CRM, or project database. This is a post-generation repair prompt, not a real-time meeting assistant.

The ideal user is an integration engineer or backend developer building a pipeline that ingests meeting transcripts from tools like Zoom, Teams, or Gong, and needs to populate downstream systems like Jira, Asana, or Salesforce with structured task records. The prompt expects a raw transcript string as input, along with optional context like a list of known participant names and a target date format. It returns a JSON array where each object represents a single action item with fields for action, assignee, due_date, and confidence. The prompt normalizes assignee names against a provided roster, standardizes dates to ISO 8601, and flags items where the source text is ambiguous.

Do not use this prompt for real-time meeting assistance, live transcription, or conversational agent workflows. It is not designed to handle multi-turn dialogue, speaker diarization, or streaming audio input. It is also not a substitute for a dedicated task extraction model if your transcript volume exceeds hundreds per hour—at that scale, consider fine-tuning a smaller model on your specific meeting format. For high-stakes workflows where missed action items could have legal or financial consequences, always route low-confidence outputs to a human review queue before they enter your system of record.

This prompt template is designed to be the core instruction you send to a language model. It takes a raw meeting transcript and a list of known participants as input and produces a clean, predictable JSON payload. The template uses square-bracket placeholders for all dynamic inputs, allowing you to inject the specific content for each run programmatically. Before using this in production, ensure you have a reliable method for providing the full transcript and a verified list of participants to ground the model's output and prevent hallucinated names.

Below is the copy-ready template. Replace every [PLACEHOLDER] with your actual data before sending it to the model. The [OUTPUT_SCHEMA] placeholder should be replaced with your exact JSON schema definition, and [CONSTRAINTS] should be filled with any specific business rules, such as date formats or required fields.

textCopy
You are an expert executive assistant. Your task is to analyze the provided meeting transcript and extract a list of concrete action items, decisions, and follow-ups.

### INPUT DATA
**Transcript:**
```text
[TRANSCRIPT]

Known Participants (Name, Email):

jsonCopy
[PARTICIPANTS_LIST]

OUTPUT SCHEMA

You must output a single JSON object with a key "action_items" containing an array of objects. Each object must strictly follow this schema:

jsonCopy
[OUTPUT_SCHEMA]

CONSTRAINTS

• [CONSTRAINTS]
• Assignee names MUST exactly match a name from the "Known Participants" list. If an action item's owner is ambiguous or not in the list, set the assignee to "Unassigned" and add a flag.
• All extracted dates must be standardized to ISO 8601 format (YYYY-MM-DD). If a date is relative (e.g., "next Tuesday"), calculate it based on the meeting date provided in the context.
• Do not invent action items that are not explicitly mentioned in the transcript.
• If no action items are found, return an empty "action_items" array.

OUTPUT

jsonCopy
undefined

To adapt this template, start by defining your [OUTPUT_SCHEMA]. A robust schema for action items typically includes fields like id, description, assignee, due_date, status, and source_quote. The [CONSTRAINTS] section is your primary lever for controlling output quality; use it to enforce business logic like "all action items must have a due date within the next quarter" or "categorize each item as Decision, Task, or Information." For high-stakes workflows, always pair this prompt with a post-processing validation step that checks the JSON structure against your schema and verifies that every assignee name exists in your [PARTICIPANTS_LIST] to catch hallucinations before the data enters your system of record.

This prompt is designed to be called after a meeting transcript is finalized, not streamed in real time. The application should first chunk the transcript if it exceeds the model's context window, process each chunk independently, and then deduplicate action items across chunks using a secondary merge prompt or deterministic matching on assignee and task description. The prompt expects a raw transcript string in the [TRANSCRIPT] placeholder and an optional [MEETING_METADATA] object containing fields like meeting_title, meeting_date, and participant_list to improve assignee normalization. If participant context is missing, the model will attempt to infer names from the transcript, but accuracy drops significantly for organizations with similar-sounding names or nicknames.

Wire the prompt into a pipeline with these stages: (1) Pre-processing — strip speaker labels if they contain PII beyond names, normalize timestamps to UTC, and inject the participant list into [MEETING_METADATA] from the calendar invite. (2) Model call — use a model with strong JSON mode support (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) with response_format set to json_object and the output schema provided in the system message. Set temperature=0.1 to reduce variance in task descriptions. (3) Post-processing validation — run a JSON Schema validator against the expected structure: an object with an action_items array where each item has task, assignee, deadline, priority, and source_quote fields. Reject any output where source_quote is not a verbatim substring of the transcript using a fuzzy string match with a minimum similarity threshold of 0.85. Flag items where assignee does not appear in the participant list for human review. (4) Retry logic — if validation fails, retry up to two times with the validation error message appended to the prompt as a [PREVIOUS_ERRORS] block. After two failures, escalate to a human review queue with the raw transcript and partial output attached.

For high-stakes meetings (legal, compliance, executive decisions), always route the final action items through a human approval step before writing to a system of record like Jira, Asana, or a CRM. Log every model call with the transcript hash, prompt version, model identifier, output, validation results, and reviewer decision. This audit trail is essential for debugging hallucinated action items and for demonstrating due diligence if a missed task leads to a dispute. Avoid using this prompt for real-time meeting assistants where latency matters more than accuracy — instead, use a streaming summarization prompt and run this structured extraction as a post-meeting batch job.