Eight months into a residential addition, during the punchlist walkthrough, your client stops in front of the master bathroom and says: "This isn't the tile we agreed on."
Your project architect is certain the client approved the Calacatta marble in an email back in schematic design. The client is equally certain they did not — or if they did, they had reservations that were never addressed. The tile is installed. The project is otherwise complete.
You spend two hours searching email. You find the exchange. The client replied "ok looks good" to a message that contained four PDFs and three separate material selections in the body text. Was that an approval of the tile specifically? Nobody can say for certain.
That dispute costs you six hours of time and a difficult conversation about a credit that never quite covers what you spent resolving it. The tile was fine. The design was fine. The problem was a decision that nobody ever clearly captured.
The Problem Is Not Missing Information
Most architecture firms believe their project information exists somewhere. An email was sent. Notes were taken. Someone marked up a PDF. This belief is largely correct — and it is the source of the problem.
Information organized by time (the order messages arrived, the date a file was saved) is not the same as information organized around decisions. When the question "was this approved, and by whom?" arises six months later, you have to reverse-engineer an answer from fragments of communication that were never designed to hold one.
In small firms, this is especially acute. Informal communication — quick texts, phone calls, walkthrough conversations — is exactly what clients value about working with a boutique practice. It is also exactly the kind of communication that leaves no reliable record.
How Projects Actually Lose Decisions
The same situations appear across firms of every size. Three come up more than any others:
The approval that was never quite an approval. A client replies positively to an email containing five other items. Eight months later, they dispute the specific thing you thought they confirmed. The record is ambiguous. Nobody wins.
The consultant change that reached one inbox, not the team. Your structural engineer sends a revised footing detail to your project architect. It affects the finish floor elevation. Your project manager — who coordinates with the interior designer — never sees it. The millwork gets specified at the wrong elevation. The conflict surfaces on site.
The verbal site decision that disappeared. An owner-builder makes a change during a site visit — widen the mudroom doorway by four inches. The contractor agrees. Your junior staff member makes a mental note. Months later, a door delivery is delayed and your client wants to know why the drawings were never updated. Your junior staff member is no longer with the firm.
None of these situations happen because a firm is poorly run. They happen because email, PDFs, and phone calls were built for communication — not for decision capture. Those are not the same thing.
The Project Decision Log
The fix is not a new bureaucracy. It is a shift in what you organize information around. Every meaningful decision should have five elements attached to it:
- Context — What triggered this decision? What was the alternative?
- Participants — Who was involved? Who needs to know?
- Files — The drawing revision, the product spec, the photo from the site visit.
- Approval status — Proposed, approved, or rejected — and by whom, on what date.
- Action items — What happens next, and who owns it.
This does not require a separate document submitted at project milestones. It requires a habit: capturing these five elements at the moment a decision is made, while the context is obvious and the effort is minimal. Ninety seconds of clarity now prevents hours of reconstruction later.
The discipline also changes how decisions get made. When a team member knows the outcome will be recorded with an approval status and assigned actions, vague direction becomes more specific. Clients who might say "sounds fine" get prompted to confirm clearly.
Where the Log Has to Live
A decision log in a spreadsheet nobody opens, or a Word document that stops being updated after week three, is not a decision log. It is a good intention.
The version that works is embedded in the communication that already happens. When a decision is reached in a message exchange, the record lives there — with the relevant file attached, the approval marked, and the action items visible to the whole team. No separate documentation step. No parallel system to maintain.
This is the idea behind how Opeego was designed for architecture practices. Each project lives in a session — one place where conversations, files, approvals, and tasks stay together. When a consultant sends a revised drawing, the team discusses it in context, tags who needs to act, and creates the follow-up tasks without anyone's inbox becoming the single point of failure. When something is decided on a site visit, the record goes in immediately from a phone — timestamped, in context, visible to everyone.
The information architects generate every day is already good enough to build a reliable decision record. The missing piece is keeping it together, organized around the decisions that matter, rather than scattered across the tools that happened to be open at the time.
Opeego is free to start — no credit card required.
Try Opeego Free