Meeting action register follow-through

Use this workflow after each recurring operational meeting to turn notes into named, trackable work. It gives operations coordinators one action register and one follow-up document that the team can use without rereading the meeting notes.

Set up the source pack

1. Collect the meeting materials in one place:

   • The agenda.
   • The notes or transcript.
   • Any decision log used during the meeting.
   • The previous action register.
   • Documents mentioned as evidence, such as a supplier scorecard, incident report or monthly report.

2. Create a working document called Meeting action register - [meeting name] - [date].

3. Add these columns before you start extracting work:

Field	What to record	Example
Action ID	A short stable reference	OPS-042
Action	One observable result	Confirm delivery dates with the courier
Owner	One accountable person	Priya Shah
Due date	A calendar date, or TBC	18 September
Dependency	What must happen first	Finance approval of revised spend
Escalation point	When and to whom to raise a problem	Raise to Head of Operations if no courier reply by 16 September
Status	Not started, in progress, blocked, complete or cancelled	Blocked
Source	The note section or decision that created it	Item 4, supplier performance

4. Keep decisions separate from actions. A decision records what the group agreed. An action records the work needed because of that agreement. For example, Use Supplier B for the October pilot is a decision. Priya to notify Supplier A and close the open quote is an action.

Extract decisions, actions and questions

1. Read the notes once without drafting. Mark each statement as one of these:

   • Decision: the meeting settled a choice, policy or priority.
   • Action: somebody must produce, change, check, send or arrange something.
   • Open question: the group needs information before it can decide.
   • Risk or blocker: something may prevent delivery.

2. Draft an action for each explicit commitment. Rewrite vague language into a result that can be checked. Replace Look into stock issue with Review stock discrepancy report and propose a correction plan.

3. Convert an open question into an action only if the meeting assigned someone to answer it. If no one was assigned, add it to an Unassigned questions section in the follow-up document. Do not silently choose an owner.

4. For each action, capture the exact wording or note reference in the Source field. This gives you a quick route back when an owner disputes the action later.

5. Use the previous register to identify repeated or unfinished work. Carry forward the existing Action ID instead of creating a duplicate. Update its status, deadline and escalation point after checking the latest notes.

Resolve the four fields that make actions usable

Work through every row in this order.

1. Owner: Find the person who accepted the work or whose role owns the outcome. If the notes name a team rather than a person, mark the owner as Unassigned and flag it for the meeting chair.

2. Due date: Record the date stated in the meeting. If the note says next week or before the next meeting, replace it with a date based on the meeting calendar. If there is no date, use TBC, not an invented deadline.

3. Dependency: State the external condition, input or approval. Avoid generic entries such as other teams. Write Receive approved site list from Facilities instead.

4. Escalation point: Set a practical trigger. It should contain a condition, a date or both. For example: Escalate to Operations Director if draft is not received by 12:00 on 17 September.

If you use a model to structure the notes, provide only the material needed for the register and follow your organisation's handling rules. Check the current product and data-handling information in the xAI documentation, as available features and limits are version-dependent.

Use a prompt that requires the model to preserve uncertainty:

Create an action register from these meeting notes.
For each action, return: action, owner, due date, dependency, escalation point, status and source note.
Do not infer an owner, deadline or decision. Write TBC or Unassigned where the notes do not state it.
List open questions separately. Flag contradictions between the notes and the previous action register.

Check the register before sending it

Read each row as if you are the named owner. You should be able to answer: what do I deliver, by when, what do I need first, and what happens if I cannot proceed?

Use this review table for common faults:

If you see this	Do this	Do not do this
Two names in Owner	Ask which person is accountable	Leave both names and assume they will divide the work
ASAP or next week	Replace it with a date or TBC	Convert it to a date without checking the calendar
A blocked action	Name the blocking input and escalation trigger	Mark it in progress with no explanation
A new action similar to an old one	Update the existing Action ID	Create a second row for the same work

Also check the register against the previous meeting's overdue actions. Confirm whether each is complete, still active, blocked or cancelled. A missing old action is often a reporting error, not evidence that the work ended.

Produce the team follow-up document

Create a document called Follow-up - [meeting name] - [date]. Keep it to the information people need to act.

Use this order:

1. Meeting name, date and attendees.
2. Decisions made, in short bullets.
3. Action register, sorted by due date and then status. Put blocked and overdue items first.
4. Open questions, with the person needed to answer each one where known.
5. Risks and escalation points requiring leadership attention.
6. Date, time and purpose of the next meeting.

Send the follow-up document to attendees and anyone named as an owner who was absent. Store the action register in the team location used for operational reporting, not only in the email thread.

When the workflow does not work

If the notes are incomplete, return to the recording or ask the note-taker for the missing section. If ownership is disputed, send the exact source wording and ask the meeting chair to decide. If deadlines conflict with an existing plan, record the conflict in the action's dependency field and escalate it at the stated point. Do not repair gaps by guessing. Issue a corrected follow-up document once the chair confirms the changes, and keep the same Action IDs so the reporting trail remains intact.