A 60-minute product call generates one hour of audio, three people's half-finished notes, and zero authoritative record of what was decided. Action items get assigned in the room and unassigned by the time Slack opens. The context behind a technical decision lives in whoever's memory survives the week.
For teams where standard meeting tools cover the job, they're the right choice. This guide is for teams they don't cover: data-residency requirements that need explicit routing control, Slack and Notion configurations that don't match a tool's built-in integration, or internal systems that need structured transcript data rather than a hosted notes UI. A build-once pipeline on Gladia routes accurate, speaker-labeled transcripts exactly where your stack needs them, without adapting your workflow to a tool's assumptions.
This guide walks through connecting Zoom or Google Meet to our platform via Make.com, using our async transcription and pyannoteAI-powered diarization to extract decisions, map speakers to real team members, and thread action items in Slack with precise @mentions, while logging the full transcript to Notion automatically.
Why automate meeting notes with transcription and AI
Off-the-shelf meeting tools handle the common case well. Where they tend to fall short is at the edges: teams that need to route transcripts to internal systems the tool doesn't integrate with, organizations where audio data must stay within specific infrastructure boundaries, and workflows where the downstream action (a CRM write, a sprint board update, a compliance log) requires structured data rather than a hosted summary.
Building on our platform flips that equation. You choose the LLM, control where data lands, and pay per hour of audio processed rather than per seat. On Growth and Enterprise plans, we never use your audio to retrain models and no opt-out action is required. The compliance details cover SOC 2 Type II, ISO 27001, HIPAA, and GDPR.
Incomplete manual notes obscure decisions
When notes are taken manually, they reflect whatever the note-taker captured rather than what was decided. For a product team where every sprint decision has downstream engineering implications, degraded context doesn't just waste time. It re-opens resolved questions and introduces rework. Automating the documentation layer means every call produces a structured, searchable record the moment it ends.
Ensure correct speaker labeling
Standard transcription APIs return a wall of text with no speaker attribution or, worse, inconsistent speaker labels that shift mid-transcript. That breaks the only workflow that matters here: assigning action items to the right person. Our speaker diarization, powered by pyannoteAI's Precision-2 model, segments the audio by speaker identity and returns consistent labels ("speaker": 0, "speaker": 1) tied to word-level timestamps throughout the full recording. Because diarization runs on the complete audio file in async mode, it has full context rather than a rolling window, and that full-context analysis improves label consistency across long, multi-speaker calls.
Automated workflow saves hours per week
As an illustration, a team running eight meetings a week, each taking 30 minutes to document, spends four hours a week on work a Make.com scenario handles automatically. The gain compounds on the workflows that matter most: product discovery calls where every customer insight needs to feed a Notion decision log, sprint planning sessions where action items need to reach engineers in Slack before the day ends, and QBRs where executives need a summary before the follow-up email thread starts.
How the automated meeting notes workflow works
The scenario chains five modules: a recording trigger, a transcription call, an LLM extraction step, a Slack post with threaded action items, and a Notion database write. Each step passes structured JSON to the next, so there's no fragile text parsing between modules.
1. Trigger: Zoom or Google Meet recording completes
Google Meet recordings land in Google Drive when the meeting ends. Zoom cloud recordings stay in Zoom cloud storage, so use a Zoom webhook trigger or sync recordings to Drive first. Use the Make.com Google Drive module with the "Watch for new files in a folder" trigger, pointed at the folder where recordings are saved. The trigger fires when a new recording file appears and passes the file ID and download URL downstream. For immediate execution rather than polling, use a Zoom webhook trigger so the scenario fires the moment the recording is processed.
2. Transcribing meetings with async diarization
Our async transcription module receives the recording URL and processes the full file before returning results. This full-context processing is what enables reliable diarization across the entire call rather than speaker attribution that resets or drifts in windowed segments.
For multilingual product teams, the coverage depth matters: we support 100+ languages, and we handle code-switching mid-conversation without breaking the session or degrading the transcript. If your discovery calls shift between English and French or your engineering team switches languages in sprint planning, the transcript reflects that accurately.
3. LLM extracts key meeting outputs
We return structured JSON with the full transcript, word-level timestamps, and speaker labels on every utterance. That structured output feeds directly into an OpenAI or Anthropic module in Make.com via the Audio-to-LLM pipeline. The LLM doesn't receive raw audio or need to interpret degraded text. It receives an accurate, labeled transcript and runs extraction against a precise input. Here is a sample prompt structure that produces consistent JSON output:
```
You are a meeting documentation assistant.
Given the following diarized transcript, return a JSON object with:
{
"summary": "2-3 sentence meeting overview",
"decisions": ["Decision 1", "Decision 2"],
"action_items": [
{"task": "Specific action", "owner": "speaker", "deadline": "if mentioned"}
]
}
Transcript: [INSERT_DIARIZED_TRANSCRIPT]
```
Because the transcript is accurate, the LLM isn't hallucinating speaker intent or inventing context. The extraction quality ceiling is set by transcription quality, and that's where our 6.4% WER on Earnings22 business audio (Solaria-3) compounds into better summaries and cleaner action item lists.
4. Route outputs to Slack and Notion
The Make.com Router module splits the LLM output into two paths. Path one handles the Slack notification flow: a parent message with the meeting summary and decisions, followed by threaded replies for each action item with the assigned owner's @mention. Path two writes the full transcript and summary to Notion. The threading pattern keeps Slack channels scannable rather than flooded with individual messages for every task.
5. Notion: centralized full meeting notes
The Notion path creates a new database item for each meeting, writing the full diarized transcript, the LLM-generated summary, participant list, and meeting date as structured properties. Teams searching for the context behind a decision made three weeks ago can query a structured database rather than hunting through a chat history.
Configure Gladia for Make.com workflows
There are two ways to call Gladia from Make.com. The community-built Gladia app in the Make.com app directory is the fastest way to get a working scenario running, useful for prototyping or evaluating the workflow. For production deployments, use Make.com's native HTTP module instead. The HTTP module gives you full control over request headers, body structure, and response parsing, and it does not depend on a third-party app's maintenance cycle. The configuration steps below cover both paths. If you are building something you will run at scale, start with the HTTP module section.
Path 1 (quickstart): Community app
- Create a Gladia account and claim your 10 free hours on the Starter plan (on Starter, audio data can be used for model training by default, Growth and Enterprise plans exclude this).
- Copy your API key from the Gladia dashboard under API Keys.
- Add the Gladia app to your Make.com organization from the app directory.
- Create a new connection in Make.com, select Gladia, and paste your API key when prompted.
The connection is reusable across all scenarios in your organization, so you configure authentication once and reference it in any workflow that calls Gladia.
Path 2 (production): HTTP module
For production pipelines, replace the Gladia community app module with Make.com's built-in HTTP module. Add an HTTP module after your recording trigger, set the method to POST, and enter https://api.gladia.io/v2/pre-recorded as the URL. Under Headers, add x-gladia-key with your API key as the value and Content-Type set to application/json. In the Request Body field, set the type to Raw and paste a JSON body with audio_url mapped to the recording URL from your trigger, diarization set to true, and a language_config object for language handling, for example, "language_config": {"languages": [], "code_switching": true} enables automatic language detection with code-switching support across all detected languages. This module returns a transcription ID in the response body (id). Pass that ID to a second HTTP module configured as a GET request to https://api.gladia.io/v2/pre-recorded/{id} with the same x-gladia-key header, using the Watch/poll pattern described in the async workflow steps below. The HTTP module response structure is identical to the community app output, so all downstream LLM, Slack, and Notion modules remain unchanged.
Set up async transcription workflow (applies to both paths)
Whether you use the community app or the HTTP module, the polling pattern and downstream JSON structure are the same. On Path 2, the "Watch Transcriptions" module maps to a Make.com Repeater module configured for a fixed number of retries, followed by a Router or Filter module that checks whether the status field in the GET response equals done and breaks the loop when that condition is met. The sleep-plus-poll pattern maps to the sleep module followed by the second HTTP GET call already described above in the HTTP module section.
In the Make.com scenario builder, add the Gladia module after your recording trigger and select "Create a Transcription" as the action. Map the audio URL from the trigger output to the Audio URL field, set language detection to "Automatic" unless your meetings are always in a single known language, and toggle diarization to "True". Optional parameters include translation for cross-language summaries and sentiment analysis, derived from transcript text rather than vocal tone. This module submits the transcription job and returns a transcription ID. It does not return the completed transcript.
You need a second step to retrieve the result, following one of two patterns. Use the "Watch Transcriptions" module as a trigger that fires when a transcription status changes to completed, or add a sleep module (set to 60–90 seconds for a typical hour-long meeting) followed by a "Get a Transcription Result" module that takes the transcription ID from the first step as its input. The Watch Transcriptions pattern is more reliable for variable-length recordings, while the sleep-plus-poll pattern is simpler to configure and adequate when recording durations are consistent. Either way, the "Get a Transcription Result" module returns the full diarized transcript as structured JSON, which you pass downstream to the LLM step.
Set up accurate speaker attribution
With diarization set to "True", we return each transcript segment with a "speaker" field ("speaker": 0, "speaker": 1, etc.) alongside the text and timestamps. These labels are consistent throughout the full recording because the pyannoteAI Precision-2 model analyzes the complete audio before assigning identities, rather than attributing speakers incrementally.
Automate action items for clear accountability
Accurate speaker labels from our diarization are necessary but not sufficient. You still need to translate "speaker": 0 into a Slack user ID before you can @mention the right person. Make.com provides two clean approaches for this.
Map speaker labels to team member names
Use a Make.com Data Store as a lookup table. Create a data store with two columns: "speaker" label (e.g., "speaker": 0) and slack_user_id (e.g., "U0123ABCD"). Populate it manually for recurring meeting participants or pull attendee data from the Google Calendar event that triggered the recording.
For dynamic mapping, retrieve the meeting's calendar invite participants in the first module of your scenario and order them by their join sequence. In clean recordings where speakers take turns without significant overlap, speaker labels generally follow speaking order, so the first person to speak becomes "speaker": 0. Matching calendar attendee order to speaker order gives you a programmatic mapping without a manual lookup table, though you should validate the mapping for meetings with frequent interruptions or simultaneous speech.
Precise task and owner assignment with AI
Pass the diarized transcript to the LLM with speaker labels intact and include the speaker-to-name mapping in the prompt context. Structure the prompt so the LLM returns a JSON array Make.com can iterate over:
```
Speaker mapping: {"speaker"speaker_0": "Alice Chen", "speaker""speaker_1": "Ben Marsh"}
From the transcript below, extract action items as JSON:
[{"task": "string", "owner": "name from mapping", "deadline": "string or null"}]
Transcript: [INSERT_DIARIZED_TRANSCRIPT]
```
This prompt pattern produces clean, iterable output and eliminates the ambiguity of a natural language task list. Each element in the array becomes one Slack thread reply.
Assign action items in Slack threads
Use Make.com's Iterator module to loop through the action_items array from the LLM output. For each item, look up the owner's Slack user ID from your data store and compose the message with the @mention embedded. Set the same channel ID as the parent summary message on this module, and set the "Thread TS" field to the timestamp of that parent message, the ts output variable produced in the "Automate key takeaway posts to Slack" step below.
Deploy transcripts to Slack and Notion
Automate key takeaway posts to Slack
Configure the Slack "Create a Message" module with the channel ID for your team's meeting notes channel. Compose the message body using the LLM's summary and decisions fields and include the meeting title and date as the message header. Save the output ts variable from this module, as it becomes the thread_ts for all subsequent action item replies.
Log complete meeting transcripts to Notion
In the Notion "Create a Database Item" module:
- Select your meetings database using the database ID from the Notion URL
- Map the Title property to the meeting name from the calendar event
- Map a Text property named "Summary" to the LLM summary output
- Map a Text property named "Full Transcript" to the complete transcript JSON or formatted text
- Map a Date property to the meeting date
- Map a Text property named "Participants" to the attendee list from the calendar invite
Your full Gladia-Make integration recipe
The complete scenario runs: Google Drive "Watch for new files" trigger, Gladia "Transcribe Audio (Async)" module, OpenAI or Anthropic "Create a Completion" module, Router splitting to two paths, Slack "Create a Message" for the summary, Iterator over action items with Slack "Create a Message" threading, and Notion "Create a Database Item". Add a Data Store lookup and calendar attendee fetch module depending on your speaker mapping approach.
Access your Gladia-Make integration
Search for "Gladia" in the Make.com app directory to get started. For support questions, reach our team directly through the Gladia Slack community or through our documentation.
Handle common failure modes
A few failure modes to handle before going to production:
- File size: We accept files up to 1000MB and 135 minutes. For longer sessions like workshops or all-hands recordings, add an audio splitter module upstream or use a URL-based input pointing to the cloud recording directly.
- Unsupported formats: We accept WAV, M4A, FLAC, and AAC. If your recording platform outputs video containers such as mp4 or mov, extract the audio track first using a Make.com media conversion module or a tool like FFmpeg before passing the file to the transcription module.
- Error handling: Add an error handler route to each module that sends a Slack notification with the file name and error message if any step fails. This prevents silent failures where no Notion page is created and no one notices for days.
- Teams recordings: Microsoft Teams stores recordings in OneDrive for private meetings and in SharePoint for channel meetings. Replace the Google Drive trigger with a OneDrive or SharePoint "Watch for new files in a folder" trigger pointed at the Teams Recordings folder. Every subsequent module is identical to the Zoom or Google Meet path.
Run your first Gladia workflow
Start with €50 in free credit on the Starter plan, copy your API key, and set up the Make.com connection. Run the scenario against a test recording and verify the Slack thread and Notion page appear correctly before going to production. Most teams are live in under a day, and our engineers are available on Slack if configuration questions come up.
FAQs
How do I optimize diarization for accurate @mentions?
Use individual microphones for each participant rather than a shared room mic and minimize cross-talk where speakers overlap. Diarization, powered by pyannoteAI's Precision-2 model, achieves on average 3x lower DER (Solaria-1, per the async benchmark) than alternatives on clean multi-speaker audio, and audio quality is the primary variable you control on your end.
What's the processing time for a 60-minute meeting?
Based on the Claap case study, our async pipeline processes a 60-minute meeting into a complete diarized transcript in under 60 seconds of wall-clock time. Total pipeline time extends beyond the Gladia transcription step to include Make.com module execution and any LLM API calls in your scenario.
How do I route Teams meeting audio through this workflow?
Replace the Google Drive trigger with a OneDrive or SharePoint "Watch for new files in a folder" trigger in Make.com, pointed at the folder where Teams saves recordings: OneDrive for private meetings and the associated SharePoint site for channel meetings. Every subsequent module (Gladia, LLM, Slack, Notion) is identical to the Zoom or Google Meet path.
What does this workflow cost at scale?
We bill per hour of audio duration at publicly listed rates with all intelligence features included in the base rate on Starter plans ($0.61 per hour) and Growth plans (as low as $0.20 per hour). Growth pricing requires an upfront volume commitment and customer data is never used for model training on Growth and Enterprise plans. Add Make.com operations costs and LLM API fees (OpenAI or Anthropic) separately when modeling total pipeline cost. At 10,000 hours per month on Growth, the audio infrastructure cost is as low as $2,000/month at the highest commitment tier, with diarization, translation, NER, and sentiment analysis all included.
Key terms glossary
Diarization: The process of segmenting an audio recording by speaker identity to determine who spoke when, used in meeting transcription to attribute every utterance to a labeled speaker ("speaker": 0, "speaker": 1). Our implementation uses pyannoteAI's Precision-2 model and is available in async workflows only.
Diarization error rate (DER): A metric that measures speaker attribution accuracy by comparing the system's speaker labels against a reference transcript. Lower DER indicates more accurate speaker identification.
Async transcription: Speech-to-text processing of a complete pre-recorded audio file rather than a live stream, where the model analyzes the full audio before returning results. This full-context approach improves accuracy, diarization stability, and multilingual handling compared to streaming transcription.
Word error rate (WER): A metric that measures transcription accuracy by counting substitutions, deletions, and insertions relative to a reference transcript, expressed as a percentage. We publish WER methodology with open and reproducible benchmark conditions across 7 datasets and 8 providers.
Code-switching: The behavior of speakers alternating between two or more languages within a single conversation. Our code-switching detection handles mid-conversation language changes across all 100+ supported languages without breaking the transcript session or requiring a separate language detection step.
