# How to extract structured data from meeting transcripts > For anyone pulling facts out of Google Meet and Microsoft Teams transcripts into fields: dates, amounts, names and statuses. Why transcripts are harder to extract from than documents, why every value should cite the line it came from, why an empty field beats a plausible guess, how to describe a field so a model can follow it, and how TrackHeros trackers apply those rules. Canonical: https://trackheros.com/blog/extract-data-from-meeting-transcripts/ Author: Sami Kanafani Updated: 2026-11-04 **In short:** To extract structured data from a meeting transcript, define each field with a type and a rule for what counts, record the transcript line behind every value, and leave a field empty when nothing was said. TrackHeros trackers work this way on Google Meet and Microsoft Teams transcripts: a value with no line behind it is dropped, and its quote is rebuilt from the stored transcript. Extracting structured data from a meeting transcript means turning a conversation into fields: a date, an amount with a currency, a person, a status, a list. This guide is for freelancers, consultants and anyone pulling facts out of Google Meet and Microsoft Teams transcripts, whether by hand, with a script or with an AI model. It covers why transcripts are harder than documents, why every value should cite its line, why empty beats a guess, how to write field descriptions, and how TrackHeros applies all of it. ## What does extracting data from a transcript mean? It means reading a conversation and writing down specific facts in a fixed shape, so they can be compared, sorted and checked. The transcript stays the source; the fields are an index into it. Typical targets are the ones people look up later: a go-live date, a budget, a candidate's salary expectation and notice period, who owns a piece of work, whether a request was in the original scope. Each has a type, and the type decides what a valid answer looks like. "Next quarter" is not a date. "About five" is not an amount until someone says five what. ## Why are transcripts harder to extract from than documents? Because people do not speak in final answers. A document states a value once; a meeting revises it, hedges it, attributes it to someone absent and sometimes argues about it. | What people do | Example | The trap | | ------------------- | ------------------------------------------------ | ------------------------------------ | | Correct themselves | "Friday. No, sorry, Monday." | Taking the first value | | Think aloud | "If we went with the hosted option it'd be 40k." | Treating a hypothetical as a quote | | Use relative dates | "End of next week" | Resolving it against the wrong day | | Leave out units | "Somewhere around sixty-five." | Inventing a currency | | Report someone else | "Priya thinks it's out of scope." | Recording Priya's view as a decision | | Disagree | "That's not what we agreed in March." | Picking a side | | Switch language | A Spanish sentence ending in English | Losing half the sentence | None of these is rare. A field filled without handling them is wrong often enough that people stop trusting the whole table. ## Why should every value cite its line? Because a value you cannot check is a value you cannot use. A citation turns "the budget is 40,000 EUR" from a claim into a pointer: these lines, this speaker, this moment. Checking it takes seconds, and a reader who disagrees can see why it was written. Citation also disciplines the extraction itself. If the rule is "point at the line or leave the field empty", a value that came from nowhere has nothing to point at and can be thrown away. The quote should be rebuilt from the stored transcript rather than written by whoever did the extracting; a paraphrase can drift, and a paraphrase that drifts while looking like a quote is the most misleading thing in the table. ## Why is an empty field better than a guess? Because an empty field gets asked about, and a guess gets repeated. A blank salary expectation prompts someone to ask the candidate; a plausible invented one goes into the comparison and decides an offer. The same rule runs through good meeting notes generally: a speaker who cannot be identified is better labelled unknown than given the likeliest name, and an [action item's owner](/answers/who-owns-an-action-item/) is better left empty than guessed. For extraction it means three outcomes per field, not two: a cited value, "unclear" where the field allows it, or nothing. ## How should a field be described? As a rule, not a label. The description is what decides what goes in the field, so it should say what counts, what does not, and when to leave it empty. | Weak description | Stronger description | | ---------------- | ------------------------------------------------------------------------------------------------ | | Deadline | The date the item is due, when a date is stated or agreed. Not estimates given as durations | | Salary | The pay the candidate asks for, with its currency, as stated by the candidate | | In scope? | Whether the change is said to be part of the work already agreed. Unclear unless someone says so | | Owner | The one person said to be responsible for the item. Leave empty if nobody was named | The stronger versions come from TrackHeros' own templates. Each excludes the commonest wrong answer: durations for deadlines, the interviewer's figure for the candidate's, a hopeful guess about scope. ## What does a cited extraction look like? A value, the lines behind it, and nothing where nothing was said. Take this excerpt from an interview, with its line numbers: ```text 41 00:18:02 Anna: What are you looking for in terms of salary? 42 00:18:09 Daniel: Somewhere around sixty-five. 43 00:18:13 Daniel: Thousand, euros, I mean. I'm based in Lisbon. 44 00:18:20 Anna: And when could you start? 45 00:18:24 Daniel: I have a two-month notice period. ``` | Field | Value | Lines | | ------------------ | ----------------------- | ----- | | Salary expectation | 65,000 EUR | 42–43 | | Availability | Two-month notice period | 45 | | Recommendation | | none | Line 42 alone would have been "sixty-five" in no currency; line 43 completes it, so both are cited. The recommendation is empty because nobody gave one in this part of the call. ## What about values that change between meetings? Keep the history and decide which value is current by rule. Most fields should take the newest meeting's value and keep the old ones; a few, such as the date a request was first made, should keep the first value and flag a different one as a conflict. Two more rules matter once meetings pile up. A meeting processed late must never overwrite a newer value, so its value goes into history marked as older. And a value repeated in a later meeting is a confirmation, not a change. [A history of every change, with the quote](/blog/a-history-of-every-change-with-the-quote/) shows what that looks like. ## How does TrackHeros extract data from Google Meet and Teams transcripts? Through trackers: tables that fill themselves from your meetings. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. After each meeting in a tracker's scope is summarised, the tracker reads its notes and the relevant passages of its transcript, and fills or updates the table. - The model must point at the transcript lines behind each value; a value with no line is dropped. - The quote shown is rebuilt from the stored transcript, never written by the model, and links to that moment in the transcript and the recording. - It is told to fill only what the meeting actually says and to leave everything else empty. - New and changed values wait in a review queue by default, where you accept, edit, or reject them. - An older meeting never overwrites a newer value, and a cell edited by hand is protected. A meeting held in another language, or in two, is read after the audio pass, from the same transcript the notes use; the [languages page](/languages/) lists what is recognised. The [trackers page](/features/trackers/) covers the rest. ## How do you check an extraction before trusting it? Run it on one meeting you remember, then read what it took against what you heard. In TrackHeros, preview a tracker on a recent meeting before saving it; nothing is saved, and you see every value it would propose. After that, the review queue is the check. Open the quote behind anything surprising, and fix the field description rather than the value when the same mistake comes back. [Review before a value changes](/blog/review-before-a-value-changes/) covers working through the queue. ## Frequently asked **Why not just ask a model to summarise the meeting into fields?** Because a summary has no source. A field filled from a summary can be checked only by re-reading the meeting, so nobody checks it. A field that points at its transcript lines can be checked in seconds, and one that points at nothing can be thrown away. **Does TrackHeros guess a value the meeting implied but never said?** No. A tracker is told to fill only what the meeting actually says and to leave everything else empty, and a value with no transcript line behind it is dropped. An empty cell means the meeting did not say. **Can I see what a tracker would extract before it runs on every meeting?** Yes. Before saving a tracker you can preview it on one recent meeting and see what it would take, without saving anything. Once it runs, new and changed values wait in a review queue by default. --- TrackHeros is in early access: https://trackheros.com/#early-access