The Intent Ledger
← All articles

Site Meeting Minutes: What to Record and a Template

Site Meeting Minutes: What to Record and a Template

Site meeting minutes are the written record of what a project team agreed on site: the decisions, the actions with named owners and dates, and the open questions. Good ones are short, factual, issued within days and tied to the project’s formal registers. Great ones also keep the reason a decision was made, because that is what people lose first. This guide gives you the structure, a template you can copy, the habits that make minutes defensible, and a way to keep the “why” alongside the “what”.

Theintentledger
theintentledger.com
Keep the Why Behind Decisions
The Intent Ledger turns project conversations, meeting notes, and client comments into source-backed records of decisions, actions, and open questions.
Explore project memory software

TL;DR

  • Record outcomes, not conversation: decisions, actions (one named owner, one firm date), and unresolved questions.
  • Issue minutes fast. A New York State DOT engineering bulletin points to three working days as the benchmark, and a short objection window turns the draft into the agreed record.
  • Pull RFI, change and claim numbers from the project registers, never from memory.
  • Add one line of rationale to every decision that was debated. It is the cheapest insurance against rework.
  • Carry open actions forward with their original item number so nothing quietly ages.

Table of Contents

What site meeting minutes are for

Minutes are not a diary of the meeting. Industry guidance treats them as a formal record of agreed actions, decisions and instructions, and they are often among the first documents pulled when a dispute starts. The New York State DOT bulletin on construction meetings is a public example of an owner spelling out how minutes should be handled on its projects.

That changes how you write them. You are not trying to capture everything said. You are producing an audit trail that someone who was not in the room, perhaps months later, can read and understand without calling anyone.

A useful test: could a new project manager who joins in week twelve read the minutes from week four and know what was decided, who owed what, and what was still open? If yes, the minutes work.

What to include in site meeting minutes

When people ask what a set of minutes should contain, the answer is consistent across the sources we reviewed. The core items:

  1. Administrative facts. Project name, meeting number, date, time, location, who attended and who sent apologies.
  2. Review of previous minutes. Confirm them or note corrections, then update the status of every open item.
  3. Agenda topics. Typical site topics include progress against the programme, safety, material deliveries or shortages, shop drawing submittals and approvals, RFIs, changes and site problems. A NYC Department of Design and Construction outline shows how a public owner lays out a cover sheet and numbered items.
  4. Decisions. What was decided, by whom, and on what basis.
  5. Actions. An owner, a deadline, and a reference to the register entry where relevant.
  6. Open questions. Things raised and not resolved, with who will answer them.
  7. Next meeting. Date, time and the main agenda items.
  8. Distribution. Who receives the minutes and by when objections are due.

Where a formal vote or approval happens, record the motion, who moved it and the outcome. Keep opinions and verbatim exchanges out. Guidance from association secretaries makes the same point: minutes are not a detailed report of the discussion.

A copyable site meeting minutes template

Paste this into a document, spreadsheet or your own tool. Keep the headings stable from week to week so readers know where to look.

Header

  • Project: ______ Meeting no.: ___ Date/time: ______ Location: ______
  • Minutes prepared by: ______ Issued on: ______ Objections due by: ______
  • Present: name, company, role. Apologies: name, company.

1. Previous minutes

  • Accepted / accepted with corrections (list them).

2. Progress and programme

  • Work completed since last meeting. Work planned for next period. Delays and their cause.

3. Design and information

  • RFIs (register no., status). Submittals (register no., status). Drawing revisions issued.

4. Changes and instructions

  • Change or variation no. (from register), description, status, who instructed.

5. Safety, quality and site issues

  • Incidents, inspections, defects, access, deliveries.

6. Decisions made

ID Decision Made by Reason (the why) Source
D-014 Example: switch to alternate cladding fixing Architect, with client’s agreement Example: original detail failed the mock-up water test Meeting 12, item 3

7. Actions

Ref Action Owner (one person) Due Status
12.3 Example: reissue revised detail Named person Date Open

8. Unresolved questions

  • Question, who answers, needed by when.

9. Next meeting

  • Date, time, location, lead agenda items.

The table rows are placeholders to show the format, not real project data.

Habits that make minutes hold up

Issue them quickly and set an objection window

Speed matters because memory fades and positions harden. The DOT bulletin cited above points to issuing within three working days. Many teams go faster, and your contract may set its own deadline, so check it.

Then use the “no objection” convention. As one construction template explains, circulated draft minutes stand as the agreed record if nobody objects within a set period, typically three to five working days. State the deadline in the header of every set. It shifts the burden: anyone who disagrees has to say so in writing, early.

If someone does object, add a line recording the objection and take it up at the next meeting. Do not quietly rewrite the minutes.

Give every action one named owner and a date

A task is something that needs doing. An action item in minutes needs a person (not a company) and a firm date. “Contractor to review” is a wish. “M. Alvarez to confirm the slab pour date by Friday 23 October” is an action.

When an action rolls over, keep its original meeting and item number. Its true age stays visible, and “zombie” items that sit open for months get embarrassing enough to close.

Reference the registers, do not retype them

RFI, variation and claim numbers should come straight from their registers. The same template warns that recording them from memory creates two versions of the truth in which minutes drift away from the formal records. In the minutes, write the number, a short title and the status, and let the register hold the detail.

Write for the audit trail, not the transcript

The most common mistake is treating minutes as a transcript. Keep them objective: facts, outcomes, assignments. If the team wants a standard to adopt, an AIPMCM standard for project minutes frames the goal as making each meeting a traceable, auditable record of decisions, actions and risks.

On style, concise and factual wins. This short piece on documenting meetings covers the same ground on keeping records plain and on what status approved minutes should carry. It is written from a UK angle, so apply your own contract and local rules.

State the objective before the meeting

Meetings with a stated objective produce decisions backed by evidence instead of improvisation. Circulate the agenda with the data people need to bring: the pending RFI list, the three-week look-ahead, the sample or mock-up photos. Decisions made at the end then rest on something you can cite in the minutes.

Where minutes fall short: the missing “why”

Standard minutes capture what was decided. They rarely capture why. “Use alternate cladding fixing” is in the record. The reason, the options rejected and the risk someone flagged are not.

That gap matters most on design-led work. Research on decision-making history in architectural practice, such as this eCAADe paper on tracing the decision history of architectural scripts, describes decisions that end up embedded in the work itself with no established way to trace them, which raises risk and error when the work is reused. The setting there is architectural scripting, but the pattern is familiar on any site: the reasoning lives in people’s heads until they leave the project.

You see the cost when:

  • A subcontractor asks why a detail changed and nobody can say.
  • A client says they never approved a revision, and the minutes show only that a revision was issued.
  • A junior designer inherits a drawing set and cannot tell a deliberate choice from a placeholder.

A practical fix costs one extra column. For every decision that was debated, write one sentence of rationale and note the source (meeting number and item). Give decisions short IDs such as D-001, D-002, so later documents can point to them. The AIPMCM standard above recommends the same traceability approach.

For more on what a decision record should hold, see our guide to the fields a record of decision needs, and our notes on client meeting documentation.

Our perspective: minutes should be a memory, not just a log

We build project memory software for design teams, so we read minutes with one question: if this were the only thing left, could someone rebuild the thinking?

Most minutes pass the “who does what” test and fail the “why” test. The reason is simple. Writing minutes is a chore done after a long meeting, and the rationale is the part that takes the most effort to summarize. So it gets dropped, and with it the link back to the conversation where the decision happened.

Our view is that a decision should never be separated from its source. A good record names the decision, the intent behind it, the risk it carries, the actions that follow, and the place in the conversation where it came from. That is what we call an ILM Record, and it is why we treat minutes, critique notes, transcripts and client comments as raw material for structured records instead of finished documents.

This does not replace the formal project registers or your contract’s rules on minutes. It sits beside them and keeps the context those documents leave out. Keep the register as the authority for numbers and status, and keep the record as the memory of how the team got there.

, Rajas

Capturing client and design feedback on site

Site meetings are also where clients react to what they see: a finish, a sightline, a change they would like. These moments are dialogues, and a list of tasks flattens them. If the client says the entry feels too dark, “increase glazing” loses the concern that should guide the solution.

Two habits help:

  • Record the concern and the instruction separately. Write what the client said they wanted or feared, then what was agreed to do about it.
  • Get approvals in writing, close to the event. Send the approval line in the minutes or a short follow-up message the same day. This article on client approvals is aimed at UK sole tradespeople, but its point travels: log the approval and any cost change on the spot, not weeks later.

For design review conversations specifically, our design review notes templates and design review checklist show how to hold decisions across phases.

Minutes from voice notes, recordings and transcripts

Many teams now record site meetings or dictate notes. That is fine for speed, but a transcript is not minutes. It is long, includes tangents, and attributes nothing to a decision. Treat it as source material: pull out decisions, actions and open questions, and keep a pointer from each to the place in the recording or transcript.

On retention, some guidance advises discarding raw notes once minutes are approved. Whether you may or should do that depends on your contract, your company’s records policy and any legal hold, so confirm with your project counsel or records manager before deleting anything. Keeping the pointer to the source is only useful if the source still exists.

Putting it into practice: a weekly rhythm

  1. Before the meeting. Circulate the agenda, objective and the open-actions list from last time.
  2. During. Take rough notes straight into the template’s headings. Mark decisions as they happen and ask for the reason out loud when it is missing.
  3. Within a day or two. Draft the minutes, check RFI and change numbers against the registers, and confirm every action has one owner and one date.
  4. Issue with an objection date. Put it in the header.
  5. At the next meeting. Start by confirming the minutes and walking the open actions, oldest first.

How The Intent Ledger helps

If your team spends meetings talking and evenings reconstructing them, The Intent Ledger turns meeting notes, transcripts, critique feedback and client comments into ILM Records: structured, source-backed records of decisions, design intent, risks, actions, commitments and unresolved questions, each traceable to the conversation it came from.

You can start small with a one-off pack: Working Set at $12, Project Record at $29, Practice Memory at $59 or Studio Ledger at $119. For ongoing capacity there are monthly plans: Working Memory at $29 per month, Living Record at $79 per month and Shared Ledger at $149 per month. See the details on our pricing page, or look at the platform overview.

FAQ

How soon should site meeting minutes be issued?

As soon as practical. The NY State DOT bulletin cited above points to three working days as a benchmark, and some teams aim for 24 hours. Check your contract, because it may set a specific deadline.

What is the no-objection rule?

It is a convention where the circulated draft becomes the agreed record unless someone objects in writing within a stated window, typically three to five working days. State the deadline in the header of every set of minutes. Any objection is recorded and resolved at the next meeting.

Should minutes record who said what?

Generally no. Record outcomes: decisions, actions and open questions, with names attached to actions and, where it matters, to approvals and votes. Verbatim discussion and unessential opinions make minutes longer and harder to defend.

Can AI write my site meeting minutes?

It can draft a summary from a recording or transcript, but a person on the project should check it against the registers and confirm owners and dates before issue. The risk is a confident summary that misses a decision or invents a deadline. Treat AI output as a first draft, not the record.

Sources