How to Automate HR Interview Transcription with Make.com and AI

You automate HR interview transcription by connecting a cloud storage trigger in Make.com™ to an AI transcription API, routing the output through GPT for structured summarization, and writing the result directly to your ATS, all without manual re-entry. A properly built workflow processes each interview in under five minutes once it is running.

Before You Start

Build the prerequisites before you open the scenario builder – skipping this step wastes the entire build session.

• A governed cloud storage location where interview recordings land consistently – one bucket, one folder convention, owned by HR or IT. Do not build on ad hoc storage.
• An API key for a transcription service – Google Cloud Speech-to-Text, Azure Cognitive Services Speech, or OpenAI Whisper. Provision and test it before building.
• An OpenAI API key for GPT-powered summarization.
• Confirmed ATS write access – verify your ATS supports inbound API writes and that you have the field mapping documented. This is the step most teams skip and regret.
• Data governance sign-off – confirm which data stores are approved for audio and transcript retention. Do not improvise compliance mid-build. See HR data governance mistakes to avoid for the compliance architecture to have in place first.
• Time budget: 4-8 hours for a working proof-of-concept; 2-3 days for a production-ready workflow with error handling.
• Risk acknowledgment: AI-generated transcripts contain errors, especially with heavy accents, crosstalk, or poor audio quality. Plan a human spot-check step from day one. Do not remove it until you have confirmed error rates against your own audio library.

Step 1 – Map Your Data Flow Before Touching Make.com™

Draw the complete recording-to-ATS handoff on a whiteboard before you open the scenario builder – this step prevents the most common cause of failed builds.

Answer four questions in writing:

1. Where does every interview recording land? Name the specific folder or bucket, the file naming convention, and who controls write access.
2. What transcription service will you use? Confirm the API accepts your audio format (MP3, WAV, M4A) and the file size limits involved.
3. What information do you need in the ATS candidate record? Full transcript? GPT summary only? Extracted skills list? Decide this now – it drives every downstream prompt.
4. Who reviews before the ATS write? Define the threshold for human review. A confidence score below 0.80 from the transcription API is a reasonable starting rule.

Document the answers. Share them with HR, recruiting, and IT before Step 2. The scenario build is fast. The alignment conversation takes longer and is more valuable.

Interview transcription is a textbook example of high-volume documentation work that belongs in the automation layer, not on a recruiter’s task list. The time a recruiter spends manually transcribing and summarizing interviews is time not spent on candidate relationships, hiring manager alignment, or offer negotiation.

Step 2 – Configure the Cloud Storage Watch Trigger

The trigger is the front door of the workflow – when a new recording lands in your designated folder, Make.com™ wakes up and starts the chain.

• In Make.com™, create a new scenario and add a Watch Files module for your storage provider (Google Drive, OneDrive, or an S3-compatible bucket via HTTP).
• Point the module at the specific folder where recordings land. Do not watch a root drive – scope it to the exact path.
• Set the polling interval. For most HR teams, every 15 minutes is sufficient. Real-time processing is rarely necessary and consumes operations unnecessarily.
• Add a File Size Filter using a Make.com™ router or filter step – reject files under 500KB (likely empty or corrupted) and files over your transcription service’s maximum file size limit.
• Add a File Type Filter – accept only your approved audio/video formats. Reject anything else with a log entry to a designated error sheet.

Test the trigger by uploading a sample recording. Confirm Make.com™ detects it within one polling cycle before moving to Step 3.

Step 3 – Route Audio to the Transcription API

This step passes the audio file to your chosen AI transcription service and returns structured text for the next stage of processing.

• Add an HTTP Module (or the native connector if available) configured to call your transcription service endpoint.
• Pass the file as a binary upload or a signed URL, depending on what your transcription service requires. Signed URLs are preferable – they avoid moving raw audio through Make.com™ data stores.
• Enable speaker diarization in the API request parameters if your service supports it. This labels transcript segments by speaker (Speaker A, Speaker B) and is essential for separating candidate responses from interviewer questions in the GPT step that follows.
• Request a confidence score in the API response. Store it as a Make.com™ variable for the routing decision in Step 4.
• Map the transcript text output to a Make.com™ data store or pass it directly to the next module. Do not write raw transcripts to shared HR systems at this stage – that happens after GPT processing in Step 5.

Routing audio through an automated transcription API with a confidence-score gate directly reduces the re-keying errors that cascade through downstream systems when recruiters document interviews manually. Automation eliminates the error at the source rather than catching it after it spreads.

Expert Take

Speaker diarization is the feature most teams skip in the initial build and regret immediately. Without it, GPT receives an undifferentiated block of text and has to guess which lines belong to the candidate versus the interviewer. The guess is often wrong. Add diarization in the API request from day one, even if your audio quality is imperfect – labeled segments produce dramatically more reliable GPT extraction than unlabeled ones, regardless of transcript quality.

Step 4 – Gate on Confidence Score (Human Review Router)

The quality gate at this step is what makes the rest of the workflow trustworthy – do not skip it to save build time.

• Add a Router module in Make.com™ immediately after the transcription API response.
• Route A (High Confidence): If the returned confidence score meets your threshold (start at 0.80 and calibrate after 30 days of production data), pass the transcript to Step 5 for GPT summarization.
• Route B (Low Confidence): If the confidence score is below threshold, send a notification – via email or Slack – to a designated reviewer with a link to the original audio file and the raw transcript. Log the event to your error tracking sheet. Do not proceed to summarization or ATS write until a human clears the transcript.
• Build a Resume Path: the human reviewer edits or approves the transcript and triggers a webhook or form submission back to Make.com™ that resumes the scenario at Step 5.

In typical HR audio environments, expect 10-20% of recordings to fall below an 0.80 confidence threshold initially. That number drops as you improve recording practices – dedicated interview rooms, headsets, and muting background noise. Track your weekly rate; it is a leading indicator of audio infrastructure quality.

Step 5 – Run GPT Summarization and Structured Extraction

The transcript enters and structured, actionable candidate data exits – this is where automation hands off to AI for the work that used to take a recruiter 30 minutes per interview.

• Add an OpenAI – Create Completion module (or equivalent HTTP call to the OpenAI Chat Completions endpoint).
• Write a system prompt that instructs GPT to act as an objective HR documentation assistant. The prompt should specify: output format (JSON), fields to extract (candidate name, interviewer name, date, skills mentioned, years of experience stated, behavioral examples provided, one-paragraph summary, any unresolved questions for follow-up), and explicit instruction to base output only on the transcript text – no inference beyond what was said.
• Include the diarized transcript – with Speaker A/Candidate and Speaker B/Interviewer labels resolved – in the user message. If diarization was not available, instruct GPT to infer speaker roles from context and flag low-confidence role assignments.
• Set a max token limit appropriate to your ATS field sizes. Oversized outputs cause write failures in Step 6.
• Parse the JSON response using Make.com™’s built-in JSON Parse module. Map each field to a named variable.

A clean, diarized transcript is the structured input that makes GPT summarization reliable. The quality gate in Step 4 exists precisely to protect this step – unreviewed low-quality transcripts produce low-quality summaries, and those summaries reach the ATS candidate record. The pipeline is only as good as what enters Step 5.

This AI-plus-automation architecture applies across HR document types. For a broader view of how Make.com™ handles the HR document stack, see Make.com™ scenarios for HR document management and human oversight best practices for AI-powered recruiting.

Step 6 – Write Structured Output to Your ATS

Structured candidate data flows into your system of record at this step – field by field, with no manual entry and no interpretation required.

• Add the native Make.com™ connector for your ATS (Greenhouse, Lever, Workday, BambooHR, or similar) or an HTTP module if no native connector exists.
• Map each GPT-extracted variable to the corresponding ATS field. Use the field mapping document you created in Step 1. Any field without a confirmed ATS destination should be written to a staging sheet rather than discarded – decisions about field mapping change, and you want the data preserved.
• Add an error handler on this module. ATS API rate limits and field validation errors are common. Configure the handler to log failures with the candidate ID, error message, and timestamp, then alert the HR ops owner.
• Write the one-paragraph GPT summary to a candidate notes field. Write extracted skills to a structured skills tag field if your ATS supports it. Write the full transcript to a document attachment or a linked secure document store – not to a free-text notes field.
• Do not write an automated score or ranking to the ATS. Extract structured information; leave ranking to humans. This is the distinction between information surfacing and automated decision-making – see human oversight best practices in AI recruiting for where that line sits.

Step 7 – Notify the Hiring Team

Close the loop with a lightweight notification that drives action without creating noise for the hiring team.

• Add a Send Email or Post Message module (Slack, Teams, or your collaboration tool of choice).
• The notification should include: candidate name, interview date, a direct link to the ATS record, the one-paragraph GPT summary, and any unresolved follow-up questions extracted in Step 5.
• Do not dump the full transcript into the notification. Link to it. Recruiters need a decision trigger, not a wall of text.
• For team environments, route the notification to the specific hiring manager tied to the open role – not a generic HR channel. Make.com™ can look up the hiring manager assignment from the ATS before sending.

Step 8 – Add Logging and Monitoring

A workflow without logging is a black box – build observability in from day one, before the first interview processes through it.

• At the start of every scenario run, write a log entry – scenario ID, trigger timestamp, audio file name, file size – to a dedicated Google Sheet or Airtable base.
• At the end of every successful run, write the completion timestamp, confidence score, and ATS write status.
• On any error path, write the error type, module name, and candidate/file identifier.
• Set a Make.com™ alert to notify the HR ops owner if more than three consecutive runs fail. Three failures in a row indicates a systemic issue – API key expiry, storage permission change, or ATS field validation change – not a one-off error.
• Review the log weekly for the first 60 days. After that, monthly review is sufficient if error rates are stable.

Expert Take

Most teams add logging as an afterthought and pay for it when a production run fails and the error log says “module failed” with no candidate ID, no error code, and no timestamp granular enough to isolate the problem. Build the log entry at the top of every scenario run – before the trigger even reaches the transcription API – so that every failure is traceable back to the exact file and step without digging through Make.com™ scenario history manually.

How to Know It Worked

Measure these four signals at 30 and 60 days post-launch to confirm the workflow is performing at production quality.

1. Processing time per interview: Average time from recording upload to ATS write-back. Target under 5 minutes for high-confidence transcripts. Document your manual baseline before launch for comparison.
2. Recruiter time freed per week: Survey the team. If your team processed 30 interviews per week at 45 minutes of manual transcription and summarization each, a 70% automation rate frees roughly 16 recruiter hours weekly.
3. Human review rate: Percentage of transcripts routed to the Step 4 human gate. Track the trend. A declining rate means audio quality is improving. A rising rate means something in the recording environment changed.
4. ATS write error rate: Percentage of scenario runs that fail at Step 6. Target under 2%. Above 5% indicates a field mapping or API stability issue that requires immediate attention.

Teams that define these metrics before launch reach stable production faster than those that iterate without a target. Clear success criteria create a forcing function for audio infrastructure investment – if the human review rate will not drop, the problem is in the recording environment, not the workflow.

Common Mistakes and How to Fix Them

Mistake 1 – Building before confirming ATS write access

The transcription and summarization steps work. Then the ATS module fails because the API is not enabled on your tier, or the field names in documentation do not match the actual API payload. Confirm write access with a test call before building Steps 3-7.

Mistake 2 – Skipping the confidence-score gate

Teams that skip Step 4 to save build time discover the problem the first time a poor-quality recording produces a hallucinated or garbled GPT summary that reaches the ATS. The gate is cheap insurance. Build it first.

Mistake 3 – Writing raw audio or full transcripts to shared HR systems

Raw audio and verbatim transcripts carry significant data sensitivity. Route them to governed, access-controlled storage – not to shared drives, team channels, or ATS free-text fields. Write links, not files, to shared systems. For the full data privacy framework, see HR data privacy mistakes your organization must prevent.

Mistake 4 – Using GPT output for candidate scoring without human review

Extracting structured data is appropriate. Generating a numeric score that influences whether a candidate advances is a different act with legal and ethical implications. Keep scoring in human hands. Surface information; do not make decisions.

Mistake 5 – Not logging errors with enough context to diagnose them

A log entry that says “error” without the module name, candidate ID, and error code is useless. Write structured log entries from the beginning. Diagnosing a production error is dramatically easier when your log tells you exactly which step failed and why.

Frequently Asked Questions

How accurate is AI interview transcription for HR use?

Modern AI speech-to-text models reach word-error rates low enough for professional HR documentation, particularly in clean audio environments. For high-stakes decisions, a brief human spot-check step inside your Make.com™ workflow – routing flagged transcripts to a reviewer before ATS write-back – keeps error risk manageable.

Does this workflow require coding skills?

No coding is required. Make.com™ uses a visual scenario builder, and every module – cloud storage watch, HTTP call to a transcription API, OpenAI GPT summarization, and ATS data push – is configured through a point-and-click interface.

How do you keep interview audio and transcripts compliant with GDPR or HIPAA?

Route all files through storage you govern rather than passing raw audio through third-party staging. Add a redaction module before any transcript is written to a shared system, and confirm your retention policy before building – the data classification decision belongs in governance, not in the scenario builder.

How long does it take to build this workflow?

A functional proof-of-concept takes 4 to 8 hours to configure and test. A polished production workflow with error handling and human review routing runs 2 to 3 days of build time.

What happens if the transcription API fails mid-workflow?

Make.com™ has a built-in error handler module. Configure it to catch API failures, log the error, and re-queue the audio file for a retry. Route unresolvable failures to a human review queue rather than dropping them silently.

Scaling This Workflow Across the Full HR Pipeline

Once interview transcription runs in production, the same pipeline pattern applies across the HR document stack – trigger, API call, GPT extraction, structured write, notification.

Performance reviews, onboarding documentation, and exit interview summaries all follow the same architecture once you have the pipeline wired. The pattern is the asset, not any individual workflow. For a full view of where Make.com™ fits across HR operations, see Make.com™ automations for the full employee lifecycle and Make.com™ scenarios for strategic HR recruiting automation.

The workflow in this guide eliminates manual transcription, summarization, and data re-entry for every interview your team conducts. Structure the automation first. Let AI handle the extraction layer. That sequence – applied consistently – is the operating model for an HR team that spends its time on judgment, not documentation. For real examples of that principle in practice, see automation-first, then AI in action.