How to automate podcast transcription: what a transcript is for

Transcribing a podcast is now a solved technical problem and an unsolved editorial one. The output of an automated transcription is accurate enough to be useful and wrong in specific, predictable places — which are, reliably, the names and terms the episode is actually about.

How much that matters depends entirely on what the transcript is for. A transcript published as an accessibility provision has obligations attached; one used to generate a search index can tolerate errors that a published one cannot; one used as the basis for quoting somebody cannot tolerate them at all.

What we'll cover

• Three different jobs
• Where transcription reliably fails
• Speakers, and getting them right
• Building it with CodeWords
• Accessibility, which has requirements
• Cleaning up without changing meaning
• Publishing it usefully
• Recording so the transcript is good
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Three different jobs

Accessibility, where the transcript is how some people consume the episode at all, and accuracy is not optional.

Search, where the transcript is an index rather than a document, and moderate error rates are tolerable because nobody reads it directly.

Reuse, where clips, quotes and written pieces are derived from it, and an error becomes a misquotation of a real person.

They need different levels of editing, and treating all three as one job means either over-investing or publishing something that misrepresents a guest.

Decide which you are doing before building, since it determines whether human editing is optional.

You can do all three from one transcript, provided the editing is done to the standard the strictest use requires.

Where transcription reliably fails

Names. Guest names, company names, product names — the words the episode is about are the words most often wrong.

Technical terms and acronyms, particularly anything specific to your field.

Crosstalk, where speakers overlap, which produces both attribution errors and dropped words.

Accents and non-native speech, transcribed less accurately, which means guests are not all served equally by an unedited transcript.

Numbers, including dates and figures, which are exactly the parts somebody might quote.

Poor audio from one participant degrades their portion specifically, which is invisible in the output — the transcript looks equally confident throughout.

Speakers, and getting them right

Automatic speaker separation is approximate, and it is worse with more speakers and with similar voices.

Label with real names, not "Speaker 1", since an unlabelled transcript is nearly unusable for reuse.

Supply the expected speakers in advance where your tooling allows, which improves both separation and labelling.

Check the transitions, since errors cluster at speaker changes rather than being spread evenly.

Attribution errors are the serious ones. A word assigned to the wrong person is a misquotation, not a typo.

Two speakers is much easier than four, and a panel episode needs proportionately more checking.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the audio source, the transcription service, the review step and the publishing destination can meet in one pipeline.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: where the audio comes from, the glossary, what needs review, and where the transcript goes.
3. Authorize the connections — the audio storage or feed, the transcription provider, and the publishing destination.
4. Describe the exceptions: a low-confidence section, an unrecognised speaker, an episode with more speakers than usual.
5. Run it over an episode you have already transcribed by hand and compare.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Accessibility, which has requirements

A transcript is the standard provision for audio content, and for many organisations it is an obligation rather than a nicety.

Accuracy is part of the requirement. A transcript full of errors does not meet the need it exists to serve, whatever the box-ticking view of it.

Speaker identification matters more here than anywhere, since a reader cannot use voice to tell who is speaking.

Describe the non-speech audio where it carries meaning — a demonstration, a sound, a long pause that is doing work.

Make it findable. A transcript linked from the episode page is the provision; one buried in a separate archive is not.

Public sector and several regulated contexts have specific standards, which are worth checking rather than assuming your general effort satisfies them.

Cleaning up without changing meaning

Remove filler and false starts for readability, which is the standard and expected edit.

Do not tidy the argument. Rewriting somebody's hesitant sentence into a confident one changes what they said.

Preserve the hedges. "I think" and "probably" are meaningful and removing them is the most common way an edited transcript misrepresents a speaker.

Keep corrections visible where somebody corrected themselves, since the correction is part of what they said.

Mark inaudible sections rather than guessing, which is both honest and less embarrassing than a confident wrong sentence.

Offer guests a review for anything substantive, which is a courtesy that occasionally prevents a real problem.

Publishing it usefully

On the episode page, not as a downloadable file, since the on-page version is what search engines and readers can use.

With timestamps, ideally linked to the audio position, which turns the transcript into navigation.

Structured by speaker and topic, rather than as an undifferentiated block, which is the difference between a transcript people use and one that is technically present.

Searchable across episodes, which is where the compounding value is and which almost nobody builds.

With the episode's key terms correct, since those are both the words most often wrong and the words people search for.

Linked from wherever people find the episode, rather than only from your own site.

Recording so the transcript is good

Most of the accuracy is determined before any software runs. The recording choices that improve a transcript are the same ones that improve the audio, which makes them easy to justify.

Record each speaker on a separate track, which is the single largest improvement available — speaker separation stops being a guess and crosstalk stops destroying both sides.

Insist on a decent microphone for guests, since one participant on laptop audio sets the ceiling for their entire contribution.

Ask guests to spell names at the start, including their own and their company's, which takes ten seconds and fixes the most common errors.

Avoid talking over each other, which is good practice for listeners and is what produces most attribution errors.

Record the room tone and the format consistently, so the pipeline is not handling a different kind of file every week.

Keep the raw multitrack, since a better transcription approach next year can be applied to it and cannot be applied to a mixed file.

Making it survive

Handle long episodes and provider limits, which usually means chunking with care at the boundaries.

Keep the original audio and the raw transcript, permanently, alongside the edited version.

Record which version is published, so a correction can be applied to the right thing.

Handle provider failures by retrying and reporting rather than publishing a partial transcript.

Report the outcome: episodes transcribed, low-confidence proportion, sections flagged, and what is awaiting review.

Limits worth knowing about

Accuracy varies by audio quality more than by any other factor, and a remote guest on a poor connection sets the ceiling.

Non-English and multilingual episodes are considerably harder, especially where speakers switch languages mid-sentence.

Provider terms differ on whether your audio is retained or used, which matters for anything confidential.

Timestamps drift in long recordings with some approaches, which breaks the navigation use.

A transcript is not a translation, and publishing an automated translation of an automated transcript compounds two error rates.

What to build first

A glossary of the names and terms your podcast actually uses — guests, companies, products, field-specific vocabulary — applied to every transcript. Those are precisely the words transcription gets wrong and precisely the words the episode is about, and correcting them mechanically removes most of what a human editor would otherwise fix.

Two habits make the difference. Decide which of the three jobs the transcript is for before deciding how much editing it gets, since publishing a search-quality transcript as an accessibility provision serves nobody. And mark inaudible sections rather than allowing a confident guess, because a plausible wrong sentence attributed to a real person is the one error that causes actual harm.

Frequently asked questions

How accurate is automated podcast transcription?

Good enough to be useful and wrong in predictable places: names, technical terms, acronyms, numbers, and anywhere speakers overlap. Those are also the words the episode is usually about.

Does the transcript need human editing?

It depends what it is for. A search index tolerates errors nobody reads; an accessibility provision and anything used for quoting do not. Decide the purpose before deciding the editing.

How do I improve accuracy cheaply?

A glossary of the names and terms your podcast uses — guests, companies, products, field vocabulary — applied to every transcript. It removes most of what an editor would otherwise correct.

Why do speaker labels matter so much?

Because an attribution error is a misquotation rather than a typo, and because a reader using the transcript for accessibility cannot use voice to tell who is speaking. Errors cluster at speaker transitions.

What should not be edited out?

Hedges like "I think" and "probably", visible self-corrections, and any hesitancy that carries meaning. Removing filler is expected; tidying somebody's argument into something more confident changes what they said.

What should happen with inaudible sections?

Mark them. A guess that reads confidently is worse than an honest gap, and it is the error most likely to misrepresent a real person.

Where should the transcript be published?

On the episode page rather than as a download, with timestamps linked to audio positions, structured by speaker, and searchable across episodes — which is where the compounding value is and which almost nobody builds.

Can I publish an automated translation of an automated transcript?

It compounds two error rates, so not without review. It is also a different provision from a transcript and should not be presented as one.

What improves transcript accuracy most?

Recording each speaker on a separate track. Speaker separation stops being a guess, and crosstalk no longer destroys both sides of an overlap. It matters more than the choice of transcription provider.

What should I ask guests to do?

Spell their name and their company's at the start — ten seconds that fixes the most common errors — and use a decent microphone, since one participant on laptop audio sets the ceiling for their whole contribution.

Should guests review the transcript?

For anything substantive, offering it is a courtesy that occasionally prevents a real problem — particularly where a transcription error changes what somebody appears to have claimed.

Do transcription providers keep my audio?

Terms differ, and some retain or use uploaded audio. Worth checking before sending anything confidential or anything a guest spoke on the understanding it was going nowhere else.

Related reading

• Automating podcast show notes
• Automating Zoom meeting summaries
• Automating multi-language content translation