Meeting action register from operational notes

Use this workflow after each recurring operational meeting to produce one action register that people can work from. It is for operations leads who receive decisions and updates across meeting notes, chat threads and project documents.

The output is not a cleaned-up meeting summary. It is a dated register of commitments, unresolved decisions and blockers, with a named owner for every item.

1. Set up the register before reading

Create one shared table for the meeting series. Use the same fields each time so actions can be carried forward rather than copied into a new list.

Include these columns:

Field	What to enter	Rule
Action ID	A stable reference, such as OPS-2026-08-01	Do not reuse an ID.
Action	One observable task	Start with a verb.
Owner	One accountable person	A team is not an owner.
Due date	A calendar date	Do not accept “next week”.
Status	Not started, in progress, blocked, done or cancelled	Update after each meeting.
Dependency	The action, decision or external input required first	Write None if there is no dependency.
Source	Meeting date, chat link or document name and section	Let a reviewer find the original wording.
Escalation needed	Yes or no, plus the decision required	Use this for matters outside the group’s authority.

Keep a separate Decisions tab or section with: decision ID, decision statement, decision owner, date made, evidence, and review date if the decision is temporary.

2. Gather the source pack

Collect material from the agreed reporting period before asking the model to extract anything. Name each item clearly, for example Operations meeting notes, 14 August, Warehouse chat update, 15 August, and Supplier transition plan, section 3.

Use this order:

1. Start with the meeting agenda and notes. They establish what was discussed and agreed.
2. Add chat updates posted since the previous meeting. Include the author and date where available.
3. Add project documents that contain milestones, risks, approvals or delivery dates.
4. Add the prior action register. This is needed to identify work that is still open, overdue or superseded.
5. Remove duplicate files and clearly mark drafts. Do not treat an outdated project plan as current evidence.

If you are using an xAI product with file or document features, supported inputs and behaviour can vary. Check the xAI documentation overview before making the workflow depend on a particular file format or feature.

3. Ask for extraction, not interpretation

Give the model the source pack and a fixed instruction. Ask it to return candidates first. Do not ask it to “make the register better”, because that invites unsupported assumptions.

Use a prompt in this form:

Read the supplied operational notes. Extract only actions, decisions, dependencies, blockers and escalation requests supported by the sources.

For each action candidate, return: action, owner named in the source, due date stated in the source, dependency, source reference, and confidence: high, medium or low.

For each decision, return: decision statement, decision owner or approving group, date, source reference, and whether it is reversible.

Do not infer an owner, due date, approval or completed status. Where a field is missing, write “Missing” and quote the relevant source wording. Flag conflicting statements separately.

Keep the extraction output separate from the live register. Treat it as a working list for review. It may identify a useful candidate, but it is not evidence by itself.

4. Reconcile candidates against the register

Review each candidate against the prior register and the source it cites. Work through the following sequence:

1. Match it to an existing Action ID if it is the same commitment.
2. Create a new Action ID only where the task is genuinely new.
3. Replace vague phrases with the committed result. Change “look into supplier issue” to “confirm supplier’s revised delivery date and notify procurement”.
4. Confirm the owner is accountable for delivery, not merely attending the meeting or providing input.
5. Convert relative timing into a date only if a source supplies enough context. Otherwise leave Due date as Missing.
6. Record dependencies as separate register items where they require work. Do not hide a major approval inside a notes field.
7. Move agreed outcomes to the Decisions section. An action to communicate a decision remains an action.

A useful distinction is simple: a decision answers “what will we do?” An action answers “who will do what next?” A risk describes what could go wrong. Do not merge them into one row.

5. Identify escalation items

Mark Escalation needed as Yes when the group cannot remove the blocker itself. Common examples include a spend approval, a cross-team priority conflict, a policy exception, an external vendor commitment, or a missing accountable owner.

Write the escalation as a decision request, not as a complaint. For example: “Operations director to choose whether the supplier transition remains on the current date or moves by two weeks.” Add the decision owner and the date by which the answer is needed.

Do not escalate routine status updates. If the team can resolve the issue through a normal action, assign that action and retain the blocker in the dependency field.

6. Run the quality check before handover

Use this table before publishing the register.

If you see	Treat it as wrong when	What to do
An owner is a department	Nobody is accountable	Ask the meeting chair to name one person.
A due date says “Friday”	The reporting period is unclear	Replace it with a calendar date or mark it missing.
An item is marked done	The source only says “nearly complete”	Set status to in progress and record the evidence.
Two sources conflict	They describe different dates or decisions	Keep both references and request confirmation.
A confident statement lacks a source	It cannot be traced	Remove it or label it as a question.

This is how to tell the output is wrong: it contains claims that cannot be traced, owners who did not accept accountability, dates inferred from context, or decisions presented as settled when the source shows disagreement. Check high-impact items first, especially external commitments, budget requests and overdue dependencies.

7. Publish and hand over

Send the register within the agreed follow-up window. Put the current actions first, then blockers and escalations, then decisions. Include only the fields recipients need to act on, while retaining source references in the shared record.

Ask each named owner to confirm or correct their action by a stated date. At the next meeting, begin with actions that are overdue, blocked or dependent on an unresolved decision. Close completed rows rather than deleting them, so the register remains an audit trail.

When the workflow does not work

If the model produces vague or unsupported entries, reduce the source pack to one document and test the extraction prompt against it. If notes do not name owners or dates, fix the meeting template and ask the chair to confirm missing commitments before the meeting closes. If different teams maintain competing registers, designate one register as the operational record and use the others as source material only. The register becomes reliable when unresolved fields are visible, assigned and revisited, not when every row looks complete.