When Twelve OAC Meetings Decide an Opening, Minutes Need to Be Records

The Cadence That Decides the Opening

A retail construction project does not decide itself in one big meeting. It decides itself across a recurring cadence of Owner-Architect-Contractor meetings that runs from kickoff to grand opening. In commercial construction, that arc can last 18 to 36 months across 50 or more meetings. In retail, the arc compresses to 3 to 6 months across 12 to 20 meetings. Each meeting matters disproportionately because there are not many of them.

OAC is also not the only meeting on the project. A single store opening typically runs 4 to 6 parallel coordination streams underneath the OAC: MEP coordination during rough-in, FF&E coordination near opening, technology deployment for POS and AV, brand and visual merch coordination before the doors open, and direct vendor calls with specialty trades (refrigeration for grocery, sign vendors for QSR, EV charging for some retailers). Each stream produces its own minutes, action items, and decisions.

Multiply this across an active portfolio. An operator running 50 concurrent projects faces something close to 50 weekly OAC meetings and several hundred parallel coordination sessions per week. Each one produces a document. Each document contains a few decisions, a few action items, and some narrative prose. Almost none of those documents talk to each other.

Why the 'Minutes Within 24 Hours' Standard Is Observed in the Breach

The construction industry has a stated norm that OAC minutes are issued within 24 hours of the meeting. Late minutes mean late action items, and late action items mean late projects. Every textbook and every general conditions document repeats the rule.

In practice, the 24-hour standard rarely survives contact with the actual workload. A general contractor PM running 4 to 6 active projects has 4 to 6 OAC meetings to minute every week, on top of running the field. Minutes get drafted on Friday afternoons. Distribution slips to Monday or Tuesday of the following week. By the time the recipients open them, the action items they record are already 5 days old, the conversation has moved on, and minor decisions have started to drift.

AI notetakers are starting to dent the drafting problem. They join the call, transcribe in real time, and produce a structured draft minutes within minutes of the meeting ending. That is real progress on one bottleneck. But it does not solve the structural problem underneath. The structured draft is still a document. It still lives in an inbox or a shared drive. The action items it contains still have to be re-keyed into whichever tool the team uses to track tasks. The decisions it records still get searched for by Cmd-F three months later when someone needs to know what was agreed.

Why Coordination Tools Fall Short at Portfolio Scale

Most teams run their meeting record in some combination of Word documents, emailed PDFs, OneNote, a shared drive, and whichever project management tool the general contractor happens to be using. Each format has the same structural failure: the meeting output is not data that the rest of the project can read.

Action items captured in a meeting are tracked in a different system from the project plan. The reconciliation between the two breaks down by week six of a typical project, after which the meeting's action items and the project's task list drift apart. Decisions are buried in narrative prose. They cannot be queried across meetings on the same project, much less across projects on the same prototype. Carryover from last week's open items is a manual copy-paste exercise that quietly stops happening when the PM gets busy.

The deeper failure is that published minutes are not auditable. A PDF on a shared drive can be silently overwritten. A Word document can be revised without a trail. When a vendor argues months later that a change order is warranted because of a verbal commitment made in OAC #7, the team has no immutable record to point to. The minutes are just another document, easy to dispute and hard to defend.

What Meeting Records Need to Do at Multisite Scale

The capabilities that solve this do not require a separate meeting tool. They require the meeting record to live on the project record, with the same structured-data treatment the rest of the project gets.

Meetings need to be first-class objects, not attached documents. They should carry a project-scoped identifier (something like MEET-14, with a tenant-configurable prefix) so the label is clean in dispute filings and in cross-team conversation. The meeting type catalog should be tenant-curated, with agenda templates that pre-fill the notes so every PM starts from the same playbook rather than a blank canvas.

Decisions need to be structured records, not paragraphs. Each decision carries a title, an optional description, a decided-on date, and a link to the meeting where it was made. When a later meeting reverses or refines an earlier decision, the two should link to each other bidirectionally so the trail reads correctly in either direction. A PM rotating onto the project a year later should be able to read the decision history without going to the original participants.

Action items need to be the same tasks the project plan tracks, not a parallel system. When the team captures an action item in a meeting, it should become a project task with the same assignee, due date, status, and priority as any other task. It should appear in the assignee's personal inbox and in the project's task views. There is no separate meeting-items system to reconcile against the project plan because there is no separate system.

Carryover needs to be structural, not manual. Open action items from prior meetings on the project should appear on the next meeting's agenda automatically, with inline triage to mark each one complete, cancel it, or defer it. Stalled blockers get put back in front of the team week after week until they close, without anyone remembering to copy them forward.

Publishing needs to lock the record and audit subsequent edits. When the meeting is over, publishing the minutes notifies every attendee through the platform's central notification system and stamps the record as official. Edits after publish remain possible (typos happen) but every change lands in an audit log. A record that may end up in a claim file cannot be quietly rewritten.

A recent platform update from RolloutIQ wired meetings into the project record on these lines. Per-project numbering with a configurable prefix, tenant-curated meeting types with agenda templates, decisions with bidirectional supersession, action items as first-class Tasks, automatic carryover surfaces, and publish-with-audit are all part of the surface. The point is not the specific implementation. The point is that coordination meetings at multisite scale need to live on the project, not in a folder.

What This Looks Like in Practice

Run through a typical 26-week storefront refresh. MEET-1 is the project kickoff and owner alignment. Five attendees, three action items, two decisions. Publish. The five attendees receive notifications on their preferred channel; the published meeting becomes the project's official record of what was agreed at kickoff.

Two weeks later, MEET-2 is the site walk and survey review. When the PM opens the meeting, the carryover panel automatically surfaces the open action items from MEET-1. Two of them have been completed and the PM marks them done inline. One is still open and stays on the agenda. The team adds new action items and decisions for the site walk. Publish.

Six weeks in, MEET-3 covers MEP coordination and long-lead items. The team makes a decision about a transformer substitution that supersedes an earlier decision from MEET-1. The two decisions link to each other bidirectionally; the MEET-1 decision now reads 'superseded by MEET-3-D02', and the MEET-3 decision reads 'supersedes MEET-1-D03'. The trail is intact in either direction.

Near opening, MEET-4 covers FF&E and brand standards. By now the carryover panel is showing open action items from across the earlier meetings. The team triages each one. Five new action items go onto the assignees' personal task inboxes.

When a PM rotates onto this project four months later, they do not inherit a folder of conflicting Word documents. They inherit a sequenced set of published meetings on the project record, with dated decisions, supersession links between them, and a complete history of which action items were closed when. Onboarding compresses from days to hours because the project literally documents itself.

How to Evaluate Meeting Capability

Most operators evaluating meeting tooling default to feature checklists: rich-text editor, attachments, attendees. The more useful evaluation runs against the structural questions that determine whether the record will hold up across a portfolio and across project turnover. When evaluating coordination meeting capability for multisite retail operations, look for these specifics:

• Meetings as first-class records on the project, not documents attached to the project
• Per-project meeting numbering with a tenant-configurable prefix, so labels stay clean in dispute filings and cross-team conversation
• Tenant-managed meeting type catalog with agenda templates that pre-fill notes
• Decisions as structured records with bidirectional supersession links across meetings
• Action items captured in meetings become first-class project tasks with the same assignee, due date, and status as the rest of the plan
• Automatic carryover of open action items onto the next meeting's agenda with inline triage
• Publish lifecycle that locks the record, notifies attendees through the platform's notification system, and audit-logs every subsequent edit
• Attendee scoping to the project team, with per-attendee Attended or Not Attended pills so the published record reflects who actually showed up
• Files and comments side panels on the meeting, backed by the platform's central file and comment systems so attachments and discussion are durable

The Bottom Line

The structural test is whether the meeting record lives on the project or in a folder. Anything that lives in a folder is going to fragment across documents at multisite scale, because retail PMs do not have the time to reconcile 50 weekly OACs plus their parallel coordination streams against the project plan. The tools have to treat decisions as structured records, action items as first-class tasks, and publishing as a lifecycle event. When they do, the project documents itself in a way that survives PM turnover, supports change-order disputes, and stops re-litigating the same decisions three months later.