Minutes are a critical tool for organizations to keep track of decisions, important events, and keep open lines of communication with the intention of making everyone more productive. However, bad minutes taken during a critical meeting can derail teams and cost businesses valuable time trying to re-coordinate and recover the lost information. The tricky thing about minutes is that it can be difficult to define a set of concrete steps that will always lead to "perfect" minutes, but we will cover how the preparing for the right kind of meeting will help you write better minutes and hopefully save you a lot of time and headache in the long run.

Not all meetings are the same and there is no point in taking formal meeting minutes and action items like you would at a board meeting at an ad hoc team meeting or a one-on-one with a colleague. Put simply, the formality and detail of the minutes should correspond directly with the formality of the meeting and the importance of the information discussed. That being said, all good minutes have the following in common: all key decisions and major ideas discussed in the meeting have been captured. If you are writing minutes for a quick team meeting to discuss a workaround to a roadblock you’ve been facing, you might draft up some bullet points about the important points discussed and the course of action agreed upon. Since everyone who is impacted by the decision was at that meeting, you likely don’t need to write down too much context and reasoning for why the decision was made, rather your minutes should help cue in attendees about the next actions should they look back on the minutes at a later time. In a board meeting, however, you should add all the relevant context you can to the key decisions and major ideas as the topics discussed here will affect far more than just the attendees of the meeting. Someone who needs to understand the changes proposed at the board meeting but who wasn’t in attendance should be able to look at the minutes and understand the thought process that led to the key decisions.

Check out the following example: suppose your organization runs into the following hypothetical problem: A third-party tool (Tool X) that is used organization-wide is set to cease operations, causing you to find a replacement solution. Both the board meeting and team meeting discuss the same ideas: either taking the time and resources to build a similar internal tool (Tool Y) to avoid having this issue ever arise again, or reaching out to the tool’s competitors and requesting some proposals for how they could handle your use case. Both meetings end up deciding on the same thing: to build the tool internally, but the documentation around each decision would vary quite a bit.
The team’s meeting notes might look something like this:


Purpose of meeting: To discuss next actions in replacing Tool X with a new solution.

Building the tool internally would help avoid this issue in the future, Ben has some experience building similar technology.

Action Items:

  1. Sync up with Ben to lay out the total cost and timeline of replacing the tool internally.
  2. Relay results to management and allocate team resources to building Tool Y.
  3. Contact UX team and put together a concrete list of use cases that are needed from Tool Y.

Whereas the board meeting’s notes on this particular issue might look something like this:


Purpose of meeting: To discuss next actions in replacing Tool X with a new solution.

Two main options were considered:

  1. Sending out calls for proposals from Tool X’s competitors. This would save time and money in the short term and might ease the transition by moving to a similar tool with the same core feature-set. The issue is that a similar problem like the current one might arise in the future and another switch would be needed. The sales cycle for such a large enterprise use case might also take a while and new employee training would be required.
  2. Replicating Tool X’s core feature set for internal use. This approach would almost certainly take longer than transitioning to a competitor and cost more up-front, but would prevent the possibility of needing to switch again later. There is also risk associated with starting to use a tool that has not been tested by the market before. On the other hand, one of the development teams has just freed up from a separate project and would be able to take this on. Some developers in the organization also have experience with technology similar to what’s required from a new Tool Y. A development timeline is needed to make sure the organization doesn't have to spend a large amount of time with no tool.

After consideration, option 2 (building a custom internal tool) was selected as the benefits of having full control over the tool’s feature set and the fact that the organization is in a good position to create an equivalent with a free team of developers outweighs the benefits of option 1 (switching to a competitor of Tool X).

Action items:

  1. Put together a detailed budget and timeline for building out Tool Y and assign to the free team. Circle back on progress in the next meeting.

As you can see, the decisions and logical paths of both meetings are similar, but both the content of the minutes themselves and the resulting action items are different. The board's minutes have significantly more content around the decision and the resulting action items are quite general as the specifics will be decided by another team and that would be outside of the board's scope. On the other hand, the team meeting's minutes just needed to mark the key decisions but much more specific action items and next steps were written as they are the ones who would be following through on those tasks.


Board meetings and team meetings are not the only kinds of meetings where a specific minute-taking structure is important. There are a number of different meeting 'classes' and tailoring your minutes to the particular kind of meeting will help you both document the important information correctly and will save you time. As you see in both the team meeting and board meeting, the minutes are not transcripts of what happened during the meeting, they are synthesized points outlining the major ideas and actions. They are both useful to others looking at the minutes after the fact and don't require too much work after the meeting is over to edit and adjust. With this information in mind, try to sort out the types of meetings you are actively taking minutes for beforehand and think about how you can save yourself time and energy by just focusing on the most important aspects instead of logging every detail.