Decisions getting lost?
Build a connected work system around the choices, owners, and follow-through that matter.
A decision that cannot be found, understood, or acted on is organizational memory loss.
A decision log process gives operations teams a reliable route from a decision request to a recorded outcome, assigned follow-through, and review. Use it when important choices disappear into meetings, chat, or private documents.
Quick answer
Build one decision record that moves through intake, framing, review, approval, communication, implementation, and review. Give every record a problem owner, a single decision authority, a due date, alternatives, rationale, linked actions, and a revisit trigger. A meeting note is not the log: the log is the system of record for the decision and its consequences.
When this needs a separate system
This is distinct from a decision tree for business processes. A decision tree helps a worker choose the next branch in repeatable work. A decision log governs a significant choice, records why it was made, and verifies what happened afterward. It also complements the distinction between a workflow and a process: the log connects a governing choice to the operational work it changes.
The decision record: the work object
- Decision statement: the choice to be made and what will change.
- Problem owner: accountable for progressing the record.
- Decision authority: the one person or defined body that can decide.
- Scope and constraints: boundaries and non-negotiables.
- Options and evidence: alternatives, assumptions, sources, and trade-offs.
- Decision, rationale, and actions: final outcome, why, owners, and due dates.
- Review trigger: a date, metric, or event that warrants revisiting.
Decision log state model
| State | Owner | Exit condition and retained evidence |
|---|---|---|
| Submitted | Problem owner | Triage confirms the decision belongs in the log; record the rationale. |
| Framing | Problem owner | Scope, authority, criteria, options, and contributors are explicit. |
| In review | Problem owner | Feedback and disagreements are recorded, not resolved in private. |
| Awaiting decision | Decision authority | Approve, reject, or return for rework with a recorded reason. |
| Committed | Problem owner | Decision, rationale, effective date, and affected parties are recorded. |
| Implementing | Action owners | Actions meet completion conditions or have an approved exception. |
| Reviewed | Problem owner | Keep, amend, or supersede; retain review evidence. |
For an architectural example, AWS describes decision records as having a lifecycle and says an accepted record should not be silently rewritten; a later choice supersedes it. The same principle preserves operational history.
Define the handoffs
For each transition, specify the sender, completion condition, required context, receiver, and acceptance condition. For example, a problem owner hands a record to the authority only when alternatives, recommendation, affected teams, and deadline are present. The authority accepts it by selecting approve, reject, or rework—not by leaving a meeting unanswered.
Exception design
| Failure | Detection and blocking state | Owner, escalation, and resume evidence |
|---|---|---|
| Missing evidence | Validation blocks In review. | Problem owner adds a source or explicit assumption; sponsor is alerted if the deadline is at risk. |
| Authority unavailable | Decision date approaches without an outcome. | Problem owner alerts the named backup; delegation or deadline change must be recorded. |
| Conflicting approvers | Required feedback materially disagrees. | Authority resolves the trade-off; preserve dissent and final rationale. |
| Decision changes | New facts invalidate an assumption. | Open a superseding record, link both records, and communicate changed actions. |
| Action overdue | Linked action passes its due date. | Action owner completes it, approves an exception, or triggers a decision revision. |
Measures that improve the system
- Decision lead time: submitted to committed.
- Overdue decision rate.
- Review rework rate caused by incomplete framing or evidence.
- Action completion reliability.
- Supersession rate and reason category.
- Scheduled-review completion.
Use these measures to find design flaws, not to reward fast approvals.
Where Workhint fits
Workhint can help teams build this as a connected work system: decision intake, role-based records, transition rules, contributor requests, approval rights, action assignments, exception paths, notifications, evidence links, and operational views. Workhint is relevant when the decision log must connect to the workflows it changes rather than remain a disconnected spreadsheet.
Build This in Workhint
Build a decision-log system for [team]. Create a Decision record with statement, problem owner, authority, impact, due date, scope, options, recommendation, evidence, decision, rationale, actions, and review trigger. Configure Submitted, Framing, In review, Awaiting decision, Committed, Implementing, and Reviewed. Require validation before review and commitment; route missing evidence, unavailable authorities, conflicting feedback, and overdue actions to named exception owners. Add views for decisions due this week, blocked records, overdue actions, and reviews due. Preserve transition history and evidence.
Start with one decision class
Choose a recurring decision that creates confusion—such as a vendor exception, customer-policy change, delivery-priority shift, or operating-rule change. Run the model for a month, review blocked records, then refine the fields and decision rights. The goal is not more documentation; it is a durable path from a choice to a visible, owned operational change.
Leave a Reply