Talking to Your Meetings
A pile of transcripts is a database nobody can query, until you give it a little structure
A research team's transcripts are the most expensive thing it owns and the least usable. So at some point I stopped re-watching mine and made them answer questions instead.
If you do research for a living you accumulate transcripts the way other people accumulate browser tabs. Dozens of interviews, each an hour or two, each holding maybe four useful minutes you can never find again. The information is all there. It is simply stored in the least retrievable format humans have devised: a chronological wall of "um" with no index. The dream is obvious, ask your meetings a question and get an answer. Getting there has less to do with the AI than with cleaning up the mess you feed it, which is the part people skip before wondering why the answers are poor.
Two problems, only one of which is the model
There are really two jobs. The first is connecting an assistant to your transcripts at all, so you can ask in plain language rather than scrub a recording. The second, and the one that decides whether any of it works, is making the transcripts worth asking in the first place.
The connection part has become easy. The honest one-paragraph version: there is now a standard way to let an assistant read a tool's data directly, so "query my meetings" can be a real feature instead of an afternoon of pasting transcripts into a chat window. You point the assistant at the transcript source and you can converse with the whole corpus. That is the part that demos well.
The part that makes it useful is duller and more important.
Raw transcripts are terrible input
A raw transcript is poor fuel for a model, for reasons easy to underrate.
It is noisy: filler, crosstalk, false starts, three people talking over a fourth. It is unstructured: no sections, no topics, no marking of what matters. It is thin on metadata: often you cannot even say with confidence who is speaking, let alone what their role is. And it is vague about the thing you usually care about most, which is who these people actually are. In buyer research the entire game is sorting the decision-maker from the influencer from the person who was merely in the room, and a transcript states almost none of that outright.
Hand that to a model and ask "who was the decision-maker," and it will give you a confident answer assembled from vibes. Sometimes it is right. You have no way to know when it is not, which for research is worse than useless, because a confident wrong finding is one you will act on.
The fix is a schema, not a cleverer model
What actually made this work was not a better model. It was forcing structure onto the qualitative mess before the model gets near it, with a small coding scheme.
The version I built tagged the things that mattered with explicit fields: the person's role, a confidence level for that judgment, and, above all, the evidence for it, an anchoring quote from the transcript itself. So instead of the model asserting "this person is the decision-maker," you get "decision-maker, medium confidence, on the strength of this line where they said they own the budget." The claim now arrives with its receipts attached.
Three things fall out of that, and they are the whole point. The confidence level stops everything looking equally certain, which is how you separate a solid read from a guess. The evidence quote makes every claim checkable, so a human can glance at the line and agree or overrule rather than trust a black box. And because the persona judgments are anchored to quotes rather than floating free, you get a defence against the exact failure that plagues this work: the model confidently crowning a junior attendee as the decision-maker because they happened to talk the most. Make it cite a quote and that error becomes much harder to commit and much easier to catch.
If that sounds like the same lesson as grounding a chatbot in its sources, it is. It is the same idea aimed at qualitative research instead of document Q&A: never trust a fluent answer, make it show where it came from. The technique travels.
Why it is worth the effort
The schema also happens to be reusable. Build it once and it works across projects, because the structure of "who is who and how do we know" stays roughly constant even when the subject matter does not. The cost of designing it is amortised over every project after.
And the payoff is the thing I actually wanted, which is to stop spending my life re-watching calls. With clean, coded, evidence-anchored transcripts behind it, an assistant can answer real questions across a whole project's worth of interviews, and show its working, in seconds. The model did not make my transcripts intelligent. The schema did. The model just reads it back to me, with the quotes attached so I can check it is not inventing things, which, after enough hours in front of recorded meetings, is precisely the colleague I always wanted. ▮
“The model did not make my transcripts intelligent. The schema did.” STRUCTURE BEATS MAGIC