team
Searching for a meeting minutes example usually turns up board minutes: motions, seconds, quorum, a vote tally. Useful if a set of bylaws is involved. Useless for the weekly delivery review that five people sit through every Tuesday.
The examples below are the second kind. They come from the meetings small teams actually run: a recurring status review, a decision meeting, a client check-in, and a post-incident review. Each one is short on purpose, and each is followed by the specific choice that makes it work. The last section shows the same meeting written the way most notes get written, so the difference is visible rather than asserted.
Meeting: Delivery review, week 39 Date: 2026-09-22 Attendees: Aoi, Ben, Chris. Absent: Dana.
Decisions
Open questions
Actions
Context CSV only was chosen because both pilot customers export CSV. Image upload needs a storage decision that is not ready yet.
Next: 2026-09-29. The migration answer has to be in before the meeting starts.
What makes this version work is the order. Decisions sit at the top, because that is what someone reading a week later is looking for. Every action carries a person and a date, so nothing needs interpreting. And the absent attendee generates an action item of its own, which is the small habit that keeps a scope change from ambushing someone on Friday.
Notice the length. This is a thirty minute meeting recorded in under two hundred words. Anything longer is usually narrative, and narrative is what nobody reads.
Meeting: Choosing the analytics approach Date: 2026-09-18 Attendees: Aoi, Ben, Priya. Question on the table: how to report weekly usage to the customer without building a reporting feature.
Options considered
Decision Scheduled weekly export to a shared folder, starting 10-06. Revisit when more than ten customers ask for it.
Actions
The extra section here is the one worth copying. Writing down what was rejected, and why, is the difference between a decision that holds and a debate that reopens every quarter. The rejection reasons are also honest about their own shelf life: option one was rejected for now, with a stated trigger for revisiting it. A decision with a trigger attached does not need to be defended again next month.
For the same reason, the estimate is written as roughly three weeks rather than a precise figure nobody measured. Fake precision in minutes gets quoted back later as if it were a commitment.
Meeting: Monthly check-in with the client Date: 2026-09-11 Present: client side, two people. Team side, two people.
What was agreed
What was promised out loud
Open on the client side
Actions
External minutes need one section internal minutes do not: what was promised out loud. Commitments made in conversation are the ones that turn into disputes, and writing them down the same day is the cheapest insurance available. The phrase no commitment to change it is doing real work in that line, because it records the limit of the promise alongside the promise.
Two practical rules go with this example. Send it the same day, and keep the internal version separate. Internal notes about pricing, staffing or frustration do not belong in the document that goes to the client, and merging the two files is how they leak.
Meeting: Review of the 09-14 outage Date: 2026-09-16 Attendees: Ben, Chris, Priya.
What happened The scheduled job failed at 02:10 and was not noticed until 09:40. Roughly seven hours of exports did not run.
Contributing causes
Decisions
Actions
Review minutes are the one place where a short account of events belongs, because the sequence is part of the finding. Everything else follows the same shape as the others. Note what is missing: no names attached to the mistake. Minutes that assign blame produce meetings where nobody volunteers what they saw, which costs more than the outage.
For contrast, here is the first example as it often gets written.
Delivery review. Everyone attended except Dana. Aoi opened by saying the import screen was mostly ready, but Ben raised a concern about the legacy fields and there was a long discussion about whether a migration would be needed. Chris said the release note was not started. There was general agreement that image upload probably slips. Aoi will follow up with Dana. Meeting ended at 10:35.
Everything in that paragraph happened. Almost none of it survives contact with a reader a week later. There is no shipping date, no owner on the migration question, no due date on the release note, and image upload probably slips is not a decision anyone can act on or point back to. The reader has to ask someone, which is the outcome the minutes were supposed to prevent.
The fix is mechanical rather than stylistic. Replace the narrative with three headings: decisions, open questions, actions. Force each line under actions to contain a name and a date. The writing gets shorter, and the record starts answering questions instead of describing a conversation.
Copying one of these examples straight into a different meeting rarely survives more than a few weeks. Teams add fields, and the additions are what kill the habit. A short test keeps the format honest: before adding a field, name the question it answers for a reader a month from now. If the answer is vague, leave it out.
Some additions do earn their place. A recurring meeting that tracks delivery dates benefits from a single line listing anything already known to be late, placed above the decisions, so the meeting starts with reality rather than with the agenda. A meeting that repeatedly runs out of time benefits from a carried-over line, listing what was pushed to next week, so the same topic does not silently disappear. Teams working across time zones often add a line naming who still has to be told, which turns the absent list into an action rather than a note.
Fields that look helpful and are not: a duration field, a mood or energy rating, a list of documents referenced without links, and a status column on action items. That last one is the most common mistake. Status belongs where the task lives, not in a static document, and maintaining it in both places guarantees they disagree within two weeks.
The other adaptation worth making is the writing rhythm. For a meeting with a fixed agenda, pre-fill the headings before it starts so the note taker is completing a page rather than composing one. For an unstructured meeting, write nothing but decisions and actions during the call, then spend three minutes afterwards adding the context line for each decision while it is still fresh.
One more rule applies to every variation. Keep the field names identical across meetings, even when the content differs. Consistent names are what make a search across a year of records return anything useful, and they let anyone stepping in as note taker work without being briefed. A format that changes depending on who typed it is a format nobody can search.
Finally, agree on where the record goes before changing the format, not after. A better template stored in a place nobody opens is still a worse outcome than a plain one stored where the work happens.
| Meeting type | The section that carries it | The section to skip |
|---|---|---|
| Weekly team meeting | Actions with owners and dates | Any account of the discussion |
| Decision meeting | Options rejected, and why | Minute by minute order of speakers |
| Client check-in | What was promised out loud | Internal commentary of any kind |
| Post-incident review | Sequence of events and causes | Names attached to the mistake |
Three rules run through all of them. Write decisions in the present tense as completed choices. Give every action an owner and a date, without exception. And record the reason behind a decision in one sentence, because the reason is the part that stops the same argument from restarting.
The last shared trait is where the records end up. Examples like these stay useful only if the action items leave the document and become real tasks in the place the team works. A record that lives in a file, with follow-ups trapped inside it as bullet points, depends entirely on someone rereading the file. Putting each action on a board as a card with an owner and a due date removes that dependency, and the written record stays as the explanation behind the cards. A feature overview is worth checking for that one property: whether the write-up and its tasks can sit in the same workspace.
Take the minutes from the last recurring meeting and rewrite them into three headings: decisions, open questions, actions. If any line cannot be given an owner and a date, it was never an action.
Then move those actions out of the document and into the board the team opens every morning, keeping a link back to the write-up. Pinateca is one place to keep both together, and the FAQ answers the practical questions about boards, members and what the free tier covers.
One screen for a normal working meeting. Detail belongs in the decisions and actions, not in the account of the discussion. Formal minutes for a board or statutory meeting follow different rules and are as long as the bylaws require.
Generally no. Attributed opinions make people careful in the next meeting, and the attribution rarely matters later. The exceptions are formal votes, where attribution is required, and cases where someone explicitly asks for a position to be recorded.
Present tense, as completed choices: the import screen ships on the 30th with CSV only. Past tense narration such as the team discussed shipping leaves the reader unsure whether anything was settled.
For statutory minutes, approval at the next meeting is usually part of the process. For working notes, sending them out the same day and inviting corrections in the first day works better, since the memory of the room fades fast and a correction on day one is cheap.
Keep working notes as long as the project is live, and longer if they explain decisions still in force. Statutory minutes have retention periods set by law or by the bylaws, which the company secretary or an accountant can confirm for the relevant jurisdiction.