Tracking meeting action items so they do not die in the notes
The meeting notes from three weeks ago contain eleven action items. Two are done. Four were overtaken by events and nobody noticed. Three have no name against them. One says "follow up with legal", which could mean a two minute message or a month of negotiation, and nobody can now remember which was meant. The eleventh is genuinely important and has been sitting there, unread, since the afternoon it was written.
Downloading a better action items template will not fix this. The template is rarely the failure. The failure is that the list is written in a place nobody returns to, in a form that cannot be checked, and is never read out loud again. A template earns its keep only when it forces the three things that make items get done: a single owner, a date, and a scheduled moment where the list is read back.
Why the list in the notes dies
Four causes account for almost all of it, and each has a different fix.
The list lives where the work does not. Meeting notes sit in a documents folder. The work sits on a board, in a tracker, or in an inbox. Anything written only in the notes is invisible during the hours when people are actually choosing what to do next. Invisibility, not laziness, is the main cause of death.
The owner is a team rather than a person. An item assigned to marketing, or to everyone, is assigned to nobody. It will be picked up only if one person privately decides to own it, which is the same thing as having one owner, except unreliable.
There is no date, or the date is the next meeting. Without a date, the item competes with dated work and loses every single time. When the date is always the next meeting, everything arrives at once and half of it slips.
Nobody ever reads the list again. This is the decisive one. An item nobody rereads is a note, not a commitment. Teams that do nothing else but read last week's items aloud at the start of the next meeting see completion rates change, because the social cost of a stale item only exists when someone says it out loud.
The fields an item actually needs
Most downloadable templates carry twelve columns. Twelve columns guarantee that eight will be left empty, and a half-filled tracker is quickly distrusted. Five fields carry almost all of the value.
| Field | Why it is needed | Common mistake |
|---|---|---|
| The action | So anyone can tell whether it is finished | Written as a topic rather than an action |
| Owner | One person who will move it | A team name, or two people |
| Due date | So it competes with other dated work | Left blank, or set to the next meeting |
| Where it came from | So the reason survives the person | Only the meeting date, with no link |
| State | So a stale item is visible | Too many states, so nobody updates it |
Three states are enough: open, done, dropped. The third is the one most trackers leave out, and it matters more than it looks. Items become irrelevant all the time. Without a way to close one deliberately, the list fills with things nobody intends to do, and a list that is mostly noise stops being read, which brings back the original problem.
Two fields often added are worth thinking about before adopting. Priority tends to become a field where everything is high, which conveys nothing. A date already ranks the list. Blocked by is useful only if something checks it, and for small teams a note in the item usually does the same job.
Writing an item so it can be finished
The wording of the item does more work than any field around it. An item that cannot be judged finished will not be finished.
Three rules cover it.
Start with a verb and name the object. Send, draft, decide, book, confirm, remove. "Pricing page" is a subject. "Draft new copy for the pricing page" is an action.
State the condition that makes it done. "Talk to the vendor" has no end. "Get written confirmation from the vendor that the migration date is the fourteenth" has an obvious one. The condition of done is what stops an item being carried for six weeks while the owner believes it is progressing.
Make it small enough to be finished by one person in a stretch of work. Anything that will clearly take a fortnight is a project pretending to be an action item. It should become a card or a small board of its own, with the action item reduced to the next visible step. A tracker filled with projects is a tracker where nothing is ever ticked.
A useful test before the meeting ends: read the item aloud and ask whether someone outside the meeting could tell, a week later, whether it happened. If not, it needs another few words.
Where the list should live
This is the decision that determines whether any of the above survives. Four options, with the trade-off each carries.
| Location | Works when | The cost |
|---|---|---|
| In the meeting notes | Almost never, for items that matter | Invisible outside the notes, never reread |
| A spreadsheet tracker | Items span teams and need a shared view | Separate from the work, so it drifts |
| A card on the board with the rest of the work | The owner already works from that board | Meeting context can be lost unless linked |
| A chat message with a reminder | Small, short-lived items | No shared view of what is outstanding |
The card on the board is the option that fixes the invisibility problem, because it puts the item in front of the person at the moment they are choosing what to do. The context problem it introduces is solved by a single line on the card saying which meeting it came from and linking to the notes, which takes seconds to write.
Two practical points come with that choice. Action items from a meeting that concern one project belong on that project's board rather than on a general list, since the owner is already looking there. And items that are genuinely cross-team, where no single board is the right home, are the case where a separate rolling list is justified. Most teams need both, with the board holding the majority.
Whatever is chosen, the list has to be somewhere everyone can see without asking for access, and it has to be one place rather than three. Teams whose boards, chat and documents are in the same tool tend to find items survive longer, simply because linking from the item to the discussion that produced it takes no effort. The features worth confirming are whether a card can carry a due date and one assignee, whether the same items can be viewed as a list by person, and whether chat lives alongside the board.
Action items are not the same as the backlog
A distinction worth drawing early, because blurring it is what turns a tracker into a second, competing to-do list.
An action item has a short life. It came out of a specific conversation, it has a named owner, and it exists to unblock something or to answer a question. Most should be finished within a week or two. The backlog is different: it holds work that has been chosen, sized and prioritised against everything else, and it survives many meetings.
Items that turn out to be real pieces of work should graduate. The action item becomes a card on the board with the rest of the work, and the entry in the meeting list is closed with a link to it. Keeping the same thing alive in both places is how two lists end up disagreeing, after which people stop believing either.
The opposite move matters too. An item that is genuinely small, such as sending a link or confirming a date, does not need to become a card with a description and a label. Writing it, doing it within the day, and ticking it off is faster than processing it. Overhead applied uniformly to items of wildly different size is one of the quieter reasons trackers get abandoned.
Capturing items during the meeting without derailing it
Items written up afterwards, from memory, are the ones that lose their owner and their date. The capture has to happen in the room.
The method that works is a designated scribe, rotating rather than permanent, who writes each item as it is agreed, in view of everyone if a screen is shared. Writing it in view has a side effect worth having: the owner sees the wording and corrects it immediately, which is the cheapest possible moment to fix a vague item.
The last four minutes of the meeting are then spent reading back every item with its owner and date. Most of the value of the whole practice is in those four minutes. Items get refused, dates get changed, and two items turn out to be the same item. None of that happens if the list is typed up an hour later.
One more rule saves a surprising amount of time: an item that nobody is willing to own is not an item. Saying so in the room, and dropping it, is better than writing it down with a blank owner, because the blank owner will sit in the list for a month before anyone admits it was never going to happen.
Reading the list back
A list that is read back weekly is a working system. A list that is not is an archive.
The read-back is short. Each open item gets one of three answers: done, still open with the same date, or the date has changed and here is the new one. A fourth answer, that it is no longer relevant, closes the item as dropped. Anything that needs discussion goes to the agenda rather than being discussed during the read-back, which is what keeps the block to a few minutes.
Two patterns are worth watching for over time. An item whose date has moved three times is not a scheduling problem, it is either blocked on something the owner does not control or it is not actually going to be done. Naming that out loud is more useful than moving the date a fourth time. And an owner with many open items has a capacity problem that the tracker has made visible, which is one of the better reasons to keep owners as individuals rather than teams.
For teams running several projects, the same read-back is worth doing once against the boards rather than the notes, looking at items sitting in a waiting state. That view answers a question the meeting list cannot: how much of the outstanding work is stalled on somebody outside the team.
What to change first
Stop writing action items in meeting notes only. Write them where the owner already works, one name and one date each, in the last four minutes of the meeting while everyone can correct the wording, and read the open ones back at the start of the next meeting. Add a dropped state so the list can be trusted. If the items, the boards and the discussion that produced them currently live in three separate applications, consolidating them is what stops the list drifting, and Pinateca is free for up to five people and ten boards.
Q1. What should an action items template include?
Five fields cover almost everything: the action written as a verb and an object, one owner, a due date, where it came from, and a state of open, done or dropped. Longer templates with priority, category and percentage complete tend to be half filled, and a half filled tracker stops being trusted. Add a field only when something will actually read it.
Q2. Should action items live in the meeting notes or in a project tool?
In the tool where the owner already works, with a link back to the notes for context. Items kept only in a document are invisible during the hours when people choose what to do next, which is the most common reason they are never done. A separate rolling list is justified for cross team items that belong to no single board.
Q3. How should an action item be worded?
Start with a verb, name the object, and state the condition that makes it finished. "Talk to the vendor" has no end point, while "get written confirmation from the vendor that the migration date is the fourteenth" can be judged by anyone a week later. If the item will take more than a few days, it is a project and the action item should be its next visible step.
Q4. Can an action item be assigned to a whole team?
It can be written that way, but it behaves as though it is assigned to nobody. One name means one person who will move it, which does not prevent several people doing the work. If the right owner is genuinely unclear in the room, that is worth resolving before the meeting ends rather than leaving the field blank.
Q5. How can follow through be improved without chasing people?
Read the open items aloud at the start of the next meeting, with owner and date. That single habit does more than any reminder system, because a stale item becomes visible to everyone rather than sitting in a document. Watch for items whose date has moved three times, since those are usually blocked or unwanted rather than late.