Meeting Action Items: A Template That Gets Them Done

A meeting action item is one piece of work somebody agreed to do, and it needs three parts: it starts with a verb, it has exactly one owner, and it says what done looks like. Add the meeting it came from and when it will be checked, and you have everything a template needs. Then the item has to leave the meeting notes the same day and go onto the board the team already works from, and the next meeting has to open by checking it. The template, a filled example, a way to fix vague items, and a follow-up routine are below.

This page is only about the actions. How to record a whole meeting, with its decisions and open questions, is in the meeting minutes template; what AI note takers capture and get wrong is in AI meeting note takers; and the fixes that come out of an outage review are covered in the incident postmortem template.

What makes an action item

• A verb first. “Send”, “call”, “draft”, “fix”, “decide”. If the line starts with a noun, such as “Pricing page”, it is a topic, not an action.
• One owner, named. Not a team, not “we”, not two people. Others can help; one person answers for it.
• Done-when. A result someone else could check: “sent to legal”, “merged and deployed”, “three quotes in the shared folder”. Without it, an item is never quite finished and never quite late.
• A check-in. The meeting or date when the owner reports back. It is not a deadline imposed on the work, it is when the group will look.
• Where it came from. The meeting and date, so anyone who finds the task later knows why it exists.

The owner rule is plain-language advice as much as project management. Digital.gov’s plain language guide↗ (opens in a new tab) puts it this way: active voice makes it clear who should do what and eliminates ambiguity about responsibilities. “It must be done” is not an action item; “Tom will do it” is the start of one.

Rewriting vague action items

Most bad action items fail on done-when. Google’s SRE workbook, reviewing a weak postmortem↗ (opens in a new tab), calls out items that use ambiguous phrases like “Improve” and “Make better”, because vague terms make success hard to measure, and notes that items without clear owners are less likely to be resolved. The same holds for any meeting. Read each item back before the meeting ends and fix it on the spot.

Vague:  Look into the onboarding emails
Better: Draft three subject lines for the welcome email and
        share them in #growth. Owner: Priya. Check: Oct 6 meeting.

Vague:  Improve the checkout page
Better: Fix the ZIP code field rejecting 9-digit ZIP+4 codes;
        done when a ZIP+4 order completes on staging.
        Owner: Sam. Check: Oct 6 meeting.

Vague:  Follow up with the vendor
Better: Call Northwind Supply and get a written delivery date
        for the replacement router. Owner: Luis. Check: Oct 2.

Vague:  Think about the hiring plan
Better: Decide whether the support hire is full-time or
        contract, and bring the decision with the reason.
        Owner: Maria. Check: Oct 6 meeting.

The last one shows a useful trick. “Think about” produces nothing anyone can check; “decide, and bring the decision” produces something the next meeting can record.

The meeting action items template

# Action items: [meeting name], [Month day, year]

- [ ] [Verb] [what, specifically]
      Owner: [one name]
      Done when: [a result someone else can check]
      Check-in: [next meeting, or a date]

- [ ] [Verb] [what, specifically]
      Owner: [one name]
      Done when: [...]
      Check-in: [...]

Carried over from [previous meeting date]:
- [ ] [item] | Owner: [name] | Status: [done / in progress / blocked: why]

Keep the carried-over block. It is the difference between a list of good intentions and an action item tracker: every meeting starts by looking at what the last one promised.

A filled example

# Action items: Operations weekly, September 29, 2026

- [ ] Call Northwind Supply for a written delivery date on the
      replacement router
      Owner: Luis
      Done when: the date is in the shared vendor sheet
      Check-in: October 2

- [ ] bug: Fix the ZIP code field rejecting ZIP+4 codes at checkout
      Owner: Sam
      Done when: a ZIP+4 order completes on staging
      Check-in: October 6 meeting

- [ ] Decide full-time vs contract for the support hire
      Owner: Maria
      Done when: the decision and reason are recorded
      Check-in: October 6 meeting

Carried over from September 22:
- [x] Renew the domain certificates | Owner: Sam | Status: done
- [ ] Update the holiday on-call schedule | Owner: Priya | Status: blocked:
      waiting on two people's PTO dates

What does not belong on the list

• Decisions. “We will launch on October 14” is not something anyone does; it is something that was decided. Record it where decisions are kept; on fenbs, that is the Decisions and rules page.
• Open questions. If nobody can do anything until someone answers, the action is “find out” and it has an owner; otherwise it is a question, not an action.
• FYIs and updates. “Priya shared the survey results” already happened.
• Ongoing responsibilities. “Sam owns the website” is a role, not an item that can be finished.

Why action items go undone

• Nobody wrote them down in a form anyone could act on. The meeting agreed on something, and five people left with five versions of it.
• The owner was volunteered while they were not in the room, or said “sure” to be polite. Confirm the owner out loud before moving on.
• The list lived in a document nobody opens between meetings, so the work competed with nothing and lost to everything.
• Nobody checked. If the next meeting never asks, the team learns that agreeing to an action costs nothing.
• The item was too big to finish before the check-in. Break it down until the first piece fits, and make that the action.

After the meeting: onto the board

Action items left in meeting notes get done when somebody rereads the notes. Filed as tasks on the board the team works from, they sit next to the rest of the work, where they get prioritized, started and finished like everything else. Do it the same day, and make the person who took the notes responsible for filing, not each owner.

On a fenbs board, each action item becomes a task. fenbs has no assignee field and no due dates, so the owner, the done-when line and the check-in go on the first line of the note, where everyone reads them: “Owner: Luis · Done when: date in the vendor sheet · Check-in: October 2”. Put the meeting name in the category, such as “Ops weekly”; categories are made by typing a new name, and the board filters by them. Add many files the whole list at once from a pasted Markdown list, with indented lines becoming each task’s note; the meeting minutes template shows the paste format, so it is not repeated here.

Or let an assistant file them

If an AI assistant is connected to the board over MCP, it can turn raw notes into tasks. Ask it to show you the list before it writes anything. The MCP specification↗ (opens in a new tab) says there should always be a human in the loop with the ability to deny tool invocations, and a quick look at the list is where you catch an item with two owners or no done-when.

Here are my notes from today's Operations weekly: [paste].
1. Pull out the action items only. Rewrite each one: verb first,
   one owner, a done-when line, and a check-in. If an item has no
   owner or no done-when, list it separately as a question for me.
2. Show me the list and wait.
3. When I say go: fenbs_search for each first and comment on any
   match instead of filing it twice. File the rest with
   fenbs_create_item in category "Ops weekly", with the note's first
   line "Owner: [name] · Done when: [...] · Check-in: [...]".
Do not decide anything or invent an owner.

Following up at the next meeting

1. Open with the tracker, not the agenda. Filter the board to the meeting’s category and go down the open items. Five minutes is usually enough.
2. Each owner answers in one line: done, in progress, or blocked and why. Nobody explains the work; they report where it is.
3. Done means the done-when line is true. If it is not, it is in progress.
4. A blocked item gets a new action: somebody unblocks it, with an owner and a check-in.
5. An item that has come back three times gets a decision: do it now, give it to someone else, or drop it on purpose. Carrying it forever teaches everyone that the list does not matter.

On fenbs, the same review works from the board: tasks moved to Completed are done, and each task’s history shows who changed what, so “I sent it last week” can be checked rather than debated. An assistant can prepare it too: ask it to list the open tasks in category “Ops weekly” with fenbs_list_items and draft the carried-over block for you to read out.