CaretA weekly team update template that shows what slipped
On 1 October, around 9 PM, I asked about that morning's LinkedIn post. It hadn't gone out. The post was approved, but the 09:15 run that was meant to publish it fell into a gap in the scheduler. Nothing failed loudly. The post just didn't happen, and nothing we read that day said so.
That's the trouble with most weekly updates. They're written from memory, by the people who did the work, so they list the work. The things that matter most on a small team are the ones nobody did: the task that slipped a third week, the job that didn't run, the decision that's been waiting on you since Tuesday.
The template
Copy this. The order matters: good news first so people keep reading, then the parts that need action.
| Section | What goes in | The rule | Example line |
|---|---|---|---|
| The week in one line | One sentence anyone could repeat | No adjectives | "Billing page shipped; the onboarding email slipped to Tuesday." |
| Shipped | Finished work, with a link | Link to the PR, doc or post, or it didn't ship | "Billing page live: PR link, Priya" |
| Slipped | Not done, new date, why | One owner per line, never "the team" | "Onboarding email, Sam, now Tue 27th: waiting on copy" |
| Carried over | Anything slipped two weeks or more | Show the count | "Pricing FAQ, 3rd week" |
| Didn't run | Scheduled jobs, posts, reports that should have happened and didn't | Say what was missed, not why it's fine | "Monday metrics report didn't run" |
| Decisions needed | Questions waiting on someone | Each has a default and the date it starts | "Raise the trial to 30 days? Default: no change from Wed" |
| Next week | Top three, with owners | Three, not ten | "Ship onboarding email (Sam)" |
Why each section earns its place
If you only add one section, add "didn't run." Scheduled work fails quietly. Our own bots once hit their weekly model limit and missed six jobs without a word, because a bot needs the model to tell you the model is out. A list of what should have happened this week, checked against what did, catches that.
A carried-over line with a count is the cheapest honesty there is. "Bing indexing, 3rd week" reads differently from "Bing indexing: in progress." We learned that from our own SEO check. The same Bing to-do sat at the bottom of three weekly reports in a row.
Decisions with a default changed how fast we move. I'm slow to answer asks. When one bot sent me a single list of every open decision, each with a default and a date the default would start, things finally moved: I didn't reply by the Monday, so the bot started the defaults itself.
Rules for writing it
- One owner per line, a person or a named bot. If nobody owns it, that's the first slip to report.
- Link the evidence. A shipped item without a link gets a question, not a cheer.
- Under 300 words. If it's longer, the shipped list is too detailed.
- Same sections every week, even when one is empty. Write "Didn't run: nothing" so readers know it was checked.
- Dates are dates. "Tue 27th," never "early next week."
- Send it at the same time every Friday, in the channel everyone already reads.
An example: one Friday, start to finish
This is an example with a made-up six-person team, to show the steps.
At 16:00 on Friday the chief of staff bot runs its weekly job: "Read this week's threads and the plan file. Write the Friday update in our template. Ask the engineer bot for the status of open pull requests."
Its draft came back like this:
- Week in one line: "Billing page shipped; onboarding email slipped."
- Shipped: Billing page (PR link, Priya). Pricing FAQ updated (doc link, Sam).
- Slipped: Onboarding email, Sam, now Tue 27th, waiting on copy. Customer interview notes, owner unclear.
- Carried over: Data export bug, 2nd week, Arun.
- Didn't run: Monday metrics report (the connected analytics app's login had expired).
- Decisions needed: Trial length, 14 or 30 days? Default: stay at 14 from Wed.
- Next week: Onboarding email (Sam), export bug (Arun), interviews (unassigned).
The founder made three changes. She gave the interview notes to herself, because "owner unclear" was true and embarrassing. She moved the export bug to the top of next week. And she cut a sentence the bot had added explaining why the metrics report failed, keeping only the fact that it did.
The bot asked before posting to the team channel. She approved it, and it went out at 16:20.
Draft Friday update. Shipped: billing page (Priya), pricing FAQ (Sam). Slipped: onboarding email, Sam, now Tue 27th; interview notes, owner unclear. Carried over: export bug, 2nd week, Arun. Didn't run: Monday metrics report. Decision: trial length, default stay at 14 from Wed.
interviews are mine, move export bug up
v2: interview notes now yours, export bug (Arun) first in next week, and I cut the line on why the metrics report failed.
Post update to #team
ApproveDenyApproved.
An example thread, shortened.
How to set it up in Caret
Our own chief of staff bot keeps our plans, owners and dates.
- Sign up at app.caretbot.com. The bot works on its own computer in Caret Cloud, so Friday's run happens even if you're on a plane.
- Create a bot and make it your chief of staff. Write its job: it keeps the plan, chases owners when dates pass, and writes the Friday update in the template above.
- Paste the template into its job, with "one named owner per line, never 'the team'."
- Connect Slack and the apps your team uses through connected apps. Threads are bridged to Slack both ways, so the update lands where people already read.
- Add a schedule: "Friday 16:00, write the weekly update." Memory lasts between conversations, so it can count how many weeks an item has carried over.
- Ask it things in the thread during the week:
- "Add 'rewrite onboarding email' to next week, owner Sam, due Tue 27th."
- "Ask the engineer bot which pull requests are still open and add them to the update."
- "Send me every open decision as one list, each with a default and a start date."
- Approve the post when it asks. An admin approves or denies with one click, and the audit trail shows what went out.
FAQ
What should a weekly team update include? What shipped (with links), what slipped (with an owner and a new date), what didn't run, the decisions waiting on someone, and the top three for next week. Keep it under 300 words.
How do I write a weekly status update people read? Use the same sections every week, lead with one sentence that sums up the week, and give every line one owner. Readers learn where to look.
Can AI write our weekly team update? Yes, if the format is fixed and it can read where the work happens: your threads, the plan and the pull requests. Have a person read it before it goes out. The bot will get an owner wrong now and then.
To see the bot that writes ours, read about an AI chief of staff for small teams. Put a bot on it: start your 7-day trial or download the Mac app.