Decisions rarely announce themselves
A call ends with “Fine, let's ship without the export option.” Someone replies “Works for me” on an email thread. Nobody writes it down, because everyone in the room heard it.
Three weeks later a stakeholder asks why the export is missing. The people who were there remember it differently. The decision happened, but you cannot point to it.
A decision log fixes that. The hard part is not the spreadsheet. It is catching the decision while it is still fresh.
What counts as a decision worth logging
Log a choice when it changes scope, schedule, cost, or who is responsible. Skip choices that are easy to reverse and affect only one person's afternoon.
If you are unsure, ask one question: would a new team member need to know this to understand why the project looks the way it does? If yes, log it.
Capture six things
- The decision. One sentence, written as a result: “Launch the first release without CSV export.”
- Who decided. Name the person who had the authority, not everyone in the room.
- The source. Link to the meeting notes, recording, or email thread. Include the timestamp or message if you can.
- The date. The day it was decided, not the day you logged it.
- The reason. One line. “Export needs a second sprint and the pilot customers did not ask for it.”
- What changes next. The action, an owner, and a date if one was agreed.
If your team revisits decisions, add a seventh field: when to look at it again. Keep it optional. A log with too many required fields stops getting filled in.
A worked example
Here is a generic example. A product manager runs a Thursday scope call. At the end, the lead engineer says the team will cut the CSV export from release one. The product manager agrees. A follow-up email confirms it.
The log entry could read:
Decision: Launch release one without CSV export. Decided by: Product manager, with the lead engineer's recommendation. Source: Thursday scope call notes, plus the follow-up email thread. Date: Thursday's date. Reason: Export needs a second sprint, and the pilot group did not ask for it. Next: Add “CSV export” to the release two backlog. Owner: product manager.
Anyone can read that in ten seconds. They can also open the source and check it.
Check the decision before you log it
Not everything that sounds final is a decision. Before logging, ask three questions:
- Was it decided, or only suggested? “We could cut export” is an option. “We're cutting export” is a decision.
- Did the right person agree? A strong opinion from someone without authority does not settle the question.
- Does it conflict with an earlier decision? If it does, link the two and mark the old one as replaced.
If any answer is unclear, ask in the thread or at the next meeting. Log it as “proposed” until someone confirms.
Keep the log easy to trust
- Use one place. Two logs mean two sources of truth.
- Replace, do not delete. When a decision changes, add a new entry and mark the old one as replaced. The history explains how you got here.
- Review it weekly. Ten minutes is enough. Scan the week's calls and threads for choices that never reached the log.
- Log within a day. Memory fades fast, and the follow-up email is easy to lose.
Where Jensi fits
Jensi collects candidate work from connected conversations and meetings into suggestions that people review. A reviewer checks the source, edits the details, and accepts the work. Accepted work keeps its source context and review history.
That helps with the capture problem in this guide: the work keeps a link back to the call or thread it came from. Whether you also keep a separate decision log is your team's choice. The habits above work with or without a tool.
For a related workflow, read how to turn Slack messages into tasks without losing context, or browse the resource library. If you want to try the source-and-review path with your own conversations, start free.