Prompting Guide
How to Prompt Copilot to Write a Weekly Status Update
The update isn't the hard part. Deciding what's worth saying is.
Microsoft 365 Copilot can turn a messy pile of notes, tickets, and half-finished thoughts into a status update that reads like you sat down and thought it through. It can't do that from a one-line request, though, and a one-line request is what most people type: "write my status update" and then paste in whatever they have lying around. The gap between a vague prompt and a useful one is almost always the same four things, and once you see the pattern, a weekly status update takes about as long to prompt for as it takes to drink a cup of coffee.
Microsoft 365 Copilot writes a better weekly status update when you give it four things in one prompt: the context (what the project is and who's reading this), the task (write a status update, not a summary or a list), the format (sections like Done, In Progress, Blockers, Next, and a rough length), and what to check before you send it. Paste your raw notes, tickets, or messages underneath, and ask it to draft from those instead of inventing specifics.
Published
Try it with your own status updatePaste your notes in and get a structured draft back in seconds, free, no account needed.Try it freeKey Takeaways
- A status update prompt needs four parts: context (who reads this and why), task (status update, specifically), format (the sections and rough length you want), and checking (what you'll verify before sending).
- Paste your actual notes, ticket titles, or Teams messages into the prompt. Copilot should organize what you did, not guess at what you might have done.
- Name the reader. "For my manager" and "for the whole team" produce different updates, and Copilot can't tell which one you want unless you say.
- Ask Copilot to flag anything it had to guess or infer, so a filled-in placeholder doesn't quietly become a false claim in the version you send.
- If part of your week lives in a long email thread, pull a summary of that thread first, then feed the summary into the status update prompt instead of the raw back-and-forth.
Copy and Paste
Prompts You Can Use Today
A full weekly status update from raw notes
I need a weekly status update for my manager, covering the backend migration project. Here are my raw notes from the week: [paste your notes, tickets, or messages here]. Write it in four sections: Done, In Progress, Blockers, and Next Week. Keep each section short, just a few bullet points, written in plain language, not jargon. If anything in my notes is ambiguous or you have to guess at a detail, mark it clearly instead of stating it as fact.
Replace the bracketed notes with whatever you actually have: a bullet list, copied ticket titles, or a few lines you jotted during the week.
A short version for a busy executive
Turn this status update into a short, few-sentence version for an executive who has no time to spare and only cares about risk and timeline: [paste your longer update or notes here]. Lead with whether the project is on track, behind, or ahead. Mention a blocker only if it could change the delivery date. Cut everything else.
Use this after you already have a fuller update, when the same week's news needs a shorter version for a different reader.
Turning a rough brain dump into Done / In Progress / Blockers
Here's an unsorted list of everything that happened this week on my project, in no particular order: [paste the list]. Sort it into Done, In Progress, and Blockers. If something could belong in more than one section, put it in the one that matters more to someone deciding whether to help me. Do not add anything I didn't mention.
Good for the week where you didn't track anything neatly and just have a jumble of half-sentences to work from.
Pulling source material from a long email thread first
Summarize this email thread, then use that summary as raw material for a weekly status update: what was decided, what's still open, and who's waiting on what: [paste the thread, or run a thread summary first and paste that in].
Useful when a chunk of your week happened inside one long thread instead of your own notes.
Checking a draft before you send it
Read this status update draft and tell me: is there anything here that sounds more finished or more certain than it actually is, based on these raw notes: [paste your original notes]. Also tell me if there's a decision buried in here that a reader might miss because it's phrased as a status line instead of a question.
Run this on Copilot's own draft, or on one you wrote yourself, before it goes to your manager.
The Structure
The four parts of a prompt that actually produces a usable update
Every prompt that works, for a status update or almost anything else, is really these four things stacked on top of each other.
Context: what the project is and who's reading
Copilot cannot read your calendar or your org chart. Say what the project is, and say who the update is for: your manager, your team, or someone three levels removed who only cares about risk. The same week of work reads differently depending on who's asking.
Task: a status update, not a summary of everything
"Summarize my week" and "write my status update" sound similar but aren't. A status update has an audience and a purpose: it tells a reader whether to worry, whether to help, or whether to move on. Say the words "status update" and point Copilot at that specific shape.
Format: sections, length, and tone
Name the sections you want (Done, In Progress, Blockers, Next are a common default) and roughly how long each one should run. Without this, Copilot has to guess your team's convention, and it will guess wrong at least as often as it guesses right.
Checking: what you'll verify before it goes out
Tell Copilot to flag anything it had to infer or guess, rather than quietly fill a gap with something that sounds plausible. Then actually read the draft against your real week before you send it, especially any line about a blocker, a date, or a commitment.
Before And After
What changes when you add the four parts
Here's the prompt most people start with: "Write my weekly status update." Nothing else. Copilot has no project, no audience, no notes, and no sense of what matters this week, so it writes something generic enough to apply to almost any project at almost any company. It reads fine. It says nothing.
Here's the same request with the four parts filled in: "I need a weekly status update for my manager, covering the backend migration project. Here are my raw notes from the week: [notes]. Write it in four sections: Done, In Progress, Blockers, and Next Week. Keep each section short, just a few bullet points. If anything in my notes is ambiguous, flag it instead of guessing." Same task, same short burst of typing, a completely different outcome, because Copilot now has a project, a reader, real material to work from, a shape to fill, and an instruction not to paper over the gaps.
The difference isn't that the second prompt is clever. It's that it answers the four questions Copilot would otherwise have to guess at: what is this, who's it for, what should it look like, and what should I be careful about. Once you've written that pattern once, reusing it for next week's update is mostly copy, paste, and swap in new notes.
Common Mistakes
What makes Copilot guess instead of report
These are the gaps that produce a status update that sounds confident and is quietly wrong.
Pasting nothing and expecting Copilot to know your week
Copilot has no access to your ticket system or project tracker unless you paste it in. A prompt with no raw material produces a status update made of plausible-sounding filler, not an account of what actually happened.
Not naming the reader
A status update for your manager and one for the whole team carry different detail and different tone. Leave the reader unnamed and Copilot has to split the difference, which usually means it's slightly wrong for both.
Never asking it to flag uncertainty
Left alone, a draft tends to smooth over gaps instead of marking them, because smooth prose reads better than a list of caveats. Ask it to flag what it had to guess, and you get a draft that tells you where to double check instead of one that hides it.
Sending the first draft unread
A status update is often the only signal your manager gets about a project that week. A line that quietly overstates progress, or buries a blocker in a bullet list instead of leading with it, is exactly the kind of mistake that a quick read catches and a skipped read doesn't.
Sourced From Microsoft
Pulling source material from an email thread first
A chunk of most weeks lives inside a long email thread rather than a tidy list of notes, and reading the whole thread again just to write a status update wastes time you don't have. In Outlook, select Summary by Copilot (or it might say Summarize) at the top of the email thread, and Copilot produces a summary at the top of the email, often with numbered citations that take you to the specific message a point was drawn from.
That summary becomes your raw material: paste it into the status update prompt the same way you'd paste a bullet list of notes. If the thread had attachments, like a PDF or a document, those get summarized separately with Summarize a file in new Outlook, which is worth running too if a decision in the thread hinges on something inside the attachment rather than the email text around it.
On Outlook for iOS and Android, the same thread summary lives behind the Copilot icon in the toolbar rather than a text label, which matters if you're trying to pull a summary together on your phone between meetings instead of at a desk.
Before You Send It
What to check before a status update goes out
Read the Blockers section first, against your own memory of the week, not against the draft's phrasing. A blocker that Copilot wrote cautiously can still read as resolved to a reader skimming quickly; if it's still open, say so plainly rather than trusting the draft's hedging to carry the weight.
Check any sentence with a date, a number, or a commitment in it specifically. These are the details most likely to have come from an inference rather than your actual notes, and they're also the details a reader is most likely to act on directly, so an error here costs more than an error in a general description of progress.
If you pulled a status update from an email thread summary, click through any citation tied to a decision or a figure before you trust it in your own update. A citation takes you straight back to the original message, which is the fastest way to confirm a point before you repeat it under your own name.
When This Isn't The Right Tool
When to write the update yourself instead
A status update that's really a difficult conversation in disguise, like telling a stakeholder a deadline has slipped for reasons that reflect badly on a decision someone made, is worth writing yourself first. The judgment about tone, what to lead with, and what to leave for a conversation instead of an email is not something a prompt should carry, even a well-written one.
If your week genuinely had almost nothing in it worth reporting, that's useful information for your manager too, and a prompt that pads a quiet week into four full sections can end up misleading a reader into thinking more happened than did. Sometimes the honest status update is three lines long, and no amount of prompting should talk Copilot into stretching it.
Writing one good status update prompt is the easy part
The harder skill is knowing which details to pull out, which to leave out, and how to phrase a blocker so it gets read as urgent instead of routine. Nightschool AI's Copilot first week at work course walks through real inbox, document, and meeting scenarios in Outlook, Word, Excel, and Teams.
Frequently Asked Questions
What should I paste into the prompt when I ask Copilot to write a status update?
Paste whatever raw material you actually have: ticket titles, Teams messages, meeting notes, or a rough bullet list from memory. The more real material Copilot has to organize, the less it has to infer, and the more accurate the draft will be.
How do I stop Copilot from making my status update sound more finished than it is?
Ask it directly to flag anything it had to guess or infer rather than stating it as settled fact. Then read those flagged lines first before you send the draft, since they're the most likely place for a quiet overstatement to hide.
Can I use an email thread as source material for a status update?
Yes. Select Summary by Copilot (or Summarize) at the top of the thread in Outlook, then paste that summary into your status update prompt instead of the raw back-and-forth. Click through any citation tied to a decision before you repeat it.
Should I tell Copilot who the status update is for?
Yes. An update for your direct manager and one for a skip-level executive need different detail and different emphasis, and Copilot has no way to know which one you want unless the prompt says so explicitly.
What sections should a weekly status update have?
Done, In Progress, Blockers, and Next Week is a common default that covers most projects. Name your preferred sections in the prompt rather than relying on a default, since teams vary in what they expect.
Can Copilot write a status update without any notes from me?
It can produce something that reads like a status update, but without your real notes it has to fill the content with plausible-sounding generalities instead of an account of what actually happened. Paste in real material for a result worth sending.
What's the difference between asking for a summary and asking for a status update?
A summary just condenses what happened. A status update is written for a specific reader to make a specific decision, like whether to help, worry, or move on. Using the words "status update" and naming the reader points Copilot at that purpose instead of a generic recap.
Should I edit the status update Copilot writes, or send it as is?
Read it against your own memory of the week before sending, especially any line involving a date, a number, or a blocker. A first draft is a strong starting point, not a finished message, the same way a colleague's first pass at a document would be.
A clear status update takes barely any time with the right prompt
The prompt is reusable. The judgment about what to say is the part worth practicing.