Skip to content

Meeting Management

Pre-meeting prep

Before attending any client project meeting, arrive with context already built. Do not wait until you are in the room to learn what the project is about.

The ritual:

  1. Open the Client Insight Bot in the project's Slack channel (e.g., #smartmouth) before the meeting
  2. Ask it targeted questions: "What is this project about and why?" / "Who are the key stakeholders?" / "What are the active risks and open action items?"
  3. Write down any terms, acronyms, or concepts you don't recognize — then ask the bot to explain those too
  4. If the bot's context is thin, go to Box and review the engagement folder directly

Coming out of a meeting having heard 10–15 things you didn't understand is not a reason to ask the EM afterward. Those are queries for the bot. The bot exists to give you a pre-compressed, semantically organized view of the project so you are not consuming team time to get up to speed.

The principle: Minimize your dataset to what is entirely relevant. Ask specific questions — "What are the three biggest risks on this project right now?" — not broad ones. A context window loaded with loosely-related documents produces vague answers even when the information is technically present.

What is an action item — and what isn't

An action item is something that deviates from the standard process. It is an informal commitment made during a meeting that would otherwise fall through the cracks.

When someone says "I'll check with Steve to make sure we got the data right," that is an action item — it is not a step anyone planned for, and it will not happen unless someone tracks it.

When someone says "I'll go build the slides for next week's Steerco," that is almost certainly not an action item — that is just step five in the normal process. Everyone already knew it needed to happen. Logging it as an action item creates noise.

The test: does this commit belong to the project plan, or is it a deviation from it?

  • If it's in the plan → not an action item, just the work
  • If it would be invisible without someone tracking it → action item

Some people speak directly to the AI during meetings: "Make sure to track this as an action item." When you see that, pay attention — they are flagging something they know would otherwise disappear. But don't assume the absence of that phrase means there are no action items. Most commitments are implicit: "I'll go do that" is a commitment, even if no one called it an action item out loud.

Decisions vs. action items vs. risks

Consultant OS surfaces three separate things from every meeting — Decisions, Action Items, and Risks — and the AI will sometimes blur the lines between them. Knowing the test for each is part of your job as reviewer.

The test for a decision: did we have a choice, and did we make it? "We're going with a combination of Salesforce and HubSpot, connected through Zapier" is a decision — there were alternatives, and we picked one. "Bob will build the marketing materials" is not a decision, even though someone had to decide to ask Bob — it's an assignment. No alternatives were weighed; it's just work being handed off. That's an action item.

A useful shortcut: a decision is the reason work happens; an action item is the work. A decision to swap vendors may spawn five action items to execute the switch — the decision is not those five tasks, it's the choice that caused them to exist.

The one exception worth knowing: allocating roles across a large effort (who owns what for an entire training rollout, an onsite, a big deliverable) is itself a decision worth logging, even though it looks like a batch of assignments. "We agreed on these roles, with these people in the room" is different from thirteen individual action items. Use judgment — logging "who has the pens for the workshop" as an individual decision is overkill, but "who owns prep for this onsite" as one decision is worth having, so nobody can later claim it wasn't theirs.

The test for a risk: a risk is not a decision and not an action item — it's a problem that might happen. "The vendor might have an outage during our deployment window" is a risk. It doesn't commit anyone to anything and it doesn't reflect a choice we made. Risks and decisions do connect, though:

  • An undecided but necessary decision is often the risk itself: "we can't get the customer to sign off, and if they don't by Thursday, the timeline slips" — the risk is the absence of a decision.
  • Mitigating a risk usually produces action items (communicate the exposure, build a fallback plan, chase down the person who owes an answer).
  • Choosing how to handle a risk — reduce it, avoid it, or accept it — is itself a decision, and should be logged as one. "We decided to accept this risk and proceed" is a real decision with real accountability attached, even though it generates no further action items.

Why the decision log matters: the same senior stakeholders re-litigate the same settled questions more often than you'd expect — not usually out of bad faith, but because people forget, or weren't fully present in the meeting where the call was made, or are testing whether the decision will hold if they push again. A decision log lets you point to exactly when a decision was made, who was in the room, and (when captured) what alternatives were considered — so "didn't we already decide this?" has a real answer instead of becoming a rehashed debate. This is also why decisions belong in the meeting minutes (see below) and why getting them into the minutes fast, with an explicit call-out to read them, matters — silence on a circulated decision is the closest thing to sign-off you'll get.

Cleaning up the decision log: just like action items, the AI can mislabel things — most often by turning an obvious task assignment into a "decision" because it was told to look for decisions made in the meeting. If you see something in the decision log that's really just an assignment ("we decided Sammy will review the minutes"), delete it from the decision log — it isn't clutter you want sitting alongside real decisions.

Known platform gaps to watch for: decisions do not yet roll up to the project level the way risks and action items do — as of now you have to view them meeting by meeting. There is also no merge function yet for linking a "decision needed" entry in one meeting to the "decision made" entry in a later meeting into one continuous history — if you see the same decision appear as open in one meeting and resolved in a later one, note the connection manually (in the meeting summary or with the EM) until that linking capability ships. Flag these gaps if they're blocking you; they're recognized, not by design.

Action item lifecycle — from spoken to done

An action item goes through three states before it is real:

New (spoken in a meeting) → Confirmed (by you) → In Asana (actionable)

Until a confirmed action item is sent to Asana, it only exists in Consultant OS. No one does work from Consultant OS — contractors and team members act on what is in Asana. An action item that never makes it to Asana is an action item that will not get done.

The process after each meeting:

  1. Confirm: Review the action items logged in Consultant OS. Is each one real? Is it distinct from standard project-plan work? Does it duplicate something from a prior meeting?
  2. Send to Asana: Use the Asana button next to each confirmed action item. It adds the item to the Action Items section at the bottom of the project's Asana plan (creating that section if it doesn't exist). Do not assign items from the Consultant OS action items page — changes there only update locally, not in Asana.
  3. Follow up: Check the Asana board throughout the week. If something is overdue, surface it to the EM and the assignee.

A useful workflow: after you have confirmed and sent all action items, do a brief sync with the EM to go through the project's action items list together. They know context you may have missed; you may know status they haven't heard.

Meeting type matters: Risks and action items logged in a customer interview meeting are scoped to that customer, not the project as a whole. Check the meeting type label (top-left in Consultant OS) before treating something as a project-level risk. Interview insights belong in the platform; they do not roll up to the project risk register automatically.

Duplicate action items across meetings

In a running project, the same topic will surface across multiple meetings. A stand-up on Monday, a check-in on Wednesday, another stand-up on Friday — all three may touch the same open item.

The AI will sometimes log these as separate action items. They are not. They are the same action item with progress updates attached.

When you are auditing action items at the project level, look for duplicates and merge them. The rule is:

  • Keep the oldest occurrence as the canonical item
  • Attach the newer mentions as updates ("discussed again on [date]; 50% complete")
  • Do not close an item just because it came up again — close it when the work is actually done

Meeting scheduling — the PC owns this

You are responsible for scheduling meetings, not waiting to be asked. The standard:

  • You create the Zoom calendar invite
  • You send it to all participants
  • Participants accept; you confirm the invite landed correctly

Before running your first client meeting, verify your Zoom account can do all of the following on a test call:

  • Create meetings of the intended duration (some accounts are capped)
  • Hit Record at the start
  • Share the meeting link with non-hosts

If you hit a permissions wall, escalate to get your account upgraded — do not assume it will work in the moment.

Meeting minutes vs. meeting summary

These are two different documents with two different audiences.

The meeting summary is internal. It can be candid, direct, and specific. It might call out a difficult stakeholder, flag a project risk, or note something the team needs to watch. This is teacher-to-teacher conversation.

The official meeting minutes is customer-facing. It goes to everyone on the meeting — including the client, and potentially their leadership. It must be sanitized and inoffensive. This is teacher-to-parent conversation.

Risks do not appear in meeting minutes. Risks are your team's internal read on what might go wrong. Sending a client a list of risks identified in their organization — including potentially unflattering observations about their team or leadership — is not appropriate. Keep risks in the platform, share them internally, and leave them out of anything customer-facing.

Decisions and action items belong in the minutes. Risks do not — see "Decisions vs. action items vs. risks" above for why that split matters beyond just tone.

The rhythm of a project — and the hard part

Projects at Cortado are bursty. A typical engagement looks like:

  • 3–4 weeks of intensive work — discovery, analysis, deliverable production, client meetings back to back
  • A shorter planning window — wrapping up loose ends, preparing for the next phase or next project

The hard part is the overlap scenario: a project runs long and its wrap-up week collides with the kick-off week of the next project. When that happens, you are simultaneously tidying up all the deliverables, ensuring every action item is closed and documented, and standing up everything for the new engagement — Asana, Box, stakeholder mapping, the first client meeting.

This is the worst-case version of the PC role. It is not unusual. Know that it happens, expect it occasionally, and when you see it coming, flag it early so the engagement manager can help prioritize what actually needs to happen in what order.