Skill Hub — Productivity and Execution Control

Follow-Up Tracking Working Skill

Capture and track every commitment made in meetings and messages so nothing is forgotten, every promise has an owner and a deadline, and accountability is visible to the whole team.

What this skill is for

Meetings and messages generate invisible commitments. Someone says "I will send the API spec by Wednesday" and no one writes it down. Wednesday passes, the spec is missing, and the project slips. This skill captures every commitment at the moment it is made, assigns an owner and a deadline, and tracks it until completion. The output is a Follow-Up Tracker: a living document that lists every open commitment with its source, owner, deadline, status, and any blockers. The tracker turns verbal promises into tracked obligations. It prevents the slow erosion of trust that happens when commitments are forgotten, and it gives the team a single source of truth for what is owed and by when.

When to use this skill

During or immediately after a meeting where decisions or promises were made.
When a stakeholder sends a message with an implied or explicit commitment.
When a project has multiple vendors or teams and handoffs depend on promised deliverables.
When a team member is managing multiple threads and cannot remember every promise.
When a commitment is approaching its deadline and the owner has not provided an update.
When an AI agent is monitoring a project and needs to know what has been promised and what is overdue.

Real work situations

Project kickoff: six promises, no tracker

A project kickoff meeting ends with six verbal commitments: the SAP basis team will provide system access by Tuesday, the vendor will deliver the API spec by Wednesday, the business analyst will confirm the account group mapping by Thursday, the test lead will prepare the test environment by Friday, the security team will approve the firewall rule by Monday, and the project manager will schedule the steering committee by Wednesday. No one writes them down. By Friday, three are missed. The project manager spends the next week chasing people and reconstructing what was promised. A Follow-Up Tracker would have captured all six at the meeting, assigned owners and deadlines, and sent a summary to all participants within 30 minutes of the meeting ending. Overdue items would be flagged automatically.

AMS support: recurring "I will check and get back to you"

A support analyst tells a business user: "I will check the background job log and get back to you." The business user waits. Two days later, they send a follow-up email. The analyst is on a different shift and does not remember the conversation. The business user escalates to the service manager. A Follow-Up Tracker would have captured the commitment at the moment it was made, with a deadline of 24 hours. If the analyst had not updated it, the tracker would have flagged the overdue item and the service manager could have intervened before the business user had to ask.

Integration project: cross-team handoff with no accountability

A middleware team promises to deliver a test message by Thursday so the SAP team can validate the mapping on Friday. The message is not delivered. The SAP team waits idle on Friday. On Monday, the middleware team says they were waiting for a certificate from the security team. The SAP team asks why they were not told. The middleware team says they mentioned it in a chat thread. No one can find the thread. A Follow-Up Tracker would have captured the original commitment, the dependency on the security team, and the expected delivery date. When the certificate was delayed, the tracker would have been updated, and the SAP team would have known to reallocate their Friday capacity.

Inputs required

Meeting notes, chat transcripts, or email threads where commitments were made.
Names of participants and their roles, to identify who has the authority to fulfill each commitment.
Project or task context that defines why the commitment matters and what depends on it.
Any existing tracker or task list where commitments are already recorded (to avoid duplication).
Deadline constraints from the project plan or sprint schedule.
Escalation contacts for when commitments are missed.
Historical data on which owners or teams have a pattern of missed commitments (optional).

Questions to ask

What was the exact promise? What artifact or action is expected?
Who is the single owner responsible for delivering the promise?
By what date and time must the promise be fulfilled?
What depends on this promise, and what is the consequence of a missed deadline?
Is there a dependency that the owner needs to fulfill the promise?
How will the owner communicate completion: email, ticket update, document upload, or meeting?
Who should be notified if the promise is at risk of being missed?
Has this owner made and missed similar promises before?

Working method

Capture commitments in real time. During a meeting or immediately after reading a message, write down every commitment. Do not trust memory. If a commitment is vague, ask for clarification before recording it.
Convert vague promises into specific commitments. "I will look into it" becomes "I will check the background job log and report the status by 2026-06-14 17:00." If the owner cannot be specific, record the ambiguity and flag it for clarification.
Assign one owner per commitment. If multiple people are involved, name the single person who is accountable for the outcome. If ownership is shared, split the commitment into separate items.
Set a deadline. Every commitment must have a date and, where relevant, a time. If the owner does not propose a deadline, propose one and confirm it. Deadlines are not suggestions; they are part of the commitment.
Record the source. Note the meeting name, date, message thread, or ticket where the commitment was made. This provides context and evidence if the commitment is disputed.
Record dependencies. If the owner needs something from someone else to fulfill the commitment, record that dependency and its owner. This prevents surprises.
Publish the tracker. Share the tracker with all participants within 30 minutes of the meeting or message exchange. This creates a shared record and gives the owner a chance to correct any misinterpretation.
Review the tracker daily. Check for overdue items, approaching deadlines, and items at risk. Use the daily execution review to surface follow-up status.
Follow up before the deadline. If a commitment is due tomorrow and no update has been received, send a polite reminder with the tracker entry. Do not wait until the deadline has passed.
Record completion or closure. When a commitment is fulfilled, mark it complete and record the completion date. If a commitment is no longer needed, mark it cancelled with a reason. If a commitment is missed, mark it overdue and initiate escalation.
Archive closed commitments. Move completed and cancelled items to an archive section or separate document. Keep the active tracker clean and current.

Decision rules

If a commitment has no owner, it is not a commitment. It is a wish. Record it as "unowned" and escalate for assignment.
If a commitment has no deadline, it is not a commitment. It is an intention. Propose a deadline and confirm it.
If a commitment is vague, it is not a commitment. It is a placeholder. Ask for specificity before recording it as a tracked item.
If a commitment depends on another commitment, the dependent deadline must be later than the dependency deadline plus a buffer.
If an owner misses a deadline without communication, mark the item overdue and send one reminder. If no response within 24 hours, escalate.
If a commitment is completed but the quality is insufficient, mark it complete but create a new follow-up for the correction.
If a commitment is made in a meeting with more than six people, send the tracker to all participants, not just the owner. Accountability is public.

Deliverables

Follow-Up Tracker — Living document with every open commitment, its owner, deadline, source, dependency, status, and any blockers. See template below.
Meeting Summary with Follow-Ups — One-page summary of the meeting with a tracker attached, sent to all participants within 30 minutes.
Overdue Report — Periodic list of overdue commitments with owners, ages, and escalation status.

Templates

Follow-Up Tracker (compact)

---
artifact: Follow-Up Tracker
project / team: <name>
updated: YYYY-MM-DD HH:MM
status: active
---

## Open commitments
| ID | Commitment | Owner | Deadline | Source | Dependency | Status | Notes |
|----|------------|-------|----------|--------|------------|--------|-------|
| FU-001 | <Specific action or artifact> | <name> | YYYY-MM-DD | <meeting / message> | <dependency or none> | open | <notes> |
| FU-002 | <Specific action or artifact> | <name> | YYYY-MM-DD | <meeting / message> | <dependency or none> | at risk | <notes> |
| FU-003 | <Specific action or artifact> | <name> | YYYY-MM-DD | <meeting / message> | <dependency or none> | overdue | <notes> |

## Completed this period
| ID | Commitment | Owner | Completed | Notes |
|----|------------|-------|-----------|-------|
| FU-004 | <Specific action or artifact> | <name> | YYYY-MM-DD | <notes> |

## Cancelled
| ID | Commitment | Owner | Cancelled | Reason |
|----|------------|-------|-----------|--------|
| FU-005 | <Specific action or artifact> | <name> | YYYY-MM-DD | <reason> |

Meeting Summary with Follow-Ups (compact)

---
artifact: Meeting Summary with Follow-Ups
meeting: <name>
date: YYYY-MM-DD
participants: <list>
---

## Decisions
- <Decision 1>
- <Decision 2>

## Follow-ups
| ID | Commitment | Owner | Deadline | Status |
|----|------------|-------|----------|--------|
| FU-006 | <action> | <name> | YYYY-MM-DD | open |
| FU-007 | <action> | <name> | YYYY-MM-DD | open |

## Next meeting
- Date: YYYY-MM-DD
- Purpose: <reason>

Quality checklist

Every open commitment has a specific, verifiable action or artifact.
Every open commitment has a single named owner.
Every open commitment has a deadline with a date and, where relevant, a time.
The source of every commitment is recorded (meeting, message, or ticket).
Dependencies are recorded and their deadlines are earlier than the dependent commitment.
The tracker is updated within 30 minutes of the meeting or message exchange.
Overdue items are flagged and have an escalation action.
At-risk items are flagged before the deadline, not after.
Completed items are archived with a completion date.
The tracker is shared with all relevant stakeholders, not just the owners.

Common mistakes

Trusting memory instead of writing commitments down. Consequence: commitments are forgotten within hours. The team learns that verbal promises are unreliable and stops making them, replacing trust with bureaucracy.
Recording vague promises as concrete commitments. Consequence: the tracker shows "look into API issue" with no definition of what "look into" means. The owner does something minimal and marks it complete. The requester is dissatisfied but cannot say why.
Assigning commitments to groups instead of individuals. Consequence: no one takes ownership. The commitment sits open until someone volunteers or it becomes critical.
Waiting until the deadline to follow up. Consequence: the owner has no warning and misses the deadline. The dependent work is delayed. The tracker becomes a record of failures rather than a prevention tool.
Not sharing the tracker with participants. Consequence: the owner does not know they are tracked, the requester does not know the status, and the tracker is a private fiction that does not reflect reality.

Weak output vs Strong output

Weak output

A meeting ends with a verbal agreement that "everyone will do their part." No written record. Two days later, the project manager asks for status updates in a chat. Three people respond. Two do not. One person says they did not know they were supposed to do anything. The project manager sends a new message summarizing what they remember. It is incomplete and inaccurate. The cycle repeats at the next meeting.

Why it fails: There is no single source of truth for commitments. Each person maintains their own memory, which diverges within hours. Accountability is impossible because there is no evidence of what was promised. The team spends more time reconstructing the past than executing the future.

Strong output

---
artifact: Follow-Up Tracker
project / team: S/4HANA O2C Phase 1
updated: 2026-06-12 09:30
status: active
---

## Open commitments
| ID | Commitment | Owner | Deadline | Source | Dependency | Status | Notes |
|----|------------|-------|----------|--------|------------|--------|-------|
| FU-012 | Deliver API spec v2.1 for /shipment/create | Vendor account manager | 2026-06-14 | Kickoff meeting 2026-06-09 | Security certificate approval | at risk | Certificate still pending. Vendor says they will deliver draft without it. |
| FU-013 | Confirm account group mapping for 50 customers | Business analyst Anna | 2026-06-13 | Process review 2026-06-11 | None | open | Anna confirmed she has the list. No blockers. |
| FU-014 | Provide system access for test client 300 | Basis team lead | 2026-06-12 | Kickoff meeting 2026-06-09 | None | overdue | No response to reminder sent 2026-06-11. Escalating to project manager. |
| FU-015 | Prepare test environment with test data | Test lead Sarah | 2026-06-16 | Kickoff meeting 2026-06-09 | FU-014 (system access) | open | Waiting for FU-014. If delayed, will use client 200 fallback. |
| FU-016 | Schedule steering committee for go/no-go | Project manager | 2026-06-15 | Kickoff meeting 2026-06-09 | None | open | Proposed date 2026-06-18. Awaiting confirmation from steering members. |

## Completed this period
| ID | Commitment | Owner | Completed | Notes |
|----|------------|-------|-----------|-------|
| FU-010 | Approve firewall rule for WMS interface | Security team | 2026-06-11 | Rule active. Tested from DEV. |
| FU-011 | Deliver vendor onboarding checklist | Vendor account manager | 2026-06-10 | Checklist received and reviewed. |

## Cancelled
| ID | Commitment | Owner | Cancelled | Reason |
|----|------------|-------|-----------|--------|
| — | — | — | — | — |

Agent instructions

AI Prompt Pattern

Role: Follow-up tracker for project and operational meetings.

Context: You have meeting notes, chat transcripts, or email threads containing commitments. You need to produce a Follow-Up Tracker that captures every commitment with an owner, deadline, and source.

Task: Extract commitments, convert vague promises into specific actions, assign owners, set deadlines, record dependencies, and produce a tracker in the compact format. Send a meeting summary with follow-ups to all participants.

Output format: Structured Follow-Up Tracker per the template, followed by a Meeting Summary with Follow-Ups.

Never trust memory. Capture commitments in real time from the meeting notes or transcript. If a commitment is not in the notes, ask for clarification.
Always convert vague promises into specific commitments. "I will look into it" is not trackable. "I will check the job log and report status by Thursday" is.
Every commitment must have one owner. If multiple people are involved, split the commitment or name the accountable person.
Every commitment must have a deadline. If none is given, propose one and confirm it.
Record the source of every commitment. Meeting name, date, message thread, or ticket number.
Record dependencies explicitly. If a commitment depends on another, link them in the tracker.
Send the tracker to all participants within 30 minutes. This creates a shared record and allows correction.
Flag overdue and at-risk items before the deadline. Do not wait for failure to report risk.
Do not invent commitments. Only record what was explicitly promised. If something is implied but not stated, flag it as "tentative."
Link to Atlas diagnostics when follow-ups involve SAP technical commitments. Reference the relevant diagnostic page for context.

Related skills

Daily Execution Review Working Skill — Use to review follow-up status during the daily review.
Blocker Escalation Working Skill — Use when a follow-up is overdue and the owner is not responding.
Priority Triage Working Skill — Use when new follow-ups compete with existing work for capacity.
Task Clarification Working Skill — Use when a follow-up commitment is vague and needs to be clarified before tracking.

Related Atlas pages

Operational Memory for SAP AMS — How follow-up tracking builds institutional memory.
AI-Ready Process Documentation — Context for structuring follow-up records so AI agents can consume them.

Verification status and limitations

This skill is a public working interpretation of follow-up tracking practices. It is not official ITIL, PMP, or SAP methodology. It focuses on practical tracking for enterprise teams where commitments are made in meetings and messages and are frequently forgotten without a structured record.

Known limitations: the skill assumes that commitments are made in a context that can be captured (meetings, messages, tickets). It does not cover informal hallway conversations that are not documented. It assumes the tracker is maintained by someone with authority to follow up and escalate. For very large projects with hundreds of commitments, the tracker may need to be managed in a tool rather than a document. The skill does not replace formal project management tools or contract management systems; it complements them with a lightweight tracking layer.