“We should call customers sooner when a part is delayed.”
Everyone agrees with the idea. The meeting ends. A week later, nothing has changed because nobody agreed who would make the calls, when the rule would apply, or where the work would be tracked.
An AI summary might make the discussion sound more organized. It cannot supply the decisions the group never made.
The people, meeting, and procedures below belong to the fictional Mesa Equipment Service example. They are teaching material, not an account of a real meeting.
Your result from this chapter: an approved action record and a draft operating procedure that someone else can follow.
Decide what the meeting should produce
Before the meeting, name its purpose. Are people sharing information, resolving a problem, choosing a policy, or assigning work?
For Mesa, the meeting addresses delayed parts and inconsistent customer updates. The desired outputs are a decision about a limited notification pilot, named follow-up actions, and a draft procedure for review.
An agenda can make the gaps visible in advance:
- What is happening now?
- Which facts are confirmed, and what remains uncertain?
- What will change during the pilot?
- Who owns each action, and when is it due?
- What needs approval before the new process takes effect?
AI can help draft that agenda from permitted background notes. A person still decides which decisions the meeting has authority to make.
Choose an appropriate record
You can work from manually written notes, a permitted transcript, or an approved meeting assistant. A recording is not required for every useful summary.
Before recording or transcribing, follow the organization's rules and applicable consent requirements. Tell participants how the record will be used, who can access it, and how it will be retained. Some meetings involve information that should not enter the chosen tool at all.
Check the actual account and sharing settings. The invite list, transcript access, and generated-note recipients may not be identical.
Automated notes need review. Google's Meet guidance explicitly says summaries can be incomplete, inaccurate, or unavailable. A generated document should therefore be treated as a proposed record until someone checks it. Google Meet note-taking guidance.
Preserve the difference between a suggestion and a decision
Use four categories:
| Category | Meaning | Example |
|---|---|---|
| Decision | An authorized choice the group actually made | Pilot one daily review of delayed-parts cases |
| Action | Work assigned to a person | Elena drafts the review checklist by September 10 |
| Proposal | An idea discussed but not approved | Offer a discount whenever a part is late |
| Open question | Something still unresolved | Who covers the review when Elena is absent? |
Do not convert “we could” into “we will.” Do not assign work to the person who mentioned an idea unless they actually accepted responsibility.
If a due date is absent, say so. A summary that invents a deadline may look useful while creating a false record of what someone agreed to do.
Work through a short meeting extract
In the fictional meeting on September 8, 2026, the notes contain these points:
M01 — Owner: “For the pilot, review open delayed-parts cases once each business day. Do not promise an arrival date unless the supplier has actually confirmed it.”
M02 — Elena: “I will draft the checklist by September 10.”
M03 — Luis: “I can prepare a list of jobs waiting for parts by September 9.”
M04 — Owner: “I will review the checklist by September 11. The written procedure is a draft until I approve it.”
M05 — Elena: “Maybe we should offer an automatic discount.”
M06 — Owner: “No decision on discounts today. Our current approval rule remains.”
M07 — Group: “We still need to decide who covers this when Elena is out.”
The approved meeting record should preserve the pilot's decisions, three actions, an unapproved proposal, and an unresolved coverage question. The automatic discount is not a new policy.
Use this prompt:
Prepare a proposed meeting record from the supplied notes.
Separate decisions, actions, proposals, and open questions.
For each item, cite the source note ID.
For each action, give the owner and due date only when explicitly supplied.
Mark missing owners or dates as unassigned or not agreed.
Preserve limits on approval and authority. Do not turn suggestions into
decisions, infer unanimous agreement, or invent a policy.
Return an action table and a short list of items the meeting owner must verify.
Do not send the record or create tasks in another system.
The three action rows should be:
| Action | Owner | Due date | Evidence |
|---|---|---|---|
| Prepare the delayed-jobs list | Luis | September 9, 2026 | M03 |
| Draft the checklist | Elena | September 10, 2026 | M02 |
| Review the checklist | Owner | September 11, 2026 | M04 |
The reviewer checks the notes and confirms any ambiguous wording with participants before treating the record as final.
Finish the handoff after the summary
Put approved actions in the team's normal task system, with their evidence and owner. Confirm that the tasks were created successfully and avoid creating duplicates when the same notes are processed again.
Send or share only the approved record with the intended audience. Keep sensitive discussion out of a broad summary where it does not belong. Retain the source record according to the organization's policy.
At the next review, ask what happened to the actions. “A summary was generated” is not a useful completion measure for the underlying work.
Turn a stable process into an operating procedure
A standard operating procedure, or SOP, explains how to carry out a recurring task. It needs more than a list of good intentions.
Build the draft from approved policy, actual practice, and the process owner's decisions. A meeting may identify the need for a procedure without containing all of its steps.
Ask a knowledgeable person to walk through the job. What starts it? Which records are needed? What changes the normal path? How does someone know the work is finished?
AI can organize that information and identify gaps. It should label proposed steps that do not yet have approval.
A worked draft: reviewing delayed-parts cases
The following procedure is proposed for the fictional pilot. It has not been approved or executed in a real business.
Purpose: keep delayed-parts cases visible and prepare accurate customer updates.
Trigger: the assigned coordinator begins the daily review on a business day.
Inputs: the current open-jobs list, supplier messages, customer case history, and the approved communication policy.
Steps:
- Open the current delayed-jobs list and confirm its update time.
- For each case, check whether the required part is still outstanding.
- Compare the latest supplier message with earlier information. Record whether an arrival date is confirmed, estimated, or unknown.
- Review what the customer has already been told.
- Prepare an update when needed, preserving uncertainty and avoiding an unsupported promise.
- Have the responsible person review and send the message through the normal case system.
- Record the actual message and next follow-up action. Flag any decision outside the coordinator's authority.
Exceptions: if sources conflict, the case history is missing, or the customer requests compensation, route the case to the responsible person. The existing manager-approval rule for discounts and refunds remains in effect.
Completion: each eligible case has a current status, a responsible owner, and a next action or a documented reason no action is needed.
Unresolved approval item: the backup for coordinator absence has not been assigned. The process owner must resolve coverage before relying on the procedure for continuous operation.
The draft adds proposed implementation detail to the meeting's decisions. The owner must review those details rather than assume they were all agreed in the meeting.
Check the procedure with someone who did not write it
Give a trained colleague one permitted practice case and the draft procedure. Ask them to explain or carry out the steps in a test setting. Watch where they need undocumented knowledge.
If they cannot find the source, identify an exception, or tell whether the task is complete, revise the procedure. Do not solve every gap by adding another long paragraph. A clearer field, example, or decision table may help more.
For physical, safety-sensitive, or regulated tasks, have the appropriate qualified person validate the procedure against the applicable authoritative instructions. An AI-written procedure is not a substitute for that expertise.
After approval, record the owner, effective date, version, review triggers, and location. Keep superseded versions out of ordinary use while retaining necessary history.
Measure whether meetings and procedures improve work
For meetings, track whether decisions are accurately recorded, action owners and dates are clear, and assigned work is completed. Note corrections required after summary review.
For procedures, track missed steps, exception handling, completion time, and how often staff need help. Compare similar cases before and after the change.
An illustrative preparation result might be twenty minutes to write a record manually versus eight minutes to generate and check it. If another ten minutes is spent correcting invented actions later, the apparent saving shrinks to two minutes. Include that later rework.
Your next step: use the meeting notes to produce an action record and a proposed SOP. Keep approval status visible, then move to Chapter 12 to process the documents that feed these operations.