The Problem Is Not the Meeting. It Is What Happens After.
Most project decisions get made. The problem is that they do not get recorded anywhere useful.
The decision lives in someone's head, in a voice memo, in a thread buried three weeks deep in an email chain, or in a PDF markup that only one person has. When a question comes up again — and it will — the team spends real time reconstructing what was decided, who agreed to it, and whether the drawings or the procurement order ever reflected it.
This is not a communication problem. It is a documentation gap. And a lightweight same-day decision log can close most of it.
The short version
- A decision log is a short structured record — decision, owner, due date, impact — not meeting minutes and not a project diary.
- It only works if it is written the same day. Next-morning reconstruction is where the details die.
- Every logged decision needs one named owner. "The team will follow up" is not an owner.
- The impact field — which drawings, products, or dates this decision touches — prevents the most rework.
- Review the log briefly each week so it stays the live reference instead of a file nobody opens.
What a Decision Log Actually Is
A decision log is not a meeting transcript. It is not a full set of minutes. It is a short, structured record of what was decided, who owns the next action, when that action is due, and what else in the project is affected.
The goal is not to document everything. The goal is to document the things that will cause confusion or rework if they are not written down.
Four fields cover most situations:
- Decision: What was agreed. One or two sentences. Plain language.
- Owner: The single person responsible for the next action. Not a group. One name.
- Due date: When the action needs to be complete. A real date, not "soon" or "ASAP."
- Impact: What else this decision touches — a drawing, a sheet, a product, a schedule, a contractor scope.
That is the whole system. The format can be a shared spreadsheet, a running doc, a project management tool, or a simple table in whatever platform the team already uses. The format matters less than the habit.
On a small team — a solo designer and one contractor — the PM role often falls to whoever ran the meeting. On a larger project with multiple consultants and a dedicated coordinator, that person should own the log. The key is that one person is responsible for capturing decisions before the day closes, not that everyone contributes to it in real time.
The 24-Hour Rule
The log only works if it is written the same day.
Waiting until the end of the week means decisions get compressed, details get lost, and the person who was supposed to own an action has already moved on to something else. Waiting until the next meeting means the gap between decision and documentation is long enough for confusion to take hold.
Same-day does not mean immediately after every conversation. It means before the workday closes, someone — a PM, a project lead, a studio coordinator — captures the decisions from that day's meetings, calls, and site visits into the log. Even AI-generated meeting notes need a human pass before their action items land in the log.
On a small team, this is often a five-minute task. On a larger project with multiple active conversations, it might take fifteen. Either way, it is faster than the time spent later trying to reconstruct what was decided.
Where Teams Get This Wrong
Logging too much. A decision log is not a project diary. If every minor exchange gets logged, the document becomes noise and people stop reading it. Log decisions that have downstream consequences — things that affect drawings, procurement, schedule, or scope. Skip the routine updates.
Assigning ownership to a group. "The team will follow up" is not an owner. When no single person is named, the action tends to fall through. Every logged decision should have one name next to it.
Skipping the impact field. This is the field that prevents the most rework. If a finish selection changes and no one notes that it affects the FF&E schedule and the reflected ceiling plan, those documents will not get updated until someone catches the discrepancy — usually at the wrong moment. The impact field forces the person logging the decision to think one step ahead.
Treating the log as a one-way record. The log is only useful if people actually reference it. A quick review at the start of each weekly meeting — what was decided last week, what actions are overdue, what is still open — keeps the document alive and keeps the team honest.
A Simple Decision Framework
Not every conversation produces a loggable decision. Use this as a quick filter:
- Does this change what is on a drawing or in a document? Log it.
- Does this change what gets ordered, specified, or procured? Log it.
- Does this change who is responsible for something? Log it.
- Does this change a date or a sequence? Log it.
- Is this a routine status update with no downstream effect? Skip it.
The filter takes about three seconds per item. It keeps the log lean and keeps the team focused on what actually matters.
What This Looks Like in Practice
A boutique studio is running a residential remodel. During a Tuesday site visit, the contractor and designer agree to shift a wall two feet to accommodate an existing condition. The designer notes it on a markup. The contractor mentions it to his framing crew.
Without a decision log, the markup stays in the designer's bag, the framing crew hears a verbal instruction, and the drawing set still shows the original wall location. Three weeks later, the cabinet order arrives and does not fit. Everyone is confident the decision was made. No one can prove when, and the drawing never caught up.
With a decision log, the entry from Tuesday reads:
- Decision: North kitchen wall shifted 24 inches west to clear existing beam pocket.
- Owner: Designer — update floor plan and reflected ceiling plan.
- Due date: Thursday.
- Impact: Floor plan, RCP, cabinet layout, possibly millwork dimensions.
The designer updates the drawings. The cabinet order gets reviewed against the new dimensions before it ships. The framing crew has a drawing to work from. The decision is not relitigated at the next site visit because it is already in writing.
The log did not prevent the wall from moving. It prevented the wall from moving invisibly.
Keeping It Simple
The temptation with any new system is to build it out — add categories, add filters, add a status column, add a review workflow. Resist that for the first few months.
Start with the four fields. Run the log for four to six weeks. See what the team actually uses and what gets ignored. Adjust from there. Over time, a well-kept log becomes part of the project's searchable record — decisions, specs, RFIs, and selections in one place instead of scattered across threads.
The goal is not a perfect system. The goal is a record that is accurate enough and current enough that the team stops asking questions that were already answered.
Questions designers ask
Should the log live in a spreadsheet, a project management tool, or a doc?
Whichever one the team already opens every day. A spreadsheet that gets checked beats a dedicated tool that gets ignored. The habit is the system; the format is just storage.
What about decisions made over text or on a phone call?
The 24-hour rule applies to those too. Calls and site visits are where the most consequential decisions happen precisely because they feel informal. The person who ran the conversation captures it before the day closes.
Should clients see the decision log?
Keep the working log internal. Clients benefit from summaries — what was decided, what they owe you by when — but a raw log full of shorthand and internal owners creates more confusion than clarity. Share the outcomes, not the mechanism.
How is a decision log different from meeting minutes?
Minutes record what was discussed. A decision log records only what was decided, who owns the next action, when it is due, and what it affects. Minutes are a transcript; the log is a commitment record.
What happens when two people remember the decision differently?
That is exactly what the log is for. The written entry is the record — not the stronger memory or the louder voice. If the disagreement surfaces before the day closes, resolve it and log the resolution. The log does not prevent disagreements; it ends the second round of them.
For studios and contractors that want to connect this kind of operational structure to their broader production workflow — drawing sets, procurement tracking, and handoff documentation — Creo's production support work is built around exactly that kind of backend coordination.
Ready to work with a studio that moves at your pace?
Get In Touch