Part 2: The Templates (Copy, Paste, Run)
Part 1 was the install plan. Part 2 is the template pack. No PDF or carousel. All you have to do is copy and paste, then get back to your actual job.
These templates exist for one reason: to stop meetings from being the only place where work, decisions, and context live. If you use them consistently, you’ll cut update meetings, reduce “quick sync” spam, and make approvals move without pulling everyone into a call.
A few rules make this work:
Rule 1: Pick one home. Put these templates in one place (Notion, Google Docs, Confluence, Linear, Asana, etc.). If people have to hunt, they’ll schedule a meeting instead.
Rule 2: Every template has one owner. One person is responsible for posting it on time and keeping it accurate. Inputs can come from others, but ownership can't.
Rule 3: These are replacements, not add-ons. If you adopt a template, you should cancel the meeting it replaces. Otherwise you’ll end up with both.
Template 1: Status At A Glance (Project Update)
What this replaces: weekly status meetings, recurring “where are we?” syncs, standups that exist only to report progress. Why it works: the whole team gets the same update in one place, without needing real-time airtime. Who owns it: the project lead (the person responsible for progress moving).
STATUS AT A GLANCE
Project:
Date:
Owner:
Status: 🟢 On Track / 🟡 At Risk / 🔴 Blocked
What moved since last update (1–3 bullets):
What’s stuck + what I need (1–3 bullets):
Next 7 days focus (1–3 bullets):
Links (brief/doc/tickets):
Template 2: Highlights And Headwinds (Team / Initiative Update)
What this replaces: round-robins, team “updates” meetings, the weekly ritual where everyone talks and nothing gets decided. Why it works: it separates progress from risk and it forces requests to be specific (who needs to do what by when). Who owns it: the person accountable for the team or initiative’s outcomes (team lead, function lead, or initiative lead).
HIGHLIGHTS AND HEADWINDS
Team/Initiative:
Date:
Owner:
Highlights (wins, progress) (1–3 bullets):
Headwinds (risks, constraints, dependencies) (1–3 bullets):
Next focus (what we’re prioritizing now) (1–3 bullets):
Links (dashboards, docs, workboard):
Template 3: Decision Proposal (Async Decision Request)
What this replaces: “quick sync?” meetings, ad-hoc calls to get alignment, Slack threads that never land anywhere. Why it works: it forces the requester to provide complete context and a recommendation, so the decision-maker can decide without a meeting. Who owns it: the requester (the person who would normally schedule the meeting).
Important: this template isn't documenting a decision that’s already made. It’s a decision request designed to close async.
DECISION PROPOSAL
Decision needed (single sentence question):
Decision deadline (date/time):
Decision-maker (name):
Context (why now, what changed, constraints) (3–6 bullets):
Options (2–3 max):
Option A:
Pros:
Cons:
Cost/effort:
Risks:
Option B:
Pros:
Cons:
Cost / effort:
Risks:
(Option C only if truly needed)
Requester's recommendation (the proposed option + why) (2–5 bullets):
Next steps after the decision (what will happen immediately) (2–4 bullets):
The section below is what prevents a “quick sync.” It tells the decision-maker and reviewers what kind of input is needed, where to put it, and when it’s due so the decision can close without a call.
How to respond (so we can close this async):
Response types: Approve or Deny / Concerns / Edits / Questions
Respond by: [date/time]
Respond here: [single link]
Quick clarification on response types (so people don’t misuse them):
Approve or Deny means the decision-maker is making the call.
Concerns / Edits / Questions are for reviewers who don’t own the final decision, but can block it if something’s missing or risky.
Template 4: Approval Intake
What this replaces: approval calls with Legal/Finance/IT, escalation meetings, and the “can we hop on for 15 minutes” loop. Why it works: most approval meetings exist because the request shows up incomplete. This forces the requester to submit complete context so approvers can respond async. Who owns it: the requester. If it’s incomplete, it gets bounced.
APPROVAL INTAKE
Request type: Contract / Vendor / Pricing / Policy / Payment Terms / Other
Requester:
Date submitted:
Needed-by date:
Approver(s):
Stakeholders to review (names):
1) What are we approving? (2–4 sentences)
2) Why now? (what happens if we don’t approve) (2–4 bullets)
3) Scope (what this includes / does not include)
4) Financial impact (answer only what applies)
One-time cost:
Monthly/annual cost:
Budget owner:
Budget line (if known):
Expected ROI / cost avoidance (if applicable):
Payment terms requested:
5) Risk snapshot (answer only what applies)
Legal/compliance: Are there any terms, regulations, or commitments that need legal review? (Examples: indemnity, liability cap, IP, exclusivity, auto-renew, termination, subcontractors)
Security/data: Are we sharing any customer, employee, payment, or confidential data? If yes, what data and why?
Operational: What breaks if this vendor/process fails? What’s the fallback?
Reputation: Could this create public/customer backlash if it went wrong?
6) Attach any applicable documents (links)
Contract docs: Draft contract, MSA, redlines (if changes requested)
Scope docs: SOW / scope doc, pricing sheet
Security docs (if data/security involved): Security questionnaire, SOC 2 (if available), data flow summary
Finance/vendor setup (if required): W-9, insurance cert, vendor onboarding form
7) Alternatives considered (2–3 bullets)
Existing option: [Tool/process] didn’t work because [specific reason].
Alternative vendor/approach: [Name] was rejected because [price/risk/fit/timeline].
8) Decision request (what exactly do you need?)
Approve / reject / revise
If revise, what change would make this approvable?
Template 5: Decision Log (Stop Re-Deciding The Same Things)
What this replaces: “Didn’t we already decide this?” meetings, re-discussing decisions already made, and quiet reversals caused by missing context. Why it works: it creates a durable record of what was decided, who owned the call, and why. This makes decisions searchable and harder to undo without a real reason. Who owns it: the person responsible for keeping cross-functional work moving (usually Head of Ops or Chief of Staff).
Important: this isn’t documentation for its own sake. It’s a control that protects decision closure. If a team doesn’t have a decision log, decisions will get revisited under pressure.
DECISION LOG ENTRY
Decision title (short):
Date of decision:
Decision-maker:
Driver (who ran the process):
Decision (the final call):
Why we chose this (rationale) (2–4 bullets):
Trade-offs (what we’re accepting) (1–2 bullets):
Links (so nobody has to reconstruct context later):
Decision proposal / brief:
Relevant docs:
Tickets / execution plan:
Follow-ups created (only if not already captured in your tracker):
Owner:
Due date:
Tracking link:
Optional fields (use only if your org needs it):
People who must review (names):
People who need visibility (names):
Template 6: The No-Response Escalation Path (Only When Responses Stall)
What this replaces: “checking in” pings and last-minute meetings used to force a response. Why it works: it gives you a predictable way to chase a response without scheduling a call. Who owns it: the person responsible for keeping decisions moving (Head of Ops, Chief of Staff, or function lead). Where it lives: in the same place as the request (doc, ticket, thread). When to use this: you do not need it for every decision. Use it when responses are slow, approvals linger, or “quick sync” keeps coming back because nobody replies on time. This is the escalation layer you activate when the async request isn’t getting a response.
How it connects: it supports Template 3 (Decision Proposal) and Template 4 (Approval Intake). You can either (1) reference it as the default rule or (2) apply it when a request is stalling.
RESPONSE WINDOW + ESCALATION PATH (Activate When A Request Is Stalling)
Applies to: Decisions / Approvals / Reviews / Other
Stalled request link:
Timer owner (who escalates if needed):
Response window once activated (choose one):
Standard: 24–48 business hours
Complex: 3–5 business days (must be labeled “Complex”)
What counts as a response:
Decision-maker: Approve / Reject (with reason) / Approve with edits
Reviewer: Concerns / Questions (must state what’s needed to proceed)
Escalation path if the response window is missed:
At deadline: Reminder in-thread + tag approver
+24 hours: Escalate to backup approver or approver’s manager
+48 hours: Escalate to exec owner for unblock decision
Template 7: Meeting Receipt (Turn Talk Into Execution)
Use when: any meeting happens, including 1:1s. Why it works: it forces meetings to end with clear ownership and a tracked next step, which reduces follow-up meetings and decisions getting changed without notice. Who owns it: the meeting owner, not whoever got stuck taking notes.
Rule: no receipt means the meeting didn’t produce work. If a meeting repeatedly can’t produce a receipt, it should be converted to async or canceled.
For 1:1s: capture only work-related commitments. Keep sensitive notes private.
MEETING RECEIPT
Meeting:
Date:
Attendees:
Decision or commitment (what are we doing / what changed):
Owner named (one person):
Due date set (if applicable):
Tracking location linked (ticket/doc/board):
Notes (optional, 3–6 bullets max):
How To Use These Without Turning It Into More Process
If you read all 7 templates and felt a small wave of “this is a lot,” that’s normal. The point isn’t to use every template every day. The point is to replace the handful of meeting types that keep hijacking the calendar.
Start With The Core Set, Then Pull In The Others When You Need Them
Most teams only use 4 templates regularly:
Template 1 (Status At A Glance) for project updates
Template 2 (Highlights And Headwinds) for team or initiative updates
Template 3 (Decision Proposal) when a “quick sync” is requested
Template 7 (Meeting Receipt) for any meeting that remains on the calendar
The remaining templates are for the situations that usually drag teams back into never-ending meetings:
Template 4 (Approval Intake) is for approvals that would otherwise turn into a meeting
Template 5 (Decision Log) is for decisions that would otherwise get re-opened later
Template 6 (No-Response Escalation Path) is only for when async stalls and silence becomes the blocker
If you keep that model, this stays lightweight.
One Owner Means Clear Accountability
If a template is missing, stale, or unclear, there should be exactly one person to go to. That’s why every template has a single owner. It prevents the “everyone thought someone else was handling it” spiral that ends in another meeting.
Where People Usually Mess This Up
If this doesn’t work on the first attempt, it’s usually for one of three reasons:
They keep the meeting and add the template. That doubles the work and creates resentment. If the template is adopted, cancel the meeting it replaced.
They let context live in too many places. If updates are in Slack, approvals are in email, and decisions are in meetings, nothing is searchable and calls creep back. Pick one home and link everything back to it.
They don’t enforce closure. Decisions stay “in discussion,” approvals linger, and people schedule meetings to force a response. Template 6 exists for that exact moment.
The Smallest “Good Enough” Setup
If you want a bare-minimum rollout, do this:
Convert update meetings using Template 1 and Template 2
Replace “quick sync” requests with Template 3
Require Template 7 for any meeting that stays on the calendar
Add Template 4 only for Legal/Finance/IT approvals
Use Template 5 only for decisions that keep coming back
Use Template 6 only when silence becomes the blocker
That combination is enough to cut meeting volume without slowing execution.
If you implement this and still feel like you’re drowning in syncs, the issue isn’t that you need more templates. The issue is that the company is still using meetings as the operating system. These templates are how you replace that, one mechanism at a time.
Trying to roll this out and something isn’t clicking? Contact me. I’ll tell you which template to use, what to cut, or what mechanism is still missing.