Write meeting action items someone can actually close

Four fields, no exceptions

A row is a task only when four values are present: the deliverable, the owner, the due date and the source timestamp. The register on this site adds two more columns, Status and Notes, because the four fields carry the work and the other two carry the checking. The four themselves are not negotiable. When a meeting did not supply one of them, the row says so instead of going blank, and the register publishes the exact words it counts: a row counts as unassigned when Owner is empty or reads Not assigned, and as undated when Due date is empty or reads Not stated (the counting rules are stated on the tool page, read 2026-09-14). A blank cell and the word Not stated therefore produce the same count, and both are honest — the empty cell is only dangerous because it is invisible.

Two habits come before the fields. Keep decisions out of the table: "we chose option B" is a decision for the notes, while the revised pricing sheet that carries option B figures is a deliverable. And write one row per deliverable rather than one row per mention. A task discussed twice in a meeting is still one task, which is why the register counts repeated deliverables and names the extra rows without merging them itself. In the three rows used below that count was 1.

Write the deliverable as a noun phrase

What gets handed over is a thing, not an activity, so the test I use is to cover the verb and read what is left. "Send the revised pricing sheet" leaves a revised pricing sheet, which someone can open, attach to a message or reject. "Follow up on the pricing" leaves follow-up, which is not a handover. "Sync on Q4" leaves a sync. The register's own three example rows are all written with a leading verb — Send the revised pricing sheet, Review the wording of section 3, Confirm the data-processing clause with legal — and each one carries an object that exists once the row closes, so all three pass that test. The verb is not the problem; an object that nobody can point at is.

Three edits turn an intention into a deliverable. Name the version or the state: "the pricing sheet" becomes "the revised pricing sheet, September list prices". Keep the qualifier that limits the work: "section 3 wording", not "the document". And split a row that carries two deliverables even when the transcript joins them with "and", because the two halves close on different dates and often in different hands. A row with two objects fails as a whole and tells the next reader nothing about which half is late.

Assign an owner, or label the row unassigned

The person who raised a task is not automatically its owner. In the two exports below, one row carries Not assigned in the Owner column while its Notes column records what the room actually did with that item: it was raised at 21:40 and nobody was named for it. Both facts stay true at once, and the register keeps them apart. Not assigned is a value a reader can filter on; a guessed name in the same cell is a value nobody can check.

An unassigned row is the table doing its job, not a defect in the table. The alternative — putting the nearest name into the cell so that the column looks complete — produces a register where every row appears owned and at least one person is quietly carrying work they never agreed to. The tool page states plainly that it never fills in a name, a date or a deliverable on your behalf, and it does not name a person from the transcript either.

There is a third state worth writing down when it appears: an owner who is named but whose scope is disputed. That belongs in Notes with its timestamp, because the next reader needs the objection rather than a tidier row.

Use a date you can defend

A due date is a claim about the future that other people will plan around, so it needs a source in the same way a number on this site does. Three honest ways to fill the field: the room named a date and the row carries it; the room named no date and the row reads Not stated; the date is still being negotiated and the row stays Not stated until somebody names one. What does not belong in the field is an estimate built by whoever is typing. "Tomorrow" is only a date once you know the day of the meeting and the time zone, and a register that quietly converts it has invented a deadline that someone else will be measured against.

Keep three different dates apart while you write. The due date is when the deliverable is expected. An estimate is what somebody said out loud, such as "aiming for the end of the month", and it belongs in Notes beside its timestamp. The completion date stays empty until the work is done, and no row closes because a date passed.

The worked example keeps this gap visible rather than tidying it: two of the three rows carry Not stated in the due-date column both before and after the pass, and the count stays at 2. Nothing in that pass was allowed to change it, because no date was spoken and there was nothing to cite.

Keep the source timestamp on every row

The timestamp is what makes a register checkable rather than merely tidy. It points at the moment a task was agreed, so a reader who doubts a row can replay one passage instead of re-reading the whole meeting. In the rows below the values are relative times inside the recording — 14:20, 18:05, 21:40 — and they are the only link between the table and the audio.

Pick one convention for the whole register and write it at the top. Relative times from the start of the recording are the easiest to replay; a wall-clock time needs a time zone before it means anything at all. The timestamp is also the thing you quote when you and the transcript disagree, so it should be typed in the same pass as the row rather than reconstructed later from memory.

Two published limits explain why the timestamp has to travel with the table rather than with the audio. Otter's pricing page gives a per-conversation ceiling — "Max transcription time per conversation" reads "30 minutes" on the free row and "90 minutes" on Pro (otter.ai/pricing, accessed 2026-09-14; original wording: "Max transcription time per conversation 30 minutes 90 minutes") — so a long session can arrive as two files. Its monthly allowance is per user and does not roll over: "Meeting & recording transcription monthly limit (no rollover) 300 minutes per user" on the free row and "1,200 minutes per user" on Pro (same page, accessed 2026-09-14). Fireflies caps what a free team can keep: "400 mins of storage/team" (fireflies.ai/pricing, accessed 2026-09-14; original wording: "400 mins of storage/team"). Old recordings are therefore the first thing to disappear, while a row that says 14:20 keeps telling a reader where to look.

If the recording is not retained at all, write that next to the row. A timestamp pointing at a file nobody can open is a citation the reader cannot check, and this site records that state as Not checked rather than treating the timestamp itself as proof.

Worked example: the duplicate row, the missing owner and the date nobody named

I ran the pass over the register's own export rather than writing a tidier one by hand. The input is action-register-before.csv as the Load example button writes it — 427 bytes, three data rows, six columns, SHA-256 first 16 characters 52ead35776b9a8e4 (measured on this machine, 2026-09-14). The rows are the tool's sample values, and the tool prints its own banner saying they are invented; the counts below are what the register reported for them.

The register's line for those rows read 3 rows · 1 unassigned · 2 without a due date · 1 duplicate row. Three defects inside three rows, and each is a different kind: a missing owner in row 2; two missing due dates, in rows 2 and 3; and a duplicated deliverable, because rows 1 and 2 carry the same Deliverable text and the same 14:20 timestamp. The tool names the extra row and its row numbers — rows 1, 2 — and leaves the merge to the person reading.

The pass then changed three things. The two mentions of the pricing sheet were merged into one row, which now carries Owner Alex, Due date 2026-09-18 and Status Pass, with a note that the chair named the date and that two transcript mentions were merged into it. The section 3 wording row kept Priya and Not stated. The item raised at 21:40 became a row of its own — Confirm the data-processing clause with legal — carrying Not assigned and Not stated, because that is what the room produced.

The output is action-register-after.csv: 419 bytes, three data rows, six columns, SHA-256 first 16 characters 9d09d71eb46d22fb (measured 2026-09-14). The register's counts for it read 3 rows · 1 unassigned · 2 without a due date · 0 duplicate rows, so one of the three defects is closed and two are recorded as open.

An import test parsed the export with Python 3 csv.reader: the header reads Deliverable, Owner, Due date, Source timestamp, Status, Notes; three data rows held 18 data cells and no row had a field count other than six; the longest Notes value, 71 characters, survived without truncation or extra quoting. The before export contains one quoted field — row 2's Notes, because that value holds a comma — and it reads back as a single cell, which is the behaviour RFC 4180 defines: "Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes." (RFC 4180, accessed 2026-09-14). Import into a third-party workspace stays Not checked: no account was connected anywhere in this pass, so no claim is made about how another product would read the file.

Fill the four fields in the action register, export the table, and send it with the notes instead of a paragraph of summary.

Export, filter and count what is open

The export keeps the six column names in one fixed order — Deliverable, Owner, Due date, Source timestamp, Status, Notes — and the same table can be copied as Markdown or printed. The status column carries this site's four states: Pass, Fail and Not checked are verdicts on a row, while Unassigned records who owns it and not whether it holds. Open work is therefore everything that is not Pass plus every row whose Owner reads Not assigned, and those two filters answer different questions: what has not been checked yet, and what nobody has taken on.

The counts line is the line I read first, because it answers "what is still open" without anyone scanning rows. In the export above it read 3 rows · 1 unassigned · 2 without a due date · 0 duplicate rows — three numbers a reader can act on, and no score, percentage or ranking anywhere on the page.

Storage limits are the reason the export matters more than the table it came from. Fireflies gives a free team "400 mins of storage/team" (fireflies.ai/pricing, accessed 2026-09-14; original wording: "400 mins of storage/team"), and Otter's free monthly allowance is "300 monthly transcription minutes" with no rollover (otter.ai/pricing, accessed 2026-09-14; original wording: "300 monthly transcription minutes"). The recording, not the register, is the fragile copy, so the 419-byte CSV is the part that survives a plan change — and the part to send with the notes. Build the register in the action register and export it before the summary circulates.

Follow up without inventing deadlines

A follow-up message should quote the row rather than summarise it. Copy the deliverable, the owner, the due date exactly as the register holds it, and the source timestamp, then add one line saying what you need. If the due date reads Not stated, the message asks for a date; it does not propose one, and it does not round the deadline to a convenient Friday. If the owner reads Not assigned, the message goes to whoever chaired the meeting, because assigning work is a decision that belongs to the room and not to a tidy table.

Two habits keep the follow-up checkable. Send the register with the message so the receiver can see the row being quoted, including the rows that are not theirs. And when a row changes after the meeting — a new owner, a named date, an item closed — record the change on the row with its date instead of editing the transcript, so the history of the task stays legible to the next person who reads it. If the follow-up then gets reworded for tone, the commitments inside it still have to survive the edit: Rewrite an email without changing what you promised covers the dates, amounts and conditions a warmer sentence can quietly move.

Where this pass stops: it does not judge whether the work is worth doing, whether that owner is the right person, or whether the deadline is achievable. Those are decisions the meeting has to make. The register keeps the gaps where a reader can find them, and a row labelled Not assigned is worth more than a sentence that hides the same gap in prose.

Four checks before a row goes out

These are the four checks I run on a finished register, in this order. They produce no score and they change nothing the meeting decided.

1. Read each row with the verb covered. What remains has to be something a person can open, send or sign. "Send the revised pricing sheet" leaves the sheet; "catch up about the pricing" leaves nothing to hand over, so it goes back to the meeting as a question instead of into the register as a task.
2. Read the counts line and write down what it said. For the rows in the worked example it read 3 rows · 1 unassigned · 2 without a due date · 1 duplicate row before the pass and 0 duplicate rows after it, while the two undated rows stayed undated. Three figures, one closed, two still open: that single line is the status of the follow-up.
3. Check that every gap carries a word rather than a blank. The register counts a row as unassigned when Owner is empty or reads Not assigned, so a blank cell and the printed word give the same count; the difference is that the word is visible to the next reader. Nothing on the tool page fills any of the four fields in for you, and it says so.
4. Decide what happens when the recording is gone. If the audio is no longer retained, mark the rows it covered instead of leaving their timestamps looking replayable. A timestamp pointing at a file nobody can open is a citation, and this site records that state as Not checked rather than reading it as evidence.

Questions

Does every row need a due date before the notes go out?

No. A date nobody named is not a field waiting to be filled; it is something the meeting did, and Not stated records it. Forcing a date in produces a register where every row looks scheduled and at least one deadline was invented by whoever typed the table — and that invented date is the one a reader plans around. Write Not stated, leave the row in the undated count, and ask the owner for a date if one is genuinely needed.

Can the register tell that two differently worded rows are the same task?

No, and its page says so. The duplicate check compares the Deliverable text after ignoring letter case and extra spacing, so two rows describing the same work in different words are not flagged at all. It never merges, deletes or rewrites a row either: when it does find a repeat it names the extra row and its row numbers, exactly as it did for rows 1 and 2 in the example above, and leaves the merge to the person reading the table.