Why action items from meetings don't get done
Everybody already writes them down. Notetakers extract them automatically now, neatly bulleted at the end of every summary. And most of them still do not happen.
The usual explanation is that people are busy and forget. That is not really it. The more useful explanation is that a list of action items throws away almost everything that determines whether an action item moves, and then we are surprised that what is left over does not work.
Here are the four things it throws away.
1. Direction
"Action items" flattens two completely different objects into one list:
- Things you owe someone else.
- Things someone else owes you.
These have nothing in common operationally. The first is work you schedule. The second is a relationship you manage — you cannot do it, you can only ask, and asking has a cost and a cadence and a right moment.
A single undifferentiated list means the second kind quietly disappears, because you cannot action it and so you skip past it every time you read the list. Which is unfortunate, because the things other people owe you are usually the ones blocking your project. Your own tasks at least have you working on them.
The fix is not a better list. It is two lists that behave differently.
2. Whether it already happened
Here is the most common way an action-item list becomes worthless.
You promise a security review. You do it on Tuesday. The item stays on the list, because nothing about doing the work touches the document where the work was written down. Two weeks later you are reading a list where you cannot tell which items are live.
Now the list has negative value. An unreliable list is worse than none, because checking it costs the same as it ever did but you can no longer trust the result — so you stop reading it, and the items that are live go down with the ones that are not.
Almost every "we tried tracking action items and it didn't stick" story is this story. The list was not wrong at any single moment; it just decayed, and nothing made it converge back to reality.
Anything that tracks commitments has to be able to close them from evidence — from the work shipping, from a later conversation moving on, from the thing simply being visibly done — and not only from someone remembering to tick a box.
3. Why it mattered
"Send the pricing breakdown" is a task. It tells you nothing about whether to do it today or in three weeks.
"Send the pricing breakdown — they cannot take it to their board without it, and their board meets on the 14th" is the same task with the reason attached, and now it schedules itself.
Reasons get said out loud in meetings constantly, usually a minute or two away from the commitment they belong to, and almost every extraction drops them because they are not phrased as tasks. What survives is the imperative clause, which is the least informative part of what was said.
4. The questions nobody wrote down
The largest category of dropped meeting output is not tasks at all. It is questions that were asked and never answered.
"What happens to our data if we don't renew?" "Can this integrate with our CRM?" "Who owns this on your side?"
These get raised, talked past, and lost when the conversation moves on. Nobody records them, because they are not action items and there is no field for them. And an unanswered question is rarely neutral — it is usually the thing quietly preventing the decision you are waiting for. You will find out about it later, framed as an objection, at the worst possible time.
What actually helps
Four changes, none of which require a new tool:
Split by direction. Keep "I owe" and "they owe" as separate lists. Read your own first — chasing someone while you are late yourself is how a relationship sours quietly.
Track age, not deadlines. Most meeting commitments never had a real deadline. What they have is an age, and age is the better signal: anything nobody has mentioned in three weeks is not progressing.
Write the because. One clause. It is the difference between a task you schedule and a task you keep re-reading.
Keep a list of open questions, separately from tasks. Re-raise them; you will be the only person in the meeting who remembers.
The part that is genuinely hard
Three of those four are discipline. The fourth is not.
Noticing what has gone quiet requires noticing an absence — something that should have come up and did not. No individual meeting contains that information. It exists only in the gaps between meetings, which is exactly where a per-meeting summary cannot look, no matter how good the summary is.
That is the reason this does not get solved by writing better notes. It is not a notes problem. It is a problem about the relationships between notes, and you cannot get there from a stack of documents each of which knows about one meeting.
How Kika does it
Kika writes the notes from each call, and then keeps the four things above as first-class objects rather than bullets: what was decided and why, what you owe, what they owe, and what was asked and never answered.
Commitments carry their age, and the ones nobody has mentioned in weeks surface on their own. It reads your merged pull requests, so work that shipped closes the matching promise instead of being chased. And five minutes before your next meeting it hands you the relevant subset as a brief — every line attributed to the meeting and date it came from, so you can check it rather than trust it.
We wrote up how that is built, including the parts that are still hard.
See what Kika remembers — 300 free meeting minutes a month, no card.