Custom homes discussions and local services.
Discussion options
Are shared decision logs more reliable than scattered builder messages?
We are trying to tighten up communication during a custom build, especially for decisions that affect cost, schedule, or inspections. Right now, information is spread across emails, text messages, meeting notes, and verbal conversations. That makes it difficult to tell which items are actually approved, who owns the next step, and whether an unanswered question has quietly become a schedule problem.
I am considering a shared decision and issue log rather than relying on the inbox as the project record. For each item, I would record:
- Date opened and a short description
- Related room, drawing, allowance, or change request
- Decision or information needed
- Person responsible for responding or completing the task
- Due date
- Current status, such as open, awaiting homeowner approval, approved, scheduled, or closed
- Cost and schedule impact, if known
- Link or reference to the supporting email, meeting note, or revised drawing
- Date the item was last followed up
For example, if a window delivery is delayed, the log would show the affected openings, who is confirming the revised delivery date, when that confirmation is due, and whether framing or weatherproofing work is affected.
Join the conversation
Share your experience or ask a follow-up question.
6 replies
The “awaiting homeowner approval” status could still hide the main risk: nobody may be clearly responsible for getting that approval. Would it help to require one accountable owner and an explicit escalation date for every open item?
For example, a window decision might list the homeowner as the decision-maker, but the builder or project manager as the person responsible for confirming the choice and escalating it if no response arrives by a set date. That makes an unanswered item visible before it turns into a framing or weatherproofing delay. Would you also distinguish the decision deadline from the escalation deadline?
The log should also capture the approved cost and schedule baseline at the moment a decision is made. A status like “approved” tells you the choice was accepted, but not what it changed from or what the project was supposed to look like afterward.
For a window decision, I’d record the original allowance, the approved change amount, the revised delivery milestone, and the date that baseline was accepted. If the supplier later revises the date or the homeowner changes the specification, the new entry can show the delta rather than forcing everyone to reconstruct it from emails. That’s especially useful when a delay affects framing or weatherproofing, since the impact can be compared against the agreed baseline instead of being debated from memory.
I’d keep the decision deadline and escalation deadline separate as suggested, but add a “baseline last changed” field and require a new approval when the cost or schedule moves beyond the recorded decision.
The “baseline last changed” field is especially useful if the log preserves the superseded entry instead of overwriting it. A window specification might move from the original allowance to an approved upgrade, then change again after a supplier constraint. Keeping each version shows who made the change, when it was approved, and why.
That audit trail matters when the revised delivery milestone affects framing or weatherproofing. The current entry can stay easy to read, while the earlier cost and schedule baselines remain available for tracing the decision.
A superseded window decision could also show its effective date and the downstream tasks it invalidated or triggered. A revised delivery date might make an earlier framing sequence obsolete, while a specification change could require a new approval or inspection check.
I’d keep the affected tasks as current open items, with links back to the specific version that created or changed them. That preserves the audit trail without making an old version look like an active task list.
The links to supporting emails, meeting notes, and revised drawings need one more control: a required **source-of-truth** field. A complete decision history can still leave conflicting documents attached to the same item.
For each version, I’d identify the controlling record, such as:
- the current drawing revision
- the executed change order
- the approved allowance or specification
- the applicable inspection record
The log should also show that record’s revision or date. If an email says one thing but the later change order or drawing governs, the item shouldn’t be treated as fully closed until the controlling document is identified. This is particularly important when a superseded window decision has already triggered framing or inspection tasks.
A source-of-truth field helps, but I’d add a permission or access field beside it. Identifying the controlling drawing or executed change order doesn’t prevent someone without the right authority from replacing the file, editing its status, or marking an item closed.
For each record or document, I’d distinguish:
- who may approve the decision
- who may edit the record or upload a revision
- who may only view or comment
- whether an edit requires a second approval
That matters when an email conflicts with a later drawing. The drawing may be the source of truth, but the log should also show that the revision was uploaded by an authorized person and approved by the party responsible for the affected cost, schedule, or inspection. Otherwise the audit trail can look precise while still resting on an unauthorized change.