A Meeting Report Is Three Records, Not One Summary

Most meeting notes fail quietly. Not because they are wrong about what was discussed, but because they blend three different kinds of statement into one smooth paragraph: what someone said and why it seemed to matter, what the group actually agreed to, and what nobody settled. Read as a single narrative, those three blur together, and a proposal ends up looking like a decision. Skavio Meeting produces a summary and key points (the highlights layer), plus decisions, action items and open questions as separate report sections, backed by a speaker-attributed transcript. The discipline this article describes is simple: treat the transcript as the evidence layer, and treat every other section as an interpretation that has to be checked against it before the report leaves the building.

Three records that behave differently under scrutiny

The highlights layer — the summary and key points — is an interpretation of salience. It answers a useful but subjective question: which parts of the discussion carried the most weight? A decisions section makes a much stronger claim. It asserts that a group reached agreement, and someone will later act on that assertion, possibly with money or a deadline attached. An open-questions list makes the weakest claim of all and is therefore the safest place to put anything uncertain. Collapsing these into one summary saves reading time and costs accuracy. The practical fix is procedural rather than technical: give each item a status before it is shared, and allow exactly one status per item. Proposals, deferrals and unresolved contradictions belong in the open-questions list, not in the decision log, even when a speaker sounded confident.

What Skavio Meeting actually produces

Skavio Meeting is a live Skavio web product that turns a meeting recording into a speaker-aware transcript plus an analysed report. The documented pipeline runs AssemblyAI transcription and speaker diarization first, then OpenAI meeting analysis and report generation on top of that transcript. The documented outputs are the speaker transcript, a summary, key points, decisions, action items, open questions and a follow-up draft, with TXT, DOCX and PDF exports. The ordering in that pipeline matters for review: the transcript is upstream of the analysis, so when the two disagree, the transcript is the artefact you go back to. The analysis step is what produces the decisions and open-questions sections; it is not an independent witness to the meeting. On the question of scale, Skavio's recorded internal measurements include a 236-second fixture completed in 19 seconds with three speakers across eight utterances, and a 3,763-second fixture completed in 40 seconds at roughly 94 times realtime with three speakers and 113 utterances. Those numbers describe pipeline throughput on specific fixtures. They say nothing about attribution quality across accents, room acoustics or crosstalk.

A review routine that keeps the sections honest

Read the report in a fixed order and the review takes minutes rather than an afternoon. Start with the summary and key points to rebuild context, but do not quote them as fact. Then take the decisions list one entry at a time and find the moment in the speaker-attributed transcript where the group actually confirmed it. If you cannot find that moment, the item is not a decision yet — move it to open questions rather than deleting it, because the discussion did happen and someone may need to revisit it. Do the same for action items, checking specifically whether a named person accepted the task or merely heard it described. Only after those two passes should you read the open-questions section, where you will often find items that were in fact resolved later in the recording and simply not captured in the corresponding section. This is not a defect unique to automated reports; manual minutes drift the same way. The difference is that with a timestamped transcript, the drift is checkable.

Where the draft ends and human approval begins

The follow-up draft is an output of the analysis step, produced alongside the report. It is a draft in the strict sense: it is not evidence that anything was agreed, and it is not a sending action. The documented workflow is upload-and-process; no automatic sending, calendar or task-system integration, live meeting-bot joining, or CRM write is documented. That leaves the handoff from draft to outbound message with a person, which is a reasonable place to keep it. The export choice reinforces the workflow: DOCX suits an editable draft that a second reviewer can correct, while PDF suits a fixed copy once the content has been approved. Whichever you distribute, keep the speaker transcript with it. A summary circulated without its underlying transcript has no evidence trail, and if a commitment is later disputed, the transcript is the part of the package that can answer the question.

Where the report can be wrong

Two failure modes deserve explicit handling. The first is speaker attribution. Overlapping speech, similar-sounding participants and poor audio can shift a line from one person to another — which turns a question into a commitment if nobody checks. Mark attribution as uncertain whenever the transcript looks inconsistent with what you remember, and never build an accountability record on a single ambiguous line. The second is salience. The summary and key-points layer reflects a model's judgment about which parts of the discussion mattered, and that judgment can miss a quiet but decisive remark or promote a long digression. Neither failure makes the report useless; both make unread distribution risky. Read the report as a structured aid to a human review, not as the review itself, and the remaining problems become ordinary editorial questions with a transcript available to answer them.

Open Skavio Meeting →