What was decided and who owes what, on the record the team already works from, confirmed by the people who were there.
Problem
Decisions and actions are agreed in a meeting and then live in someone's notes. They reach the system of record late, partially or not at all, so the next meeting begins by reconstructing the last one.
The cost is dropped commitments and decisions that are reopened because nobody can show they were made.
Typical applications: meeting notes synced to work items.
Shape
The steps below are platform-neutral. A platform page shows which vendor capability carries each one.
- Agree which meetings are recorded, and tell participants.
- Capture the meeting and produce a summary, the decisions and the action items.
- Have the meeting owner confirm or edit them.
- Write confirmed actions to the system of record with an owner and a due date.
- Link each decision to the record it affects.
- Follow up on actions that pass their date.
Control set
The control set is part of the design, not a follow-up. Each control is agreed with the process owner before the build starts.
| Control | How it is met |
|---|---|
| Review | The meeting owner confirms the summary and the actions before anything is written to the record. Unconfirmed output is not treated as the record. |
| Data | Recording needs the participants' knowledge and, where the law or the client requires it, their consent. Meetings that are out of scope are named before the build, and retention of recordings and transcripts is set by policy. |
| Monitoring | Meetings captured, actions created, actions confirmed and actions closed on time are tracked. |
| Off switch | Capture can be disabled for a meeting, a team or the whole account. Existing records are unaffected. |
| Correction | A wrong action or decision is edited on the record, with the edit visible. Repeated errors change which meetings are in scope. |
Measures
Reference design. This pattern has not yet produced measured results in a C9D Consulting engagement. The targets below are examples of the shape, not results and not promises. Real targets come from the baseline measured in the diagnostic.
| Baseline | Metric | Example target |
|---|---|---|
| Actions that never reach the record | Share of meeting actions on the record with an owner and date | All of them, for meetings in scope |
| Time from meeting to recorded actions | Hours from meeting end to confirmed actions | Same working day |
| Decisions reopened for lack of a record | Reopened decisions per quarter | Falling |
Handoff
At the end, the client team owns:
- The list of meetings in scope and the consent and retention policy
- The playbook for confirming and recording actions
- A runbook for disabling capture and correcting the record
- Champions among the people who chair the meetings in scope
Where it applies
| Platform | Application |
|---|---|
| monday.com | AI Enablement on monday.com |
A platform that is not listed has no published application yet. The pattern itself does not depend on any one vendor.
Engagement
This pattern is not sold on its own. It is delivered through the engagement shapes in the Engagement Specification.
- E-01 Decision Advisory. Settles whether this pattern is the right first move, on which process and on which platform. It starts with a diagnostic and ends with the playbook handoff.
- D-01 Delivery Engagement. Where the client wants the workflow built, the build ends with working software and its playbook.
Read the Engagement Specification, or request a conversation.