The retro went well. People were honest, the quiet ones spoke, and you left with six things to fix. Nine weeks later somebody raises one of them again, and nobody in the room can say whether it was ever done.
This is not a facilitation problem. The hour was fine. What failed happened after it, and it fails the same way in most teams, for four reasons that are all visible on the day.
An owner is a person, not a team
"The team will sort out staging" is not an owner. Neither is "infra", "we" or "whoever picks it up next". Every one of those is a way of finishing the conversation without anyone agreeing to anything, and they feel like progress because the sentence has a subject.
Name one person. Not because the work is theirs alone, but because somebody has to be the person you ask. An action owned by a group is an action owned by nobody, and the only reliable sign of it is that when you come back to it, everyone present assumes somebody else was handling it.
If nobody will take it, that is useful information and it should be said out loud. An action with no owner is a problem the team has decided not to fix yet, which is a legitimate position. Writing it down anyway, unowned, is how a list becomes something people stop reading.
A date is a commitment, not a category
"Next sprint", "soon" and "before the next release" are not dates. They cannot pass, so they cannot be missed, so nothing about them ever becomes uncomfortable enough to prompt anyone.
A real date has a specific quality: on the day after it, somebody is either done or visibly not done. That discomfort is the entire mechanism. Removing it by writing "ongoing" does not make the work more likely to happen, it makes the failure invisible.
Pick a date you would be willing to be asked about. If the honest answer is that you cannot commit to one, the action is too big and needs splitting, which is a better outcome than a date nobody believed when it was written.
A status somebody actually changes
Most action lists have two states in practice: written down, and forgotten. The list exists, it is accurate on the day it was made, and it decays from there because nothing ever prompts a change.
The fix is unglamorous. The list has to be looked at somewhere that is not the retro, and the retro has to open with it rather than close with it. Opening with "here is what we said last time, and here is what happened" costs about four minutes and changes what people are willing to write down for the rest of the hour, because everybody now knows the list gets read back.
Closing with it does not have the same effect. By then the decisions are made and the list is a formality.
The problem it was meant to fix
This is the one almost everybody misses, and it is the one that matters most.
Write down what the action was for, not just what it is. "Write a release runbook" is a task. "Write a release runbook, because releases take a whole day and only one person can do them" is a task attached to a problem.
The difference shows up months later. When releases are still taking a whole day, the second version lets you ask a question the first one cannot: we closed an action against this, and it came back. That is a different conversation from noticing the same complaint for the fourth time and treating it as new. One leads to asking why the fix did not hold. The other leads to writing the same action again, which is roughly how most teams end up fixing the same three things every year.
You can do this with nothing but a habit and a shared document. Put the problem in the same line as the action, keep the old lists, and read them before the next retro. It is tedious and it works.
The uncomfortable part
If you do all four of these for six months, you will find that some of your fixes did not hold, and that a few problems have come back twice. That is not a sign the retros are failing. It is the first time you have had the information at all.
Most teams never get it, because the record is spread across archived documents, exported PDFs and whatever tool they were using two engagements ago. The problem is rarely that nobody cared. It is that nothing was keeping count.
That is the part we are building. Retros.ai keeps the record, carries open actions forward until somebody closes them, and links each action to the problem it was meant to fix, so the question of whether a fix held can be answered rather than guessed at. Until it is ready, everything above works perfectly well in a spreadsheet, and it is worth doing either way.