Action items: what they are and how to write them

An action item has four parts, and it fails without any of them.

• A description phrased as an action. It starts with a verb and names something that will exist when it is done.
• Exactly one owner. One named person, never a team, never two people, never a function.
• A due date. An actual date. "Next week" is not one, and "ASAP" is a mood.
• A status. So that the list can be reviewed rather than re-read.

Most lists that people complain about are missing the second or the third. A list of well-phrased actions with no owners is a wish list, and a list of owned actions with no dates is a backlog nobody will ever declare bankruptcy on.

This is the distinction that most action item lists get wrong, and getting it right is most of the value of any process around them.

Two conflations cause most of the damage. Putting decisions on the action list is why decision logs turn into to-do lists and then die, because a record that people keep trying to close stops being a record. Putting issues on it is why action lists fill with entries nobody can move, which teaches everyone that the list is not worth reading.

The action item and task boundary is the subtle one, and the useful distinction is provenance rather than size. An action item arises from a specific conversation and carries the context of why it was agreed. Once it enters the tracker it becomes an ordinary task and loses that context. The action item is the bridge from a conversation to a system of record, which is the whole reason the category exists and the reason the bridge is where things get dropped.

Start with a verb, and name the deliverable rather than the intention.

"Follow up on pricing" fails both tests. There is no verb that describes an act, and "follow up" names an intention that could be discharged by thinking about pricing. "Send the revised pricing sheet to Anna" passes both: it starts with an act and it names a thing that will exist afterwards. The test to apply is whether two people would agree on whether it is done.

The same discipline governs the rows of a responsibility matrix, which are supposed to be written with action verbs such as schedule, write or monitor, and are supposed to exclude generic administrative entries like attending meetings or providing status. An action item that would be true every week is not an action item.

Three phrasings worth banning outright. "Circle back", because nobody can tell you what circling back looks like when it is finished. "Look into", because it commits to attention rather than to an outcome. And "we should", because it has no subject and is therefore already ownerless before anybody assigns it.

"Marketing will look into it" is not an action item. It has no verb worth the name and, more importantly, it has no owner, because a function cannot own anything: functions do not have calendars, and calendars are where work happens.

This is the same rule as the single accountable role in a RACI matrix and the single approver in DACI, and it exists for the same reason. Two owners is zero owners, because each of them can reasonably believe the other has it. Diffusion of responsibility is not a moral failing; it is what a group does by default when an assignment is ambiguous.

The rule survives the obvious objection. Work that genuinely requires several people is still owned by one of them, and that person's job includes getting the others to do their part. If nobody in the room is willing to be that person, you have not found an owner, you have found out that the item is not going to happen, which is useful information delivered early.

The related question of who holds a decision rather than a piece of work is different and is covered in collaborative decision making.

Three places, doing three jobs, and a list that lives in only one of them will fail in a predictable way.

The minutes hold the item as a record of what was agreed, in the words it was agreed in, next to the discussion that produced it. This is the version that answers "why did we commit to that" six weeks later.

The tracker holds it as work, with a status that changes. This is the version that gets done. Which tracker barely matters, and the trade-offs between them are in task and project management tools.

The responsibility matrix holds the recurring case. If the same kind of item is assigned to the same role every month, that is not an action item, it is a responsibility, and moving it to the matrix removes it from the list permanently.

The failure mode of minutes-only is that nothing gets done. The failure mode of tracker-only is that in three months nobody can reconstruct why an item exists, and it gets closed as stale when it was actually load-bearing.

This topic is drowning in statistics, and a striking number of them cannot be traced to anything. The most-repeated one, some variant of "X per cent of meetings end without clear next steps", circulates in dozens of forms with no primary study behind any of them that I could find. It is worth saying so plainly, because a page that repeats an unsourceable number to make a point that is true anyway has damaged itself for nothing.

What can be cited holds up well enough on its own. Atlassian's State of Teams research reports that meetings are judged ineffective 72 per cent of the time, that 78 per cent of respondents are expected to attend so many meetings that it is hard to get their work done, and that 51 per cent work overtime at least a few days a week because of meeting load, rising to 67 per cent at director level and above. Doodle's State of Meetings research found that 44 per cent say poorly organised meetings leave them without enough time for their actual work, and 43 per cent that such meetings create confusion.

The strongest citation available, and one almost nobody writing on this topic uses, is PMI's Pulse of the Profession in-depth report on communications. It found that US$135 million is at risk for every US$1 billion spent on a project, and that 56 per cent of that, some US$75 million, is at risk because of ineffective communications. Fifty-five per cent of project managers agreed that effective communication to all stakeholders is the single most critical success factor in project management.

For the academic ground, Steven Rogelberg's The Surprising Science of Meetings and the Cambridge Handbook of Meeting Science are the anchors. One caution about the first: the figures attributed to Rogelberg in circulation online frequently do not match what he actually wrote, so check any specific number against the text before repeating it.

All the statistics about how much time meetings consume belong on meeting overload, where they are set out properly, rather than being restated here.

An action item list is only worth keeping if something forces it to be read, and the cheapest forcing function is the first item on the next agenda of the same meeting.

Read the previous list aloud, in order, with the owner's name, and require one of three answers: done, in progress with a new date, or dropped. Dropped is the important one and the one teams are shy about. An item that has been carried for four meetings is not going to happen, and saying so out loud converts a quiet failure into a decision, which is a much better object to have.

Two ceremonies already build this in. The standup and the retrospective are both supposed to end with one owned action, and the argument for exactly one rather than a list is made in standup and retrospective formats. A debrief has the same rule for the same reason.

Once the item is on your own plate rather than the meeting's, it stops being an action item and becomes ordinary work, subject to whatever system you use. Capture, which is where most personal systems fail, is treated at length in Getting Things Done, and what to do with a list that has grown longer than the week is in Ivy Lee, Eat the Frog and ABCDE and the Eisenhower Matrix and the Pareto principle.

Here is the mechanical problem that no amount of process fixes. Every other artefact around a meeting is written afterwards, at a desk, by somebody who has decided to write it. An action item is agreed mid-sentence, by a person who is mid-argument, and who cannot write it down without leaving the conversation they are in the middle of having. The commitments most likely to be missed are the ones made by the people doing the most talking, which is to say the ones that matter.

Assigning a note-taker is the usual answer and it has a real cost: you have removed one participant from a meeting you called because you needed all of them.

This is the problem Earkeep was built for. It records your day continuously on your own device, transcribes it there, and writes plain files you own, so the commitment does not have to be caught as it goes past. Afterwards you mark the stretch of the day that was the meeting, and an agent running against it drafts the list of what was agreed, which you then correct. The recall is good because the record is complete, not because anything was clever about listening.

Be clear about the boundaries, because this is a topic where tools routinely overclaim. Earkeep does not detect action items: there is no extraction feature and no action items tab, and the reading is done by an agent running on your machine as your own command-line tool, when you ask it to. It has no tracker, no due dates, no assignment and no reminders, so nothing in the app will ever chase an owner. The record does not identify speakers, which on this topic is a real limitation worth stating: it can tell you that something was agreed, and not who volunteered for it. And the output is a file, typically a Markdown list in a directory you chose. Getting it into Jira is your job.

Telling the room you are recording is also yours to do, and there is a page on how to say it in a sentence.

Action items are the output of a meeting; deciding which meetings should exist at all comes first, and that is meeting overload. The meeting whose entire output is agreements, and where the first set of action items is generated, is the kickoff. And the sibling artefact that action items are most often confused with, the one that is a record rather than a task, is the decision log.