Hand off meeting notes so the next person can start

Ask what the receiver needs to do next

A pack is defined by the first thing the receiver does with it. Write that action down before you assemble anything, because it decides what has to be inside. Three questions do most of the work: what the new owner will do in the first hour, what they will have to prove to somebody else, and who else will end up reading the same file.

The answers sort the material for you. If the first action is pasting rows into a task list, the table and its column names carry the weight, and a paragraph of prose about the meeting is ballast. If the first action is telling a client what changed, the decision lines carry the weight and the table is the appendix. If the first action is chairing the next review, the unanswered questions matter more than anything the room settled, because the meeting is being continued rather than filed.

In the pack described on this page, the receiver's first action was importing the register into a workspace database. That is why the six column names and the file's own header row were given more room than the summary paragraph that used to sit above them, and why the import test in section 4 was run before anything was announced.

Address the pack to a role rather than a person — the incoming project owner, the next chair — and put the handoff date on the pack. A pack that names an individual goes stale the week that individual changes team, and the attachments then belong to nobody in particular. The date matters for a second reason: it tells the next reader which version of a moving set of notes they are holding.

Separate decisions, tasks and open questions

Three lists travel together, and merging them is the most common way a handoff loses information. A decision is something the room settled; it belongs in prose with the timestamp of the moment it was settled. A task is work with a deliverable, an owner, a due date and a source timestamp; it belongs in a table where the receiver can sort and filter it. An open question is something the room could not close; it belongs in a list that ships with the pack rather than in a paragraph nobody reads twice.

The failure mode is quiet. A summary written to sound complete promotes an open item to a decision, or drops it, and the receiver has no way to tell which happened. The export used below does the opposite and keeps both states visible: of its three rows, one reads Unassigned in the Status column because nobody was named to own it, and one reads Not checked because no date was ever spoken for it. Neither word is a defect in the table. Both are the table doing its job.

Four parts travel with the notes

Two of those four parts are routinely left out and both are cheap to add. The evidence pointer takes one extra field on a row you are already typing, and the access line is a sentence. What they prevent is the same thing: a new owner who cannot act without coming back to ask you what a row means.

Trim the transcript, keep the evidence

A new owner almost never needs the whole transcript, and they do need the ability to doubt one sentence. Keep the location and drop the volume: a timestamp on every row, the exact wording only where the wording decides something, and the name of the file that holds the audio with the date its retention ends. Pasting a long stretch of dialogue into the pack usually hides which sentence produced which row, which turns a searchable record into reading homework.

What a transcript export can carry depends on the account you exported from, and that decides what the receiver is able to re-check. Otter's public pricing page lists an export row — "Exportable audio, text, and captions" — whose formats widen with the plan: the free row gives "mp3, txt", Pro gives "mp3, txt, pdf, docx, srt", and the rows above Pro add "; bulk export" (otter.ai/pricing, accessed 2026-09-14). Fireflies lists "Download transcripts, summaries, recordings" among the features that arrive with Pro (fireflies.ai/pricing, accessed 2026-09-14). Neither is a reason to change plans; both are reasons to name, inside the pack, the format you actually exported and who can regenerate it, so the receiver is not left hunting for a menu item that belongs to somebody else's account.

Where the wording matters, quote the sentence and keep it beside the row rather than in a separate document. Where it does not, the timestamp is enough, and it is more durable: when the audio is deleted at the end of its retention period, a row that carries 14:20 still says where to have looked.

Write the rows while you still have the audio in front of you — the action register tool keeps the four fields in one table and reports what is still missing without filling anything in for you.

Test the import with a small sample

Run one file through the destination before the handoff is announced. The test takes a minute, and it separates a receiver who reads your table from a receiver who retypes it. The thing being tested is not the content, which you already checked, but the file: whether the columns arrive as columns, whether the rows survive, and whether the notes come back whole.

Here is the pass run for the pack on this page, on 14 September 2026. action-register-after.csv was parsed with Python 3 csv.reader: the header reads Deliverable, Owner, Due date, Source timestamp, Status, Notes; three data rows held 18 data cells; no row had a field count other than six. The longest Notes value, 71 characters, came back without truncation. The before file behaves the same way except in one cell: row 2 of this file was wrapped in quote marks because its value contains a comma, and the parser returned it as a single field instead of splitting it in two — the behaviour RFC 4180 describes, and the reason that specification registers the file type the pack uses as "MIME media type name: text" and "MIME subtype name: csv" (RFC 4180, accessed 2026-09-14).

One result stays open and is reported as such rather than assumed. The pack was not imported into a third-party workspace: no account was connected anywhere in this pass, so the check sheet records the destination import as Not checked. That is the honest state, and it is the field to fill in on the next handoff that does connect one.

Worked example: a handoff pack for a new project owner

The pack on this page was assembled from the register tool's own example, which the file labels in its Notes column and the tool labels on screen as invented sample values. The rows are therefore a rehearsal; the measurements below are not, and neither is the process they went through.

The input is action-register-before.csv as the register's Load example writes it: 427 bytes, three data rows, six columns, SHA-256 first 16 characters 52ead35776b9a8e4. Measured on this machine on 14 September 2026, that file carries one duplicated deliverable — Send the revised pricing sheet appears on rows 1 and 2 — one unassigned owner, and two rows whose Due date reads Not stated. The register reports the same reading in its own words: 3 rows · 1 unassigned · 2 without a due date · 1 duplicate row.

The check then produced the file that travels in the pack: 419 bytes, three data rows, six columns, 18 data cells, no duplicated deliverable, and one merged row carrying the date the chair named. Its SHA-256 first 16 characters are 9d09d71eb46d22fb, and the register's count line for it reads 3 rows · 1 unassigned · 2 without a due date · 0 duplicate rows.

Two rows in that export are open, and they are the two the receiver has to act on: row 2 has no date to work to, and row 3 has no owner. Sending them this way is better than sending a tidy file, because a receiver who can see the gap can close it; a receiver reading a summary that hides the same gap cannot even tell it exists.

The pack's file identity is recorded on the check sheet, and this is where a second render of that sheet matters. The first render lists an earlier export of the same register at 650 bytes, SHA-256 first 16 characters 0ee17bc089c14947, five data rows; the render below is that first version, and the file that shipped is the 419-byte version above. Two exports of one register, one file name, and the difference is invisible unless the byte count, the hash prefix and the row count travel with the pack. That is the whole reason the sheet has those three columns.

Name files so the next person can find them

Give the whole pack one prefix and one date, and let the file name say what the file is: the register, the open questions, the check sheet. Write the date into the name rather than the word "final", because the second version of a pack is the normal case and only one of the two names survives a folder listing. The rule is not about tidiness; it is about a receiver who opens their downloads folder a week later and has to decide which of two files is the one they were given.

The header row is a contract as well. The export keeps six column names in a fixed order, and those same six names are published on the tool page and in the site's own register file, so a receiver comparing the pack against either can see that the columns mean the same thing. A destination that imports spreadsheets makes this concrete: Notion's help page states that "CSV imports create a new Notion database (rows → items/pages, columns → properties)", and, for a file added to a database that already exists, that you should "make sure your CSV headers match the database's property names exactly" (Notion Help, notion.com/help/import-data-into-notion, accessed 2026-09-14). The same page notes that "CSV and ZIP use different import options", so a CSV goes in one file at a time rather than as part of a batch.

Renaming a column to match a destination is a legitimate edit, and it belongs in the pack's notes with the date, because the next person comparing a renamed export with the original will otherwise assume the data changed. Export the register and the open-question list as an importable file, then test the import with one page before sending the pack on.

Record access restrictions

Notes that were private to a five-person meeting change audience the moment they move into a workspace or behind a link, and the change is silent. Notion's help page draws three levels, and the third one is worth reading literally: "Anyone on the web with link: This means that anyone who has the link to your page can access it, even if they aren't part of your workspace or aren't a Notion user." The same page explains what an outside reader needs to get in: "To access your page, your guest will need their own Notion account." (Notion Help, notion.com/help/sharing-and-permissions, accessed 2026-09-14). A link that works for everyone is convenient exactly once, and it stays that way until somebody deletes it.

So the pack records four things about access, in the pack rather than in your memory of the meeting. Who may open it, by role. Which level they get — invited people only, the workspace, or anyone with the link. What happens to the pack when the working group shrinks or the project closes. And which items are pointed at rather than quoted: personnel matters, legal advice and security findings stay in the restricted system, and the row says where to look for them instead of carrying them into a wider room.

Retention belongs in the same sentence as access. If the audio is kept for a fixed period, write the date beside the rows so a reader knows when the timestamps stop being replayable, and know what happens to the pack afterwards: the table survives, and the rows whose Status depended on listening to that file should not be quietly left reading Pass.

Close the loop after the receiver confirms

A handoff is finished when the receiver has used the pack, not when the link was sent. Ask for three specific confirmations, because none of them can be answered from your side of the transfer: how many rows arrived in the destination, which open questions now have an owner, and whether any row could not be found at all. The first catches a column that mapped onto the wrong property. The second tells you the pack's open list was read rather than filed. The third is the omission you could not have found yourself, because a sentence that was never written leaves no row behind.

When the receiver finds something missing, it goes back into the register as a new row with its own source timestamp and the date it was added, and the transcript is not edited to make the pack look as if it had always been complete. If the new owner takes on the unassigned row, the Owner and Status fields change and the change is dated; if they name somebody else, that name goes in the same way. A register that shows its own history is more useful to the next handoff than one that reads clean.

This is the end of the meeting chain rather than a separate task: the checks in Check meeting notes against the recording and the decisions produce the rows, the four fields make each row closeable by somebody else, and the pack is what carries them out of the room.

Two questions the pack raises

Does the pack have to include the recording or the transcript?

No, and on most meetings it should not. The pack carries the register, the open-question rows and a pointer to the file — its name, the format you exported, and the date its retention ends. Whether the audio itself may travel is the organisation's decision and often the participants' as well, so the pack states what is available on request instead of attaching it. If the recording is never going to be retained, write that beside the rows, because the timestamps then mark where to look rather than proof that can still be produced.

Will another product open the CSV as a proper table?

Not checked on this page, and marked that way on purpose: no third-party account was connected while this pack was prepared, so nothing here claims how a specific product would read the file. What was verified is narrower and reproducible — the export parses into six columns per row, three rows holding 18 cells with no malformed row, and the quoted cell in the before file comes back as one field. Where a product does document its own behaviour, the pack can quote it: Notion's help pages describe a CSV import creating a database and requiring the headers to match the destination's property names exactly.