5 AI Workflows Every Manager Needs

Most of a manager's week is not strategy. It is the connective tissue around strategy: turning a hallway conversation into a written update, prepping for a meeting that starts in nine minutes, restating a decision so three teams interpret it the same way, assembling a status report from six half-finished threads, and writing down what you told someone in a one-on-one so it actually changes their behavior.

None of this is hard. All of it is repetitive. And repetitive knowledge work is exactly where the hours leak out — not in one dramatic block, but in twenty-minute increments scattered across the week that never show up on a calendar. You feel it as "I was busy all day and shipped nothing."

This is not a tools problem. Buying a smarter chatbot does not fix it, the same way buying a faster keyboard does not make you a better writer. It is a systems problem. The five workflows below are not five tricks. They are one operating loop. Each takes the messy output of your week as input and returns something structured. And critically, each one feeds the next.

The stack: one loop, not five tricks

A normal management week has a natural sequence, and these workflows ride on top of it:

A meeting happens and produces notes. Those notes contain a decision that needs to be made explicit. The decision needs to be communicated to the people it affects. At the end of the week, the communications and decisions roll up into a report. And the gaps the report exposes — who is stuck, who is drifting — become the agenda for coaching in your one-on-ones.

meeting → decision → communication → report → coaching
   ↑                                              │
   └──────────── next week's agenda ──────────────┘

The point of treating these as a loop is that the output of one is already the input to the next. You stop re-typing the same information in five different shapes. You capture it once, in raw form, and let each workflow reshape it for its audience. That is the whole game.

Workflow 1 — Communication

Trigger: Any time you finish a conversation, a thread, or a thought that someone else needs to know about. This fires the most — several times a day.

The input you actually have: Half-formed notes. A Slack thread that wandered. Three bullet points you scribbled after a call. Never a clean brief.

The prompt:

You are my chief of staff. Here are my raw notes: [paste].
Draft a 5-sentence update for [stakeholder, e.g. my VP].
Lead with the decision or ask, then status, then risks.
Plain language, no adjectives. Do not invent details that
are not in my notes; if something is missing, leave a
[CONFIRM] tag instead of guessing.

Before:

talked to design — they think the onboarding redesign slips to next sprint bc the research isn't done, eng is fine either way, I think we hold the launch date and cut the second screen, need to tell marketing before they send the email

After:

Recommendation: hold the launch date, cut the second onboarding screen. Design research won't finish this sprint, but engineering can ship the trimmed flow on schedule. Risk: marketing has an announcement email queued — they need to know today so messaging matches the reduced scope. I'll confirm the email timing with [CONFIRM: marketing owner]. No change needed from your side unless you want to keep the second screen and move the date.

Failure mode: The model fills gaps with confident-sounding fiction. Guardrail: The [CONFIRM] tag forces it to flag what it doesn't know instead of inventing it. Read every output for tags before you send — that one scan is the QA step.

Workflow 2 — Meeting

Trigger: The fifteen minutes before a meeting starts, and the five minutes after it ends.

The input you actually have: Before — a calendar invite and last week's notes. After — a transcript or your live scribbles.

The prompt (post-meeting):

Here is a raw meeting transcript/my notes: [paste].
Produce three sections:
1. DECISIONS — what was actually decided (not discussed).
2. ACTIONS — owner, task, due date. One line each.
3. OPEN — questions left unresolved.
Quote the source line for each decision. If ownership or a
date was never stated, write "unassigned" — do not assume.

Before:

...yeah so we should probably look at the churn numbers, Priya can you, well someone needs to pull Q2... and the pricing thing is still up in the air, let's not decide today... ok and the demo, James is on it right...

After:

DECISIONS: Pricing change deferred — not decided today ("let's not decide today"). ACTIONS: Pull Q2 churn data — unassigned, no date ("someone needs to pull Q2"). Customer demo — James, no date ("James is on it"). OPEN: Who owns the churn pull? When is the pricing decision revisited?

Failure mode: The model promotes discussion into decisions, so your notes claim things were settled that weren't. Guardrail: Forcing a quoted source line for every decision makes hallucinated agreements impossible — if there's no quote, it can't claim a decision.

Workflow 3 — Decision

Trigger: When a choice has more than one defensible answer and more than one person has to live with it. Usually once or twice a week.

The input you actually have: A tangle of opinions from Slack, a meeting, and your own gut — none of it organized into options.

The prompt:

Turn the following into a one-page decision brief: [paste].
Structure:
- DECISION: the single question being answered, in one line.
- OPTIONS: 2-3 named options, each with the main tradeoff.
- RECOMMENDATION: one option, and the single most important
  reason.
- RISKS: what breaks if we're wrong.
- REVERSIBILITY: is this a one-way or two-way door?
Use only the information provided. Mark assumptions as
[ASSUMPTION].

Before:

do we build the integration ourselves or use the vendor — building gives us control but eng is slammed, vendor is faster but it's $40k/yr and we'd be locked in, sales keeps asking for it

After:

DECISION: Build the integration in-house or license the vendor? OPTIONS: (A) Build — full control, but [ASSUMPTION] engineering capacity won't free up for ~2 sprints. (B) Vendor — live in weeks, costs $40k/yr and creates lock-in. RECOMMENDATION: Vendor. Sales demand is immediate and the in-house timeline is unfunded. RISKS: Lock-in raises switching cost later; the $40k recurs. REVERSIBILITY: Two-way door — we can rebuild and migrate off the vendor in a future quarter.

Failure mode: The brief reads decisively while burying the assumptions the recommendation rests on. Guardrail: The [ASSUMPTION] tags surface exactly what you're betting on. If a tagged assumption is wrong, the recommendation is wrong — check those first.

Workflow 4 — Reporting

Trigger: End of week, or whenever a status roll-up is due upward.

The input you actually have: A spreadsheet row, the week's decision briefs, and a fistful of Slack updates from your team. Disconnected.

The prompt:

You are writing a weekly status report for [audience, e.g.
my director]. Inputs: [paste metrics, decisions, and team
updates]. Write it in this order:
1. Headline: one sentence — are we on track, and the why.
2. Shipped: what's done.
3. Slipping: what's behind, and the cause.
4. Need from you: explicit asks, or "nothing this week."
Maximum 200 words. No adjectives, no hedging. Numbers as
given — do not estimate or round beyond what I provided.

Before:

signups up to 1,240 (was 1,090), onboarding redesign slipped to next sprint (research), James shipped the demo, still blocked on the legal review for the data contract

After:

On track overall, with one external blocker. Signups grew to 1,240 from 1,090. The customer demo shipped. The onboarding redesign slipped one sprint pending design research. Need from you: the data-contract legal review has been pending two weeks and now blocks the partner launch — a nudge to legal this week would unblock it. Otherwise nothing.

Failure mode: AI inflates numbers, softens bad news, and adds confidence the data doesn't support. Guardrail: "Numbers as given, no estimating" plus a hard word limit. Then verify every figure against the source before it goes up — a wrong number in an exec report costs you trust you can't easily rebuild.

Workflow 5 — Coaching

Trigger: Right after a one-on-one, while it's fresh.

The input you actually have: Your impressions of the conversation and a vague sense of what should change.

The prompt:

Based on these one-on-one notes: [paste], draft a short
follow-up I can send to [name].
Include:
- One specific thing they did well, with the example.
- One area to develop, framed as a next step not a critique.
- One concrete action with a check-in date.
Direct and supportive. Second person. No generic praise —
every point must reference something in my notes.

Before:

good 1:1 with Sam, he's doing well on the migration but keeps waiting for me to unblock things instead of escalating directly, wants to grow into a lead

After:

Sam — strong work driving the migration; the way you sequenced the rollout to avoid downtime was exactly right. One step toward the lead role you mentioned: when you hit a blocker like the API access last week, escalate to the owning team directly rather than routing through me — that's the muscle a lead uses daily. Let's pick one blocker this week for you to resolve without me, and review how it went next Friday.

Failure mode: Generic, interchangeable feedback that could apply to anyone — which signals you weren't paying attention. Guardrail: "Every point must reference something in my notes." If a sentence could be sent to any direct report, cut it.

Sequencing: adopt by frequency, not by interest

Do not start with the workflow that sounds most impressive. Start with the one that fires most often, because that's where the time actually drains.

That means Communication first — it triggers several times a day and compounds fastest. Then Meeting, which you do daily and which generates the raw material everything else consumes. Then Decision and Reporting, which are weekly. Coaching comes last: it's the highest-leverage workflow over months, but it fires least often, so it's the wrong place to build the habit.

Adopt one. Use it until it's automatic. Add the next. Stacking all five in week one guarantees you abandon all five by week three.

The 3-times rule and what to measure

A workflow you run once is a novelty. A workflow you run three times becomes infrastructure — by the third pass you've tuned the prompt to your context, your stakeholders, and your standards, and it stops feeling like a detour.

So the commitment is small: pick one workflow, run it three times this week, and write down two numbers each time. Without measurement you're guessing, and a workflow that feels fast but produces output you rewrite from scratch is costing you, not saving you.

Two columns carry the verdict. Minutes saved tells you whether the workflow earns its place. Rewrites needed tells you whether you can trust the output without re-checking it — and a workflow you have to rewrite twice isn't saving time, it's relocating it. When rewrites stay low and minutes drop, you keep it. When rewrites climb, the fix is almost always the prompt, not the model: tighten the guardrail, add a [CONFIRM] or [ASSUMPTION] tag, and run it three more times.

Build the loop once. Then let it run every week.