Meeting Transcript Analyzer

What this system does with a raw transcript

Paste a transcript or point the workflow at a Google Drive file. It extracts features, action items, and insights, then files each one in Jira as the right issue type. A person still runs the meeting and still owns the backlog. The workflow removes the step where someone re-reads the transcript and hand-writes tickets.

1. Step 1Webhook intakePOST transcript text or a Drive file reference
2. ↓→
   Step 2Normalize inputBranch on source, download from Drive when needed
3. ↓→
   Step 3Analyze transcriptOllama Qwen extracts features, actions, insights
4. ↓→
   Step 4Route by typeFeatures become stories, everything else becomes tasks
5. ↓→
   Step 5Create Jira issuesStory or Task with priority and source attached
6. ↓→
   Step 6Return summaryJSON result back to the caller

Problem and design decisions

Meeting notes rot in docs because converting them into tracked work is tedious. This workflow is a reasonable automation candidate: the input is unstructured text, the output is structured records, and the mapping between them follows a stable schema.

One decision matters more than the rest. The LLM never touches Jira directly. It returns JSON with itemType, title, description, and priority. Deterministic Code nodes normalize that output, an IF node routes on itemType, and only then do the Jira nodes run. If the model returns garbage, the failure happens before anything is written.

The model runs locally through Ollama (qwen-3-4b-2507.gguf, temperature 0.3). No transcript leaves the machine that runs n8n. That choice trades raw capability for data control, which is the right trade when transcripts contain internal discussion.

Architecture and technology

The Jira nodes use placeholder project configuration (JIRA_PROJECT_KEY in the export). Target project, issue-type availability, and priority scheme must be set during import. Nothing in the export is production-ready until those values point at a real project.

Detailed operation

1. Intake. POST to the meeting-transcript webhook path with either transcript text or source: "google-drive" plus a file reference. Parse Webhook Input normalizes both shapes into one internal format.

2. Source branch. IF Google Drive File checks the source field. Drive files go through Download from Drive and Extract Text Content. Direct text goes through Set Direct Text. Merge Content reunites both paths so downstream nodes see one shape.

3. Analysis. The Analyze Transcript agent node sends the text to Ollama with a fixed prompt that demands three sections: features (title, description, priority), actions (title, description, priority, assignee), and insights. Normalize & Parse converts the model output into individual items with an itemType field.

4. Routing and filing. IF Feature splits the stream. Features go to Create Feature Ticket (Jira Story). Everything else goes to Create Action Item (Jira Task). Both nodes attach the source, priority, and assignee when present.

5. Summary. Summarize Results builds a short report of what was filed, and Return Results sends it back as JSON.

Code and workflow package

The export lives in this repository at workflows/meeting-transcript-analyzer.json. It is a standard n8n workflow export and imports through the n8n UI or API without conversion.

What to configure after import:

• Jira credentials and the real project key in both Jira nodes.
• Google Drive credentials if Drive intake is needed. Direct-text intake works without them.
• An Ollama instance with the Qwen model available, reachable from n8n.
• Review the webhook responseMode against your needs before relying on the response payload.

Known limits: transcript quality bounds output quality. The workflow does not deduplicate against existing Jira issues, and the export has no retry or logging beyond what n8n provides natively.

Reliability, security, and limits

Transcripts stay local when Ollama runs on your own hardware. Jira and Drive credentials live in n8n credentials, never in the export. The failure mode to plan for is model output that does not parse: keep a human glance over created tickets until the prompt proves stable on your meeting style. Rate limits are a non-issue for typical meeting volume; long transcripts are bounded by the local model's context window, not by an API quota.

Further reading

• Building AI Agent Workflows with n8n and LangChain covers the orchestration pattern behind the agent node.
• AI Agent Workflows explains when an agent step belongs inside a deterministic workflow.
• The AI Workflows shop category holds related downloadable packs.
• To adapt this to your tracker or meeting format, start with Services.