Actions and Decisions That Do Not Get Lost

Strip the notes back far enough and two things remain

Nobody has ever gone looking for last month's meeting notes because they fancied reliving the discussion. They open them for one of two reasons: to find out what was decided, or to find out whether something was their job.

Everything else in a summary is packaging. So it is worth being fussy about these two, because they are the parts that fail quietly. A summary with a weak context paragraph is merely dull. A summary with a decision that was never made, or an action with nobody's name on it, causes an actual problem several weeks later, at which point nobody can remember enough to sort it out.

An action has three parts

An action item needs an owner, a verb and a date. Take away any one of them and it stops being an action.

The owner is one person. Not "the team", not "marketing", not "we". A task owned by a group is owned by nobody, and everyone in that group will assume, entirely reasonably, that one of the others has it. This is the single most common way work disappears, and it happens without anyone behaving badly.

The verb is specific. "Send the revised timeline to Priya" is a verb. "Look into the timeline" is a mood. If the action does not describe something you could watch a person do, it is not finished being written. Be suspicious of the whole family of soft verbs: explore, consider, align on, think about, circle back, touch base, take a view.

The date is a date. "Next week" is not a date. "ASAP" is a way of saying no date while sounding urgent. "Before the launch" only works if the launch has a date, in which case use that one.

A decision is not an intention

The other half of the problem is at the decisions end, and it runs the opposite way. Actions fail by being too vague. Decisions fail by being too generous.

Summarisers are agreeable. Give one a transcript where somebody said "we should probably just go with the second option" and nobody contradicted them, and it will file that under DECISIONS with a clean full stop. What actually happened was that a person floated an idea and the room moved on.

There is a real difference between four things that all sound similar in a transcript:

• Somebody proposed something.
• Somebody proposed something and nobody objected.
• The group discussed it and reached agreement.
• The person who had the authority to decide said yes.

Only the last two are decisions, and in most organisations only the last one really is. A summariser cannot tell these apart unless you make it try, which means telling it explicitly what counts and where to put the rest.

From the transcript below, extract decisions and actions. Be strict.
DECISIONS: only include something if the transcript shows the group agreeing
or a person with authority saying yes. Name who confirmed it and quote the
sentence they confirmed it in. If someone proposed an idea and nobody
responded, that is NOT a decision.
ACTIONS: a table with columns Task, Owner, Due date, Confidence.

Task must start with a specific verb. Reject vague verbs like "look into",
"explore" or "align on"; if that is all that was said, write the task as
it was said and mark Confidence as LOW.
Owner must be one named person. If a team or department was named instead
of a person, write the team name and mark Confidence as LOW.
If no owner was named at all, write UNASSIGNED.
If no date was said, write NO DATE. Do not invent one.
AMBIGUOUS: a separate list of anything that might be a decision or an action
but that you are not confident about. For each one, say what was said and what
is missing. Put anything you were tempted to guess at in here.
Never infer an owner from who happened to be speaking at the time.
TRANSCRIPT:
[paste it]

The ambiguous list is the point

That third section is the one people delete because it looks like the tool failing. It is the opposite. It is the tool telling you where the meeting was unclear, which is information you could not otherwise get.

A well behaved summary with nothing in the ambiguous list means one of two things: either the meeting was unusually crisp, or the model resolved every uncertainty on your behalf and did not mention it. In practice it is nearly always the second.

Read that list first. Each item is a thirty second job while everyone still remembers the meeting: message the person, confirm who has it, fill in the date. Do it a week later and it becomes a small archaeology project.

Relative dates need converting

Meetings run on relative time. "Friday", "end of the month", "before the board meeting". Notes that keep those phrases are useless in three weeks, because nobody can recover which Friday was meant.

Fix it in the prompt by telling the model the meeting date and asking it to be explicit about what it worked out rather than what it was told.

This meeting took place on [date]. In the actions list, convert every relative
date into an actual calendar date. Show it as: 3 October (said as "Friday").
If a phrase is genuinely ambiguous, such as "end of the month" or "soon",
leave it as it was said and add (AMBIGUOUS). Do not guess which one was meant.

Send it today, not perfectly

Here is the trade nobody makes consciously, and almost everybody gets wrong.

A slightly rough summary that lands within the hour gets read by people who still remember the meeting. They spot the two errors immediately, because the real version is still in their heads. They reply, you correct it, and the notes are now accurate and agreed.

A beautifully polished summary sent on Thursday gets read by people who have had four meetings since. Nobody remembers well enough to challenge anything, so the errors go uncorrected and become the record. Then it gets forwarded.

Speed is not laziness here. Sending quickly is what gets your notes checked by the only people qualified to check them, which is why the summary that goes out the same hour ends up more accurate than the one you spent an evening tidying.