What we’re building
A weekly operating review (WBR) that lands on the COO’s desk Tuesday morning, drafted from the messy updates the department leads sent on Monday. The draft is the COO’s editing surface, not the COO’s whole job. It compresses three hours of synthesis into fifteen minutes of editing, and it produces a single page in a fixed shape that the leadership group already reads.
The fixed shape is the point. The same questions, asked every week, of the same teams, formatted the same way. The shape is what makes a year of WBRs comparable. Without it, every week is its own essay and the company has no operating memory.
Who this is for
Companies between 20 and 100 people with at least three departments that send weekly updates, where the COO or chief of staff is currently spending several hours synthesizing them. Useful at smaller scale too if the founder is the synthesizer; at that size the time saved is the founder’s, which is the highest-cost time in the building.
What you need before starting
A paid Claude Cowork account. A folder. A template.md that names the questions the WBR answers, in the shape your leadership group already reads. A running-context.md that names the people, products, projects, and metrics so the workflow doesn’t have to relearn them every week. The cooperation of three department leads who’ll send updates in their native shape (Slack thread is fine, Google Doc is fine, email with a spreadsheet attached is fine; uniformity at the input is not the goal).
The workflow map
A folder called WBR/. Inside it, weekly subfolders (week-2026-W18/). Inside each: a current-week/ folder where the three updates land, a draft.md the workflow writes Tuesday morning, and a final.md the COO writes after editing. At the top of WBR/, a template.md, a running-context.md, a previous-weeks/ archive (which is just the past final.md files renamed by date), and a numbers/ folder where the regularly-tracked metrics live as a small CSV the workflow can read.
Flow: Monday evening, the leads drop their updates into current-week/. Tuesday at 6am, Cowork runs. It reads the updates, the running context, the template, and the past four weeks of finals. It writes draft.md. The COO opens it at 8am, edits, saves to final.md, and ships.
Claude Cowork setup
Connect Cowork to the folder. Write the template, write the running context, set up the schedule. Run the first week manually with last week’s data so you can calibrate before the leads start sending fresh updates.
Prompt block 1: the template
template.md. Don’t think of this as a doc layout. Think of it as a question list.
# WBR: week {WNN}, {date range}
## The one number that moved most
A single sentence naming the metric that moved most this week, by how
much, against what target, and why we believe it moved.
## What changed since last week
A short paragraph per department, only where something changed enough
to matter.
## Decisions made
A bulleted list of decisions taken this week, with the owner of each
and the date.
## Decisions needed
A bulleted list of decisions the leadership group needs to make this
week, with the question, the owner, and the deadline.
## Asks
What each department needs from leadership, in plain language.
## Risks named this week
What anyone flagged this week as a risk, with the owner.
## Numbers (always)
| Metric | This week | Last week | 4-week trend | Target |
|---|---|---|---|---|
| ... | ... | ... | ... | ... |
## Missing this week
Any update we expected and did not receive.
## Inferences
Anything in this draft that is the workflow's inference rather than a
direct read from the inputs. (The workflow always populates this
section; if there are no inferences, the section reads 'none'.)
Prompt block 2: the running context
running-context.md. Lives forever, gets edited as the company changes. The workflow reads it every run.
People (department leads):
- Sales: Maya
- Operations: Yusuf
- Finance: Lina
- Product: Karim
- Support: Sara
Products:
- {Product A}: launched Q1, primary revenue line
- {Product B}: in beta with three accounts
Projects (active):
- 'Atlas': pricing rework, owner Lina, deadline end of month
- 'Maple': support tier redesign, owner Sara, deadline mid-quarter
Metrics we always track:
- New MRR, churned MRR, net MRR
- Tickets opened, tickets resolved, time-to-first-response
- Pipeline coverage versus quarter
Vocabulary:
- 'pipe' = pipeline
- 'a tier-2 ticket' = a support ticket that escalated past first
response
Things to ignore in updates:
- Praise sections (Maya tends to write a paragraph thanking the team;
do not include in the draft)
- Vendor name-drops (Yusuf likes naming the tools he used; do not
include unless the tool is the news)
Prompt block 3: the run instruction
Build this week's WBR draft.
Read everything in current-week/. Read template.md. Read
running-context.md. Read the four most recent files in previous-weeks/.
Read numbers/.
Write the draft at draft.md following template.md exactly. Fill the
numbers table from numbers/ for the standard metrics. For any
non-standard metric mentioned in this week's updates, add a row and
mark it (new this week).
For the 'one number that moved most', pick from the numbers table.
Pick by absolute movement against target, not by absolute size of the
metric.
For 'inferences', list anything in the draft that is your reading of
the inputs rather than a direct quote or number. Be honest about
what's inference; do not bury it.
For 'missing this week', name any expected input that did not arrive.
Expected inputs are: one update from each named department lead in
running-context.md.
Do not edit final.md. Do not send anything anywhere. Stop and present
draft.md for review.
Example output (excerpt, redacted)
# WBR: week 18, April 28 to May 4
## The one number that moved most
Net MRR is at AED 412k, against a target of AED 430k for end of week.
The shortfall is AED 18k, driven by two churn events in week 17
that landed on this week's number. (Source: Lina's update,
numbers/mrr.csv.)
## What changed since last week
Sales: pipeline coverage moved from 2.4x to 2.7x for the quarter,
mostly from one new logo entering late-stage. (Source: Maya's update.)
Operations: the second warehouse partner agreement is signed; setup
starts Monday. (Source: Yusuf's update, line 3.)
Finance: 'Atlas' pricing rework went out for legal review.
(Source: Lina's update.)
Product: no significant change reported.
Support: time-to-first-response slipped from 27 minutes to 41
minutes; Sara flags this as a tier-2 ticket spike that has not
fully resolved. (Source: Sara's update.)
## Decisions needed
- Approve revised pricing for 'Atlas' before legal review closes
Friday. Owner: Lina. Deadline: Thursday EOD.
- Sign off on the second warehouse partner SLA. Owner: Yusuf.
Deadline: Monday.
## Missing this week
None. All five departments reported.
## Inferences
- The MRR shortfall attribution to two specific churn events in
week 17 is from Lina's update, but the framing as 'shortfall'
is the workflow's, not Lina's.
- The reading of Sara's tier-2 spike as 'has not fully resolved'
is inferred from her update saying response time is still high
on Monday morning.
Human review point
The COO, Tuesday morning, before 9am. They open the draft, edit anything that’s wrong or weak (the inferences section is the easiest place to catch overreach), tighten the language, and ship the final.
The other review point is the template itself. Quarterly, the COO and the leadership group sit with the past 12 finals and ask whether the questions are still the right questions. If a question stopped getting useful answers, change it. The template is a living document. The workflow follows the template; the template follows the company.
What not to automate yet
Shipping the final stays with the COO; the act of shipping is part of the COO’s job, and outsourcing it removes the moment where they own the page. Chasing a missing update stays with a person; if Yusuf didn’t send his update Monday, the WBR draft says ‘missing this week’ and the COO asks Yusuf, rather than the workflow asking Yusuf in your name on Tuesday at 6am. Comparing departments stays with a meeting; the page presents the numbers and the meeting interprets them, and a workflow that scores or ranks is a workflow that picks fights it doesn’t understand. And forecasting next week’s number stays out of the draft entirely; a drafted forecast in a WBR is a forecast nobody made and everyone reads, which is the worst possible kind.
Where one-off summaries fail and operating memory becomes necessary
The first WBR feels like a win. So does the fifth. Around the tenth, you start noticing what the workflow doesn’t have.
There’s no opinion about a missing input. Yusuf didn’t send an update for two weeks running and the draft kept going, with missing this week populated correctly each time. The COO read both drafts and didn’t quite register the pattern, because the drafts looked normal otherwise.
There’s no memory of what ‘normal’ looks like for any of the numbers it carries. A 41-minute time-to-first-response is high if the four-week average is 25, normal if the average is 38. The workflow can compute either, but it doesn’t know which way to read it without you telling it, and the telling is the part you keep meaning to do and not doing.
And there’s no memory of decisions made. Every Tuesday it lists ‘decisions made’; every Monday it forgets what they were. Six months in, you find a decision in week 12’s WBR that was reversed in week 19’s, and nobody noticed at the time because the workflow doesn’t compare across weeks unless you ask it to.
The fix to all three isn’t a smarter prompt. The fix is a system that holds memory across weeks, normalizes against history, and surfaces patterns. That isn’t a workflow anymore. It’s the next thing.
The operator lesson
A first draft from the right inputs is what makes the workflow useful. The template is more important than the model.
[VISUAL NOTE] – Suggested visual: a small two-panel image. Left panel: the three input documents in their native shape (Slack thread screenshot redacted, Google Doc thumbnail, email with attachment). Right panel: the one-page WBR draft. – Why it helps: shows the compression visually. Three messy things become one structured thing. – Could be generated with Nano Banana Pro: no for the inputs (they need real shape). Possibly for the right panel if you want a clean render rather than a screenshot, but a real screenshot is better. – Avoid: any chart that isn’t in the actual WBR, stylized ‘dashboard’ imagery, anything that suggests a BI tool. This is a Markdown page, not a dashboard.