Copilot & AI in Microsoft 365

Copilot can read a 50-page document in seconds and tell you what matters. Used well, it saves hours. Used badly, it gives you confident-sounding nonsense.

One of the highest-value uses of Copilot is summarisation — taking a long document (a report, a policy, a contract, a research paper) and producing a clear, structured summary. Copilot can do this in seconds, across documents far longer than anyone has time to read carefully. For knowledge workers who routinely face stacks of documents they’re expected to be ‘across’, this is genuinely transformative.

The trick is knowing what to ask for. ‘Summarise this’ produces a generic summary. ‘Summarise this in five bullet points focused on financial implications’ produces something useful. ‘What decisions does this document require from me?’ produces something even more useful. The quality of the summary is almost entirely determined by the quality of the prompt.

The thing to watch is over-reliance. Copilot summaries are excellent starting points, but they’re not a replacement for reading critical content. For policies you have to comply with, contracts you have to sign, or reports you’ll be challenged on — read the source. Use the summary to know where to focus your reading time, not as a replacement for it.

Why this matters

Summarisation is the fastest-payoff use of Copilot for most knowledge workers:

It compresses information overload. A 50-page report becomes a 5-bullet brief. You decide if the full report is worth your time.

It surfaces the structure of complex content. What are the main themes? What’s been decided? What’s still open?

It frees your reading time for what matters. Spend an hour on the document that needs deep reading, not on every document that crosses your desk.

When you’ll use this

• When you’ve been sent a long report or policy and need the highlights fast.
• When reviewing handover documents from a colleague.
• When preparing for a meeting where you’ll discuss a document you haven’t fully read.
• When deciding whether a document deserves your full reading time.

How to do it

1. Open the document in its source location (SharePoint or OneDrive — not a download).
2. Open Copilot inside Word, or use Copilot Chat with the document attached.
3. Ask for a structured summary with the focus that matters to you.
4. Refine: ask for shorter, more detailed, or focused on a specific theme.
5. Ask Copilot to flag risks, decisions needed, or open questions.
6. Verify any critical claims against the source document.
7. Save useful summaries somewhere durable if you’ll need them later.

Best practices

• Be specific in your prompt. ‘Summarise focused on financial implications’ is better than ‘Summarise this’.
• Ask for structure. Bullet points, sections, or a table beats a wall of prose.
• Always verify critical claims. Especially for legal, financial, or regulatory content.
• Save useful summaries. Otherwise you’ll generate the same one again next month.

Common mistakes

• Trusting summaries blindly for critical content. Hallucinations look exactly like accurate summaries. Verify.
• Asking ‘summarise this’ with no focus. You get generic output. Specify what you care about.
• Using summaries as a substitute for reading documents you’ll be held accountable for. Read the contract. Read the policy.

Sample Copilot prompts

• Summarise this document in five bullet points.
• Give me a one-paragraph executive summary.
• What decisions or actions are mentioned in this document?
• Highlight any risks or open questions.
• Summarise this focusing on financial implications only.

↑ Back to top ↑ Back to list

PDFs hide their structure. Copilot can pull out the specific facts you need — dates, requirements, totals — without making you read the whole thing.

PDFs are the format you receive when someone wants to send you something fixed and final — contracts, invoices, regulatory documents, formal proposals, scanned forms. They’re great for distribution but terrible for reading on a screen and worse for finding specific information. Copilot can read PDFs natively (when they’re in your SharePoint or OneDrive), and it can extract specific data points without you having to scroll through 40 pages.

The skill is in framing the request. Don’t ask ‘what’s in this PDF?’ — that produces generic summaries. Ask for the specific things you need: ‘extract all dates and what each one represents’, ‘list every requirement marked as mandatory’, ‘find the total cost and break down what it includes’. The more precise the question, the more useful the answer.

For scanned PDFs (image-based, not text-based), results vary. Copilot needs to read text from the image, which works for clean scans but struggles with poor-quality ones. If results look wrong on a scanned PDF, it might be the OCR quality rather than Copilot getting confused. The fix is usually to ask for verification or run it through a better OCR tool first.

When you’ll use this

• When you’ve been sent a long PDF (contract, policy, report, proposal) and only need specific details.
• When you need to extract structured data — dates, costs, requirements, parties.
• When you need to compare PDF content against a checklist.
• When you want a table of key fields rather than reading the whole document.

How to do it

1. Open the PDF in its source location (SharePoint/OneDrive, not a download).
2. Open Copilot Chat or Copilot in your file viewer.
3. Ask for the specific fields you need, with page references where helpful.
4. Request structured output (table, bullet list) — easier to scan than prose.
5. Refine if results are too broad or too narrow.
6. Verify critical extractions against the source — especially page numbers.
7. Copy useful output into a checklist or notes for action.

Best practices

• Be specific about what you want extracted. Fields, headings, timeframes — name them.
• Ask for page numbers or section titles. Lets you verify quickly.
• Request a table for structured results. Far easier to scan than paragraphs.
• Always verify against the source for legal or compliance content. Treat output as a draft summary.

Common mistakes

• Asking ‘tell me about this PDF’. You get a vague summary. Be specific.
• Trusting extractions on scanned PDFs without checking. OCR quality affects accuracy.
• Skipping page reference requests. Without them, verifying takes much longer.

Sample Copilot prompts

• Extract the key dates (effective date, renewal, notice period, termination) and include the page number for each.
• List the top 10 requirements from this PDF. Group them by theme (Security, Privacy, Delivery, Reporting).
• Find anything related to data retention or records management and summarise the obligations in plain English.
• Create a checklist from this PDF: Requirement | Owner | Due date.
• Pull out any risks, exclusions, or assumptions. Return as bullets with a short impact statement for each.

↑ Back to top ↑ Back to list

Comparing two versions of a document manually is slow and error-prone. Copilot can do it in seconds — and tell you what actually matters.

Comparing documents is one of those tasks that humans are terrible at and AI is fantastic at. A revised contract, a new draft of a policy, a peer-reviewed proposal — comparing them word-by-word is tedious, and missing a small change can have real consequences. Copilot can scan both documents and tell you what’s added, what’s removed, and what’s changed, in seconds.

The trick is to ask for changes that matter, not every change. A revised contract might have hundreds of formatting tweaks alongside three substantive changes — you want to find the three. Tell Copilot what you care about: ‘show me changes that affect scope, deliverables, or pricing’ or ‘ignore formatting changes — just show me wording changes that affect meaning’. This narrows the output to what actually matters.

For formal documents (contracts, regulated content, audited material), use Copilot’s comparison alongside Word’s built-in Compare/Track Changes feature as a second check. Copilot is fast and good at the ‘so what’ interpretation; Word’s Compare is exhaustive and good at catching every literal change. Together, they’re more reliable than either alone.

When you’ll use this

• When you’ve received a revised version of a document and need to know what changed.
• When you have two drafts of the same document and need to merge them.
• When auditing changes to a controlled document.
• When deciding whether to approve a revised contract or proposal.

How to do it

1. Make sure both documents are accessible in SharePoint or OneDrive.
2. Open Copilot Chat and reference both documents (by name or link).
3. Ask for a comparison focused on what matters — scope, pricing, obligations, key wording.
4. Request output grouped by Added / Removed / Modified.
5. Ask for section headings or page numbers so you can verify quickly.
6. For formal documents, also run Word’s Compare as a second check.
7. Verify critical changes in the source documents before sign-off.

Best practices

• Ask for material changes first. Anything that affects cost, scope, timing, or obligations. Ignore formatting noise.
• Request section headings for each change. So you can jump to the right place.
• For formal docs, layer Copilot with Word’s Compare. Two tools catch more than one.
• Always verify before signing or approving. Trust but verify.

Common mistakes

• Asking ‘what’s different’ with no focus. You get every formatting tweak alongside real changes.
• Trusting Copilot’s comparison without verifying. A missed change in a contract is expensive.
• Comparing wrong versions. Make sure you’re comparing the right two — easy to confuse v2 and v3.

Sample Copilot prompts

• Compare Document A and Document B. Summarise the key differences in Added / Removed / Modified sections.
• Only show changes that affect scope, deliverables, pricing, or timelines. Ignore formatting changes.
• List the top 10 most important changes and explain why each matters in one sentence.
• Create a short email I can send to stakeholders summarising what changed and what needs review.
• Find any wording changes related to risk, liability, security, or compliance and summarise them clearly.

↑ Back to top ↑ Back to list

When the answer is spread across a folder of documents, Copilot can search across all of them at once — and pull together a consolidated answer.

Some questions can’t be answered from a single document. ‘What did we agree about pricing across all these meeting notes?’ ‘What policies mention data retention?’ ‘What are all the open risks across our project documents?’ These are multi-document questions, and they’re exactly where Copilot’s ability to search and synthesise across content shines.

The key to making this work is scope. Don’t just ask Copilot a question and hope for the best — tell it which documents to look at. ‘Across the files in this Teams channel…’ or ‘Looking at the documents in [folder name]…’ or ‘In the project documents from [project name]…’. Without scope, Copilot might pull in unrelated content from across your tenant. With scope, it focuses on the right material.

For best results, your content needs to be findable. Files with clear naming, proper metadata, and stored in logical locations produce dramatically better Copilot results than chaotic libraries. This is why metadata and structure matter so much for AI readiness — Copilot is only as good as the content it’s reading.

When you’ll use this

• When the answer to your question is spread across several documents.
• When you’re getting up to speed on a project and need to synthesise everything quickly.
• When you want to find every mention of a specific topic across a content set.
• When you’re building a brief or one-pager from disparate sources.

How to do it

1. Identify the right scope — which folder, channel, project, or file set.
2. Open Copilot Chat with the right context (the relevant Teams channel or SharePoint location).
3. Ask the question and specify the scope explicitly.
4. Request a consolidated answer plus a list of source documents used.
5. Ask for direct quotes or section references for anything important.
6. Refine if results are too broad — narrow by timeframe, document type, or topic.
7. Verify critical findings against the original documents.

Best practices

• Be explicit about scope. Which folder, project, team — say it clearly.
• Ask for sources used. Verifies the answer and catches misses.
• Use consistent file naming and metadata. Copilot retrieves better-organised content more reliably.
• For accuracy-critical answers, request direct quotes. Lets you verify quickly.

Common mistakes

• No scope, vague question. Copilot pulls in random content; answers are unreliable.
• Trusting consolidated answers without checking sources. Especially for compliance or legal questions.
• Expecting good results from messy content. Copilot can’t fix what your structure can’t surface.

Sample Copilot prompts

• Across these project documents, what are the agreed next steps and who owns each one? Include the source document name.
• Find any mention of risk, issue, or blocker across these files. Summarise each item with context and source.
• What decisions were made this month across these meeting notes? Group by topic and include the meeting date.
• Create a one-page brief from these documents: Objective, Current status, Key risks, Decisions needed.
• List all references to compliance/security requirements across these documents and consolidate into one checklist.

↑ Back to top ↑ Back to list

Meeting notes are usually a mess — bullet points, half-sentences, side conversations. Copilot turns that mess into a clean summary your team can actually use.

Meeting notes are one of the most consistently disappointing types of content in any organisation. Someone takes notes (or doesn’t). The notes are messy, partial, in someone’s OneNote that nobody else can find. Decisions made in the meeting get lost. Action items don’t have owners. A week later, half the team has a different memory of what was agreed.

Copilot can fix this almost effortlessly. Give it your raw notes — even if they’re chaotic — and ask for a structured summary: decisions made, action items with owners and due dates, open questions, follow-ups. What was an unreadable mess becomes a clean post you can put in the channel or send around in email. The whole team is on the same page.

The bigger win is consistency. If every meeting in your team produces a Copilot-summarised version of the notes in the same format, you’ve built a reliable record of what was decided, week after week. Decisions become searchable. Action items become trackable. The team gets accountability without anyone having to be a heroic note-taker.

When you’ll use this

• When meeting notes are messy and you need a clean summary fast.
• When you want to capture decisions and actions consistently across recurring meetings.
• When you want to send a meeting recap to people who weren’t there.
• When you’re collating notes from a workshop or planning session.

How to do it

1. Open your raw notes (OneNote, Word, Loop, Teams meeting notes).
2. Ask Copilot to summarise into a consistent structure: Summary, Decisions, Actions, Risks, Follow-ups.
3. Ask for action items as a table with Owner and Due Date columns.
4. Request a shorter ‘sendable’ version (3-6 bullets) for busy stakeholders.
5. Scan the output for accuracy — particularly names, dates, and decisions.
6. Save the summary in a shared location (channel post, OneNote, Loop).
7. Send to attendees and follow up on actions.

Best practices

• Use a consistent template every time. The team recognises the format and knows where to look.
• Separate Decisions from Actions. ‘We agreed X’ is different from ‘Sarah will do Y by Friday’.
• Ask Copilot to flag unclear items. Better to flag missing owners than guess.
• Save in a shared, durable place. Notes lost in someone’s OneNote help nobody.

Common mistakes

• Trusting Copilot to invent owners or dates that weren’t said. If it wasn’t in the notes, the summary shouldn’t make it up.
• Sending the summary without scanning it. A wrong action assigned to a wrong person creates real problems.
• Letting summaries stay in personal storage. Defeats the team-record purpose.

Sample Copilot prompts

• Turn these meeting notes into a structured summary with: Summary, Decisions, Actions, Risks, Follow-ups.
• Extract action items as a table: Action | Owner | Due date | Notes. Leave blanks if not stated.
• Write a Teams update I can post to the channel summarising what happened in under 6 bullet points.
• Identify any open questions or unresolved issues and list what needs clarification.
• Rewrite this summary in a more confident, professional tone without changing the meaning.

↑ Back to top ↑ Back to list

Most emails are 80% routine and 20% specifics. Copilot handles the routine 80% in seconds — you add the 20% that needs your judgement.

Drafting emails is the most everyday Copilot use case for most knowledge workers. A request, a follow-up, a polite refusal, a status update — these are emails you’ve written hundreds of times. Copilot can draft them faster than you can, in the right tone, with the right structure. You add the specific details, check the result, and send.

The skill is giving Copilot enough context to produce something useful. ‘Write an email about the meeting’ produces generic mush. ‘Write a short email to my manager confirming I can attend the strategy session next Thursday at 2pm, and asking whether I should bring the Q3 numbers’ produces something almost ready to send. The more specific you are about audience, purpose, tone, and details, the less editing you’ll need to do.

Where Copilot saves the most time isn’t speed of typing — it’s overcoming the small friction of starting. Many emails sit half-written for an hour because you can’t quite work out how to phrase the awkward bit. Copilot drafts the awkward bit in two seconds. You read it, make it more ‘you’, and hit send. The friction is gone.

When you’ll use this

• When you need to send a routine email and don’t want to think about how to phrase it.
• When you’re stuck on the right opening or closing line.
• When you need to write something polite about a difficult situation.
• When you want a draft to react to, rather than starting from scratch.

How to do it

1. Open Outlook (or Copilot Chat with your Outlook context).
2. Tell Copilot the recipient, the goal, and the tone (friendly, firm, formal, brief).
3. Provide the specific details Copilot can’t know — names, dates, numbers, requirements.
4. Ask for a draft, then refine: shorter, more direct, more polite, different opening.
5. Add anything Copilot got wrong or missed.
6. Read the final version aloud — does it sound like you?
7. Send.

Best practices

• Tell Copilot the outcome you want. ‘Approve’, ‘confirm’, ‘decline gracefully’, ‘request more info’.
• Specify the tone. Same content, different tone, very different email.
• Include specific details. Names, dates, numbers — Copilot can’t guess these.
• Always read before sending. Copilot can sound great but be wrong on facts.

Common mistakes

• Sending Copilot’s draft unedited. Even good drafts need your review for tone and accuracy.
• Pasting confidential information into prompts. Check your tenant’s policies before doing this with sensitive content.
• Generic prompts produce generic emails. ‘Write an email’ is too vague. Be specific.

Sample Copilot prompts

• Draft a short email to [person] asking for [thing]. Keep it friendly and clear. Include a deadline of [date].
• Rewrite this email to be more concise but still polite: [paste text].
• Create three subject line options for this email: [brief context].
• Turn my notes into an email: [bullet notes]. Tone: professional, warm.
• Write a polite decline of this meeting request: [paste]. Acknowledge but explain my conflict.

↑ Back to top ↑ Back to list

Status updates are routine, expected, and easy to mess up. Copilot can structure your messy notes into a clear update your manager will actually read.

Writing project updates is one of those tasks that takes more time than it should. You know what’s happened. You know what’s blocked. You know what you need from your manager. But putting it into a clean update, in the right tone, in the right structure, takes longer than the update should ever take. Copilot can fix this.

Give Copilot the facts: project name, status (Green/Amber/Red), what’s progressed since last update, what’s blocked, what you need (a decision, support, a resource). Ask for a structured update with clear headings. Out comes something your manager can read in 30 seconds — and act on. The whole exercise takes you 5 minutes instead of 25.

The deeper benefit is that consistent updates build trust. Managers learn to expect the same format every time, scan the parts they need, and act on the ‘help needed’ line. Project status moves from ‘something to chase’ to ‘something I can rely on’. That’s worth investing 5 minutes in, every week.

When you’ll use this

• When your manager asks for a status update and you have 5 minutes, not an hour.
• When you’re sending a regular project update and want consistency.
• When you need to escalate a blocker and want the right tone.
• When you’re moving from messy progress notes into something a manager will read.

How to do it

1. List the project name, current status, and time period.
2. Add key progress points (what changed since the last update).
3. Note any blockers, risks, or things you need from your manager.
4. Ask Copilot to format as a structured email or Teams message.
5. Use clear headings: Status, Progress, Risks, Next steps, Help needed.
6. Review and ensure dates, owners, and numbers are accurate.
7. Send.

Best practices

• Lead with status and impact, not background. Your manager doesn’t need the warm-up paragraph.
• Use consistent headings. Status, Progress, Risks, Next steps, Help needed — every time.
• Be explicit about decisions required. ‘Need approval to proceed by Friday’ beats ‘might need approval’.
• Keep it to 6-10 lines unless asked for more. Brevity is professional.

Common mistakes

• Writing 600 words when 100 will do. Long updates don’t get read.
• Burying the ask. ‘Help needed’ should be obvious, not hidden in paragraph 4.
• Forgetting to mention what’s blocked. If you only report progress, you signal everything is fine when it isn’t.

Sample Copilot prompts

• Write a project update for my manager. Use headings: Status, Progress, Risks, Next steps, Help needed. Notes: [paste].
• Rewrite this update to be half the length but keep the key points: [paste].
• Turn this update into a Teams message under 100 words: [paste].
• Suggest a clear ‘help needed’ line based on these blockers: [paste].
• Make this update sound more confident without being aggressive: [paste].

↑ Back to top ↑ Back to list

The hardest part of building a deck isn’t designing the slides — it’s deciding what should be on each one. Copilot does that in 30 seconds.

Anyone who’s built a presentation knows the moment of staring at a blank PowerPoint and not quite knowing where to start. The structure problem comes before the design problem. What goes on slide 2? Slide 3? How does the story flow? Copilot is excellent at exactly this part — generating a logical, well-structured outline you can then design slides around.

Tell Copilot the goal of the presentation, who the audience is, and how long it needs to be. Out comes a slide-by-slide outline with titles, bullet points, and a logical flow. Even if you don’t use it as-is, it gives you a starting structure to react to — which is much faster than starting from nothing.

The thing to know about Copilot-generated outlines is they’re often too generic at first pass. Push back. ‘Make this more executive-friendly.’ ‘This audience already knows the basics — skip the intro.’ ‘I want to lead with the recommendation, not build up to it.’ The second iteration is usually much better than the first.

When you’ll use this

• When you’re starting a new deck and need a structural starting point.
• When you’re stuck deciding what should go on each slide.
• When you’ve been asked to present on a topic and don’t know how to organise it.
• When you want speaker notes drafted alongside your outline.

How to do it

1. Define the audience, goal, and time limit (e.g. 5 minutes, 10 slides).
2. Ask Copilot for an outline with slide titles and 2-4 bullets per slide.
3. Request a logical flow (problem → options → recommendation → next steps).
4. Adjust the outline to match your organisation’s language and priorities.
5. Iterate: ask Copilot to make it more executive-friendly, less technical, more visual.
6. Convert the outline into actual slides.
7. Generate speaker notes from the outline if presenting live.

Best practices

• Tell Copilot the decision you want the audience to make. Outlines built around a decision are sharper than outlines built around a topic.
• Ask for slide titles in ‘headline’ style. ‘Q3 revenue grew 12%’ is a slide; ‘Q3 Revenue’ is a label.
• Iterate aggressively. First-draft outlines are starting points, not final products.
• Double-check facts before slides go to leadership. Hallucinated numbers in outlines can become hallucinated numbers in slides.

Common mistakes

• Using the first-draft outline as the final outline. First drafts are generic. Push for sharpness.
• Making slides for every bullet Copilot suggested. One idea per slide. Trim ruthlessly.
• Letting Copilot’s tone overwrite your team’s tone. Adjust the language to fit how your audience actually talks.

Sample Copilot prompts

• Create a 10-slide presentation outline about [topic] for [audience]. Goal: [goal].
• Give me slide titles only, in a compelling ‘headline’ style, for this topic: [topic].
• Rewrite this outline to be more executive-friendly and less technical: [paste].
• Create speaker notes for each slide based on this outline: [paste].
• Suggest the strongest opening slide and the strongest closing slide for this presentation.

↑ Back to top ↑ Back to list

Most business writing is too long, too jargony, and too cautious. Copilot can rewrite it for clarity — without changing what you actually mean.

Most professional writing is clearer than it has to be — and Copilot is excellent at making it clearer. Long sentences shorten. Jargon disappears. Passive voice becomes active. The meaning is preserved; the friction is reduced. The reader gets the point faster.

Where this matters most is when you’re writing for an audience that doesn’t share your background. Technical writing for non-technical readers. Business writing for general staff. Internal jargon for external customers. Copilot can act as the translator — and the translation is usually faster than rewriting yourself, especially when you’re tired or under pressure.

The risk is over-smoothing. Copilot tends to ‘flatten’ tone — interesting prose becomes generic prose, your voice becomes Copilot’s voice. For high-stakes writing (your blog post, a proposal, a customer-facing email), use Copilot for clarity but keep your own voice in the final version. For routine writing, the flatness is fine; clarity matters more than style.

When you’ll use this

• When your writing is technically correct but hard to read.
• When you’re writing for a less-technical audience and need to translate.
• When your draft is too long and you need to trim without losing meaning.
• When you’re stuck on how to phrase something and need a starting point.

How to do it

1. Select the text you want to improve (paragraph, section, or whole page).
2. Ask Copilot to rewrite for clarity and brevity, keeping meaning unchanged.
3. Specify the audience (end users, executives, customers).
4. Specify the tone (plain English, confident, friendly, formal).
5. Ask Copilot to keep specific terms unchanged (product names, policies, acronyms).
6. Compare the rewrite to the original — has anything important been removed?
7. Adjust to add back any missing nuance.
8. Replace the section in your document.

Best practices

• Specify the audience before rewriting. Different audiences need different rewrites.
• Tell Copilot what to preserve. Product names, regulatory language, key terms.
• Watch for over-smoothing. Copilot can flatten interesting prose into corporate mush. Push back.
• Active voice and short sentences for instructions. Tell Copilot this explicitly if you want it.

Common mistakes

• Accepting the rewrite without comparing to the original. Subtle meaning can be lost.
• Letting Copilot remove technical terms that should stay. ‘API’ shouldn’t become ‘connection’ if your audience knows what an API is.
• Using Copilot rewrites for content where your voice matters. Personal blog posts, customer messages, distinctive tone — keep it yours.

Sample Copilot prompts

• Rewrite this in plain English for end users. Keep meaning the same: [paste].
• Make this more concise and remove jargon. Keep any product names unchanged: [paste].
• Rewrite this to sound confident but not aggressive: [paste].
• Give me two rewrite options: one formal, one friendly: [paste].
• Shorten this to under 100 words while preserving the key points: [paste].

↑ Back to top ↑ Back to list

Copilot can generate 12 ideas faster than you can generate 3. Use it to break out of stuck thinking and pressure-test what you have.

Brainstorming with Copilot isn’t a replacement for human creativity — it’s a prompt for it. Ask for 10 ideas on a topic and Copilot produces 10. Some are obvious, some are bad, a few are interesting. The interesting ones spark your own thinking. The obvious ones confirm what you already know. The bad ones, by contrast, sharpen what makes a good idea.

The skill is iterating. First-draft brainstorming is broad and generic. Pick the most interesting 2-3 ideas and ask Copilot to expand them: ‘For idea 3, what would the first month of work look like?’ or ‘For idea 7, what could go wrong and how would I handle it?’. The deeper questions produce more useful output than the initial brainstorm.

Copilot is also good at the meta question: ‘What am I missing?’ or ‘What’s a non-obvious approach to this?’. These prompts get past the boring options and surface unconventional thinking. They won’t always work, but when they do, they save you from going down the same well-worn path everyone else takes.

When you’ll use this

• When you’re stuck on a problem and need fresh angles.
• When you need a list of options to choose from.
• When you want to pressure-test an idea you’ve already had.
• When you’re starting a project and need to generate possibilities before narrowing down.

How to do it

1. Explain the goal, constraints, and what ‘good’ looks like.
2. Ask Copilot for 10-12 ideas — quantity beats quality at this stage.
3. Ask Copilot to group the ideas into themes.
4. Pick the top 2-3 and ask for pros/cons, effort, and risks for each.
5. Ask ‘what am I missing?’ or ‘what’s a non-obvious option?’.
6. Pick one idea and ask for a simple plan to execute.
7. Apply your own judgement to the final selection — Copilot generates options, you choose.

Best practices

• Brainstorm wide first, then narrow. Don’t kill ideas in the first round.
• Ask ‘what am I missing?’. Reveals blind spots in your thinking.
• Iterate on the top 2-3 ideas. Depth beats breadth after the initial brainstorm.
• Capture ideas somewhere durable. Otherwise they evaporate when the chat ends.

Common mistakes

• Stopping at the first round. Initial brainstorming is generic. Push for round two and three.
• Letting Copilot pick for you. Generation is the AI’s job; selection is yours.
• Brainstorming without constraints. ‘What should we do?’ is unanswerable. Add constraints (time, budget, scope) for sharper output.

Sample Copilot prompts

• Brainstorm 12 ideas for [project]. Constraints: [time/budget/tools].
• Group these ideas into 3 themes and recommend the strongest theme: [paste ideas].
• For the top 3 ideas, give pros/cons, effort, and risks.
• What am I missing? What’s a non-obvious approach to this?
• Create a one-week action plan for idea #2 with daily tasks.

↑ Back to top ↑ Back to list

Spreadsheets full of numbers don’t speak for themselves. Copilot can read your data and tell you the ‘so what’ — what changed, what matters, what to do.

Data analysis used to require either skill (in Excel, in pivot tables, in interpretation) or asking someone with the skill. Copilot collapses that gap dramatically. Show it a spreadsheet and ask ‘what’s this telling me?’ and within seconds you have a plain-language explanation of trends, outliers, and what they probably mean.

The catch is that Copilot is interpreting what it sees, not necessarily what’s true. It can spot trends correctly. It can also project trends incorrectly, miss context, or apply the wrong frame. For data that’s important — financial, operational, decisions — use Copilot’s interpretation as a starting point, then verify the underlying numbers and the logic of the conclusion.

The most useful pattern is to ask Copilot for the ‘so what’ and the ‘what should I do’. Numbers without action are just noise. ‘Revenue grew 12%’ is data; ‘revenue grew 12%, driven by enterprise sales, suggesting we should double down on enterprise marketing’ is insight. Copilot can produce both, but you need to ask for the second one explicitly.

When you’ll use this

• When you have a spreadsheet of numbers and need the headline.
• When you’re preparing a report and need a ‘what does this mean’ paragraph.
• When you need to explain data to a non-technical audience.
• When you want to identify trends, outliers, or notable changes quickly.

How to do it

1. Open the spreadsheet (or summarise its structure if you can’t share it directly).
2. Tell Copilot what the metric is and what success looks like.
3. Ask for trends, highs/lows, and notable changes.
4. Ask for the top 3 insights — focus, not exhaustiveness.
5. Ask for ‘what should I do based on this’ or ‘what questions does this raise’.
6. Verify the underlying numbers and logic before presenting.
7. Use the output to write a short summary for your audience.

Best practices

• Tell Copilot what the metric represents. Numbers without context produce wrong interpretations.
• Ask for top 3 insights, not ‘all insights’. Focused output is more useful than exhaustive output.
• Verify before presenting. Especially percentages, totals, and comparisons.
• Use simple visuals for one insight at a time. Don’t dump 12 charts on a slide.

Common mistakes

• Trusting Copilot’s interpretation without checking the numbers. AI hallucinations in numerical context can be subtle.
• Asking ‘analyse this data’ with no context. Generic output, often wrong frame.
• Confusing correlation with causation. Copilot sometimes confidently claims causal relationships that the data only shows correlation for.

Sample Copilot prompts

• Explain what this data is telling me. Focus on trends, spikes, and changes: [context].
• Summarise the top 3 insights and why they matter for [audience].
• What questions should I ask next based on these numbers?
• Write a short paragraph I can use in a report summarising the findings.
• What’s the most surprising thing in this data and why?

↑ Back to top ↑ Back to list

A chart without commentary is just shapes on a slide. Copilot can write the explanation that turns a chart into a story.

Charts are essential in presentations and reports — but they’re also where most decks fall flat. The chart shows the data; the audience has to interpret it themselves; half the meaning is lost. The fix is to add a one-sentence takeaway and a short description that tells the audience what the chart means, not just what it shows.

Copilot can write these descriptions in seconds. Tell it what the chart shows (the metric, the timeframe, the categories), and ask for a takeaway plus a longer description. The takeaway becomes your slide title or the line under the chart. The description becomes your speaker notes or the body text. The chart now communicates, instead of just decorating.

This is also where accessibility lives. Charts without descriptions are inaccessible to screen readers. A short alt text on every chart makes your content usable by people who can’t see it — and it’s the same description Copilot has already written. Win twice with one prompt.

When you’ll use this

• When you have a chart in a presentation and need commentary.
• When you want a one-line headline that explains what the chart shows.
• When you want speaker notes for a slide with a chart.
• When you need accessible alt text for charts in any document.

How to do it

1. Identify what the chart shows (metric, timeframe, categories).
2. Ask Copilot for a one-sentence takeaway.
3. Ask for a 2-3 sentence description suitable for a slide or speaker notes.
4. Edit to match your slide tone and keep it factual.
5. Add the description to speaker notes, body text, or alt text.
6. Verify the description against the actual chart data.

Best practices

• Lead with the takeaway. What changed, what matters — first.
• Use units and timeframes explicitly. ‘Revenue grew 12% from Q1 to Q3’ is precise; ‘revenue grew’ is vague.
• Avoid vague terms. ‘A lot’ and ‘significantly’ are weak. Use approximate values.
• Write alt text at the same time. Same description, different placement.

Common mistakes

• Letting Copilot invent numbers. If the chart shows 12%, the description should say 12%, not ‘15%’ because Copilot guessed.
• Generic descriptions that work for any chart. If the description doesn’t reference the actual data, it’s useless.
• Forgetting alt text. Descriptions you wrote anyway should also be accessible.

Sample Copilot prompts

• Write a clear chart description for this slide. Chart shows: [describe].
• Give me a one-sentence takeaway and a 3-sentence description of this chart: [details].
• Rewrite this chart description to be more executive-friendly: [paste].
• Create alt text for this chart that is concise but informative: [details].
• Write a 60-second verbal explanation of this chart for a meeting: [details].

↑ Back to top ↑ Back to list

Customer feedback is unstructured, repetitive, and exhausting to read in bulk. Copilot finds the patterns in 30 seconds.

Customer feedback — survey responses, support tickets, NPS comments, app reviews — comes in floods, and reading it all manually doesn’t scale. But the patterns within it are gold: the same complaints come up repeatedly, the same praise points get repeated, the issues that drive churn cluster around themes. Copilot is exceptional at pulling those patterns out fast.

Give Copilot a batch of feedback and ask for themes, frequency, and example quotes. Within seconds you get something like: ‘60% mention onboarding friction, 25% praise customer support speed, 15% raise pricing concerns.’ Add representative quotes and you have a feedback summary you can act on — without having to read 800 individual entries.

The thing to watch is anonymisation. Customer feedback often contains names, emails, account details — sensitive data you don’t want flowing through prompts unnecessarily. Strip personal details before analysing in bulk, or use sanctioned tooling that handles this within your tenant. Pattern-finding doesn’t need to know who said it; it just needs the words themselves.

When you’ll use this

• When you have a batch of customer feedback and need a summary.
• When you’re preparing for a customer review meeting and need themes.
• When you need to identify what to fix or prioritise based on customer voice.
• When you’re writing a report and need the customer narrative.

How to do it

1. Collect the feedback text (export from Forms, copy from emails, etc.).
2. Strip personal identifiers before processing.
3. Ask Copilot to group feedback into themes with frequency counts.
4. Ask for representative example quotes for each theme.
5. Ask for edge cases — minority issues that might be early signal.
6. Ask for recommended actions based on the main themes.
7. Review and adjust based on your own knowledge of customers.

Best practices

• Anonymise before processing. Customer names and details aren’t needed for theme analysis.
• Ask for themes plus edge cases. Don’t miss minority signal.
• Distinguish symptoms from causes. ‘Slow load times’ is a symptom; ‘oversized images’ might be the cause.
• Convert themes into actions with owners. Insights without action are wasted.

Common mistakes

• Including personal data in prompts unnecessarily. Anonymise first.
• Trusting frequency counts without sampling. Spot-check the underlying feedback to confirm Copilot grouped accurately.
• Acting only on themes, not edge cases. Outliers can be your most valuable signal.

Sample Copilot prompts

• Group this feedback into themes and summarise each theme: [paste].
• What are the top 5 recurring issues and suggested fixes?
• Provide a short action list based on this feedback, prioritised by impact.
• Summarise feedback for leadership in 6 bullet points: [paste].
• Show me edge-case feedback that might be early signal of bigger issues.

↑ Back to top ↑ Back to list

The hardest part of communicating data isn’t the analysis — it’s the translation. Copilot turns complex findings into language anyone can understand.

Most data analysis ends up communicated to non-technical audiences — leadership teams, business stakeholders, customers. The analyst understands the data; the audience often doesn’t. The translation gap is where good analysis goes to die. Copilot is excellent at bridging this — turning technical findings into plain language without losing accuracy.

The trick is to give Copilot both the technical version and the audience. ‘Here’s what the data shows; explain this to a non-technical executive in 60 seconds.’ or ‘Here’s the analysis; rewrite it for an internal newsletter.’ The audience framing shapes the language: an executive needs the headline and the implication; a newsletter needs the story; a customer-facing message needs the relevance.

What you don’t want is over-simplification. Copilot can sometimes flatten technical detail to the point of misleading the audience. ‘Customer churn is up 8%’ is simpler than ‘churn rose from 3.2% to 3.5% (a 9.4% relative increase)’ but the second is more accurate. For high-stakes communication, ask for two versions and pick the right one.

When you’ll use this

• When you’ve done analysis and now have to explain it to non-technical stakeholders.
• When preparing a presentation, briefing, or report for a senior audience.
• When you need a ‘what this means for you’ summary for customers or staff.
• When you’re writing internal communications about data-heavy topics.

How to do it

1. Describe the dataset and what decision it supports.
2. Ask Copilot to explain it in plain language with a simple example.
3. Specify the audience explicitly (executive, customer, general staff).
4. Request a short ‘what this means’ section.
5. Ask for a recommended chart type to communicate the insight.
6. Validate terminology and ensure technical accuracy hasn’t been lost.
7. Test the explanation on someone in your audience profile if possible.

Best practices

• Use everyday language and avoid acronyms unless defined. Spell out what your jargon means.
• Explain one insight at a time, then build up. Don’t dump three findings into one paragraph.
• Include the decision or action the data supports. Why should the audience care?
• Use analogies carefully. Wrong analogies are worse than no analogies.

Common mistakes

• Over-simplifying to the point of inaccuracy. Better to use slightly more technical language than to mislead.
• Ignoring the audience’s domain knowledge. Different audiences need different translations.
• Skipping the ‘so what’. Data without implication is noise.

Sample Copilot prompts

• Explain this dataset to a non-technical audience in plain English: [context].
• Write a short ‘What this means’ section for leadership based on these findings: [summary].
• Suggest the best chart to communicate this insight and why.
• Create a 60-second verbal explanation I can say in a meeting.
• Give me two versions: one accurate and slightly technical, one simpler and more accessible.

↑ Back to top ↑ Back to list

Outliers are where the interesting stuff lives — the early signals, the anomalies, the things you’d want to know about. Copilot finds them fast.

Most data analysis focuses on averages, trends, and headlines. But the outliers — the data points that don’t fit the pattern — are often where the most interesting stories are. The unusually high score, the sudden drop, the customer who behaved completely differently from everyone else. Copilot can scan datasets and surface these anomalies in seconds.

The challenge is that not every outlier is meaningful. Some are data entry errors. Some are seasonal effects. Some are real signal that something is changing. Copilot can identify the outliers, but you need to bring the context: ‘Is this December spike normal? Yes — happens every year.’ or ‘This region’s drop is concerning. Let’s investigate.’ The AI flags; you interpret.

Use outlier analysis as the start of a conversation, not the end. ‘These five values are outliers’ is a list. ‘These five values are outliers, here’s why each might be worth investigating, and here are the questions to ask the source teams’ is a starting point for action. Copilot can do all of this if you ask explicitly.

When you’ll use this

• When you suspect something unusual is happening in your data.
• When you want to spot-check a dataset for errors or anomalies.
• When you’re investigating a sudden change or unexpected result.
• When preparing a report and want to call out the most notable points.

How to do it

1. Define what ‘normal’ looks like for the dataset (range, average, expected pattern).
2. Ask Copilot to identify outliers and explain why they stand out.
3. Ask for possible reasons for each outlier (errors, seasonality, real change).
4. Request follow-up questions or validation checks you should run.
5. Verify the outliers against context (what was happening at that time?).
6. Decide whether to investigate further, ignore (known cause), or fix (data error).

Best practices

• Compare like with like. Outliers in one segment may not be outliers in another.
• Check for data quality issues first. Often outliers are typos, not real anomalies.
• Look at outliers in context. Some are valid (a one-time event); others are concerning (early signal).
• Document assumptions. What you treated as normal vs anomalous matters for the analysis.

Common mistakes

• Treating every outlier as significant. Many are noise. Apply judgement.
• Ignoring outliers that don’t fit your hypothesis. The unwelcome outlier might be the most important signal.
• Acting on outliers without verification. One bad data point shouldn’t drive a major decision.

Sample Copilot prompts

• Based on this data summary, what outliers or unusual patterns stand out? [summary].
• Suggest validation checks I should run in Excel to confirm these anomalies.
• List possible reasons these numbers could be unusually high/low.
• Draft a short message asking the data owner to verify these outliers.
• Are these outliers likely to be data errors, seasonal effects, or real signal?

↑ Back to top ↑ Back to list

Copilot can give you a working understanding of a topic in five minutes. It’s not a substitute for deep learning — but it’s an excellent starting point.

When you need to understand something new fast — a regulation, a methodology, a concept that just came up in a meeting — Copilot is genuinely useful as a research tool. Tell it your starting level (beginner, intermediate) and what you need to do with the information, and it produces a working overview, key terms to know, and pointers for going deeper.

The skill is in framing the request around your context. ‘Tell me about agile’ produces a generic overview. ‘I’m a project manager moving from waterfall to agile in a financial services org — what do I need to know?’ produces something far more useful. The more context Copilot has about your situation, the more relevant the research output.

What Copilot is bad at is acting as your only source. It doesn’t always know what’s recent, accurate, or specific to your jurisdiction. For anything regulatory, legal, or industry-specific, treat Copilot’s research as orientation — and verify with authoritative sources before relying on it. The starting point is fast; the verification is non-negotiable.

When you’ll use this

• When you need to get up to speed on a topic before a meeting or decision.
• When you’ve encountered a term or concept and need a working understanding.
• When you’re moving into a new role or domain and need orientation.
• When you want a structured overview before reading deeper sources.

How to do it

1. State the topic, your goal, and your current level (beginner, intermediate, expert).
2. Ask Copilot for an overview plus key terms to understand.
3. Request ‘what to avoid’ or common mistakes if it’s a method or tool.
4. Ask for a checklist or simple framework you can apply at work.
5. Note any claims that need verification (regulatory, technical, recent).
6. Verify against authoritative sources before relying on it for decisions.
7. Apply what’s relevant; ignore what doesn’t fit your context.

Best practices

• Be specific about your context. Industry, role, what you’ll do with the info — all of it shapes the answer.
• Ask for ‘what to avoid’. Common mistakes are often the most useful information.
• Turn research into actions. A checklist beats a summary for actually applying knowledge.
• Verify anything that matters. Especially regulatory, legal, or industry-specific claims.

Common mistakes

• Treating Copilot as your only source. It can be confidently wrong, especially on recent or specific topics.
• Skipping the verification step on regulatory content. ‘Copilot said it was fine’ is not a defence.
• Asking generic questions. ‘Tell me about X’ produces generic answers. Add context.

Sample Copilot prompts

• Give me a quick overview of [topic] and the key terms I need to know.
• What are the most common mistakes people make with [topic]?
• Create a simple checklist I can apply at work for [topic].
• Explain [topic] at a beginner level, then at an advanced level.
• I’m a [role] in [industry] — what do I need to know about [topic]?

↑ Back to top ↑ Back to list

When something technical lands on your desk and you need to grasp it without going deep, Copilot translates it into something you can actually work with.

Most non-technical roles still encounter technical content regularly: an architecture document from IT, a security review, a vendor’s API capabilities, a developer’s design proposal. You don’t need to become an expert — you just need a working understanding to make decisions or ask the right questions. Copilot is genuinely useful here, translating dense technical content into plain English with examples that make sense.

Paste a technical paragraph and ask Copilot to explain it as if to someone with your background. Better still, ask for a ‘why does this matter for me’ section — what does this mean for your team, your product, your decisions? The technical content becomes actionable instead of just incomprehensible.

Where this falls down is on highly specialised content. A working understanding of cybersecurity is fine for an executive; the same level of understanding for a security architect is dangerous. Match the depth of explanation to what you actually need to do, and don’t pretend to understand more than you do. Copilot is a translator, not a substitute for expertise.

When you’ll use this

• When you’ve been sent a technical document and need a working understanding.
• When you’re in a meeting that’s heading into technical depth and need orientation.
• When you need to communicate a technical concept to non-technical stakeholders.
• When you want to ask better questions of your technical colleagues.

How to do it

1. Paste the technical content or describe the concept.
2. Ask Copilot to explain it in plain English with an example.
3. Specify your background (executive, project manager, business analyst).
4. Request a ‘why does this matter’ or ‘what should I do’ section.
5. Ask for the questions you should ask a technical SME to deepen understanding.
6. Verify with technical colleagues if you’re going to act on the explanation.
7. Use the explanation as a starting point, not a final understanding.

Best practices

• Specify your starting level. ‘I’m not technical’ or ‘I have basic knowledge’ shapes the depth.
• Ask for examples using your tools. Generic examples don’t stick.
• Request a glossary if there are many terms. Unfamiliar vocabulary derails understanding.
• Don’t skip the SME conversation for high-stakes decisions. Copilot is orientation, not authority.

Common mistakes

• Pretending to understand more than you do. Better to admit gaps and ask for verification.
• Trusting Copilot for highly specialised technical decisions. Match expertise to stakes.
• Using the explanation as the final word. Treat it as a starting point.

Sample Copilot prompts

• Explain this concept in plain English and give a simple example: [paste].
• Summarise this for a non-technical audience in 5 bullet points: [paste].
• What questions should I ask an SME to confirm I understand this correctly?
• Create a short glossary of the key terms in this passage: [paste].
• What are the implications of this for a non-technical project manager?

↑ Back to top ↑ Back to list

Most workflows can be improved if you start from proven approaches. Copilot is a fast way to gather best practices — and the pitfalls to avoid.

When you’re trying to improve a process — onboarding, document review, project handovers, meeting facilitation — there’s usually a body of accumulated wisdom about what works. Copilot can pull that wisdom together quickly: principles, common patterns, things to avoid, simple frameworks. It saves you from reinventing what others have already worked out.

The skill is in narrowing the request to your context. ‘Best practices for project management’ is too broad. ‘Best practices for managing a 6-week digital project with 4 people in a regulated industry’ produces something you can actually apply. Constraints make the output sharper.

Where this is most useful is when you’re new to running something. Inherited a process you don’t know? Designing one from scratch? Ask Copilot for the standard pitfalls and the proven approaches, then layer your own judgement on top. You’ll skip past mistakes you’d otherwise have made and get to the interesting decisions faster.

When you’ll use this

• When you’re improving an existing workflow and want proven approaches.
• When you’re designing a new process from scratch and need a starting framework.
• When you’ve inherited a process and want to know if you’re doing it right.
• When you’re training someone in a process and want a checklist.

How to do it

1. Describe the process and what problem you’re solving.
2. Add constraints: team size, timeline, industry, tools.
3. Ask Copilot for best practices and a ‘minimum viable’ version of the process.
4. Request common pitfalls, risks, and quick wins.
5. Ask for a checklist your team can actually use.
6. Tailor the output to your organisation’s tools and policies.
7. Pilot the new process before rolling out widely.

Best practices

• Anchor best practices to outcomes. What does success look like? Speed? Quality? Compliance? Different priorities lead to different practices.
• Ask for ‘good enough’ options. Not every process needs to be world-class. Sometimes ‘better than what we have’ is the right target.
• Document ownership and decision points. A process without ownership isn’t a process.
• Turn guidance into a checklist. Bullet points your team can actually follow beat philosophical frameworks.

Common mistakes

• Asking for best practices without constraints. You get generic theory, not applicable advice.
• Implementing ‘best practices’ without piloting. What works for others may not fit your context.
• Skipping the pitfalls section. Knowing what to avoid is often more useful than knowing what to do.

Sample Copilot prompts

• Give me best practices for this process: [describe]. Include pitfalls and quick wins.
• Create a simple checklist we can use every time for this workflow: [describe].
• Propose a lightweight governance approach for this process in Microsoft 365.
• Write a short ‘how we do it here’ guideline based on these requirements: [paste].
• What’s the ‘minimum viable’ version of this process I can pilot in two weeks?

↑ Back to top ↑ Back to list

There’s too much happening in any industry to keep up with manually. Copilot can curate a quick digest — and tell you what to actually pay attention to.

Keeping up with industry news manually is a losing battle. Newsletters pile up, blog posts go unread, the LinkedIn feed is mostly noise. Copilot can do the curation work for you — summarise what’s been happening across your topics of interest, highlight what matters, and tell you what to read in full versus what to skim.

The trick is to be specific about your role and the topics you actually care about. ‘Tell me what’s happening in tech’ is too broad. ‘I’m a SharePoint admin in a financial services org. Give me a weekly digest of Microsoft 365 updates that matter for my role’ is something Copilot can do well — and the output is genuinely useful instead of generic.

Where this is most powerful is when you turn it into a habit. A weekly 5-minute prompt that produces your industry digest is a better information diet than reading 30 newsletters. The information is filtered, focused, and tied to action — what you should adopt, what to watch, what to ignore.

When you’ll use this

• When you want a regular digest of industry updates.
• When you’ve fallen behind on industry news and need to catch up.
• When you want to know what changed recently in your tools or platforms.
• When preparing for a strategy session or planning cycle.

How to do it

1. Tell Copilot your role and the topics you care about.
2. Ask for a digest format: 5-10 bullets, grouped by theme.
3. Request ‘why this matters’ for each item.
4. Ask for a shortlist of actions: what to adopt, watch, or ignore.
5. Make this a recurring prompt — same format every time.
6. Capture key changes that affect your team in a running note.
7. Validate major changes before communicating to your team.

Best practices

• Limit to 3-5 topics for focus. Broad digests become noise.
• Ask for impact on your tools and workflows. Headlines without implications aren’t useful.
• Capture decisions and adoptions. What changed because of this digest?
• Verify big news before acting. Copilot can mix up dates or details.

Common mistakes

• Asking for ‘all the news’ without a filter. You get exhaustive output that’s hard to read.
• Trusting recency claims without checking. Copilot may confuse ‘recent’ with ‘in training data’.
• Reading the digest but not acting. Information without action is just consumption.

Sample Copilot prompts

• I’m a [role]. Give me a weekly digest of updates on: [topics]. Keep it under 10 bullets.
• Summarise what changed this month in Microsoft 365 that impacts end users.
• What should I watch for in the next quarter related to [topic]?
• Turn these updates into a short internal post for staff: [paste].
• What are the three most important things I should know about [topic] right now?

↑ Back to top ↑ Back to list

Most online learning is too long, too generic, and too disconnected from your actual work. Copilot can build a learning plan tied to what you really need to do.

Learning a new tool or skill is usually inefficient. You watch a 30-minute video to find one 2-minute tip you needed. You read a tutorial that uses examples completely unlike your actual work. You take a course that’s interesting but disconnected from anything urgent. Copilot can fix this by building a learning plan around your specific context — what you need to do, what you already know, what your time budget is.

Tell Copilot the tool or skill, your starting level, and your goal. Ask for a structured learning plan with practical exercises using real workplace scenarios. Within seconds you have a 14-day or 30-day plan with daily 20-minute tasks, hands-on exercises, and a checklist of core skills you should develop. Far more useful than a generic course.

The pattern that works best is small loops: try, reflect, repeat. Copilot can prompt you with daily exercises, quiz you on what you’ve learned, and adjust the plan based on what’s working. Treat it like a tutor who’s available 24/7 and customises around what you actually need.

When you’ll use this

• When you’ve been asked to learn a new tool and don’t know where to start.
• When you need to ramp up on a skill quickly for a specific project.
• When you’ve tried generic tutorials and they don’t fit your context.
• When you want a practical, exercise-based learning plan.

How to do it

1. Name the tool or skill and your current level.
2. Specify your goal (job task, project, certification, general capability).
3. Ask for a 14-day or 30-day learning plan with daily 20-minute tasks.
4. Request hands-on exercises using your real workplace scenarios.
5. Ask for a checklist of ‘core skills’ you should master.
6. Track progress and ask Copilot to adjust the plan based on what’s working.
7. Use Copilot to quiz you and reinforce learning.

Best practices

• Focus on real tasks at work, not generic tutorials. Examples that match your environment stick.
• Learn in small loops. Daily 20 minutes beats weekly 3 hours.
• Keep a cheat sheet of commands and steps you use often. Reduces re-learning.
• Quiz yourself. Active recall beats passive reading every time.

Common mistakes

• Trying to learn everything at once. Pick a slice; master it; expand.
• Learning passively without practice. Reading about a tool isn’t using it.
• Letting the plan drift. Without daily check-ins, the plan stops working.

Sample Copilot prompts

• Create a 14-day learning plan for [tool/skill] for a beginner. 20 minutes per day.
• Give me 5 practical exercises I can do in [tool] using real workplace scenarios.
• What are the top 10 things I should learn first in [tool]?
• Quiz me on [topic] with 8 questions and explain the answers.
• Build a cheat sheet of essential [tool] commands and shortcuts.

↑ Back to top ↑ Back to list

Translation is no longer a job for specialists in everyday cases. Copilot can translate fast, with the right tone, and let you check the result.

Translation used to mean either expensive professional services or risky free tools that produced robotic output. Copilot has changed this for everyday business translation. Need to translate an internal email, a customer message, a piece of marketing copy? Copilot does it in seconds, with appropriate tone, and lets you adjust for region or context.

The skill is specifying tone and context. ‘Translate this to French’ produces a literal translation. ‘Translate this to French (for France) in a friendly customer-facing tone, and keep our product names unchanged’ produces something you can actually send. Tone and locale matter — French for France isn’t the same as French for Quebec.

Where this falls short is for legally binding or culturally sensitive content. Contracts, regulatory communications, anything where exact wording matters legally — those still need professional translators. Copilot is excellent for the routine 95%; for the high-stakes 5%, treat it as a starting draft for a human translator to refine.

When you’ll use this

• When you need to send an email, message, or document in another language.
• When you’ve received a non-English document and need to understand it quickly.
• When you’re communicating with international colleagues or customers.
• When you want a draft translation to send to a professional translator.

How to do it

1. Paste the source text and specify the target language.
2. Tell Copilot the tone (formal, friendly, customer-facing, internal).
3. Specify the region if relevant (Spanish for Spain vs Mexico, etc.).
4. Ask Copilot to keep specific terms unchanged (product names, brand names, technical terms).
5. Review the translation for tone and accuracy.
6. If the content is high-stakes, send to a professional translator for verification.
7. Save useful translations or build a glossary for repeat use.

Best practices

• Specify region for languages with multiple variants. Spanish, French, Portuguese, Chinese — region matters.
• Ask Copilot to keep brand names and acronyms unchanged. ‘Microsoft 365’ shouldn’t become ‘Microsoft 365 in Italian’.
• Use the ‘natural’ version for readability. Literal translations sound like translations; natural ones sound right.
• Don’t translate confidential content unless your environment allows it. Check your tenant’s policies.

Common mistakes

• Translating high-stakes legal content with Copilot only. Professional translators exist for a reason.
• Forgetting tone and context. Same words in different tones land very differently.
• Trusting translations without a native speaker review for important communications. Subtle errors are easy to miss.

Sample Copilot prompts

• Translate this into [language] in a professional tone: [paste].
• Translate this into [language] but keep product names and acronyms unchanged: [paste].
• Provide two options: one literal, one more natural and conversational.
• Translate and shorten this to under 120 words: [paste].
• Translate this email and adjust the tone for a [region] customer.

↑ Back to top ↑ Back to list

Even good writers benefit from a second pair of eyes. Copilot is a fast, patient proofreader who’ll explain its suggestions if you ask.

Proofreading your own writing is hard — you read what you meant to write, not what’s actually on the page. Copilot reads what’s actually there, and catches grammar issues, typos, awkward phrasing, and unclear sentences in seconds. For everyday business writing — emails, reports, internal docs — it’s a fast quality check that catches most of what would otherwise slip through.

The most useful pattern is to ask for both the suggestion and the reason. ‘Proofread this and explain your edits’ produces output that helps you learn — what you tend to do wrong, what to watch for next time. Over time, your writing improves because you understand the patterns Copilot is fixing, not just because Copilot fixed them.

Be careful with high-stakes content. For legal documents, regulated content, or anything customer-facing where exact wording matters, treat Copilot’s suggestions as one input — not the final word. Some of its ‘improvements’ will smooth over distinctions that matter, or change technical language that needed to stay precise. Read every change before accepting.

When you’ll use this

• When you’ve drafted something and want a quality check before sending.
• When your writing feels clunky and you want a polish.
• When you want to learn what you tend to get wrong.
• When you need to tighten something to a length limit.

How to do it

1. Paste your draft or select the text to improve.
2. Ask Copilot to proofread and suggest improvements.
3. Request structural improvements (headings, bullets) for longer text.
4. Ask Copilot to explain its edits if you want to learn.
5. Review each change — accept the ones that improve, reject the ones that change meaning.
6. For high-stakes content, do a final human read.
7. Keep your voice in the final version.

Best practices

• Ask for ‘suggested edits’ and ‘why’ if you want to learn. Proofreading is also teaching.
• Keep key terms consistent. Process names, teams, systems — Copilot may try to vary them; tell it not to.
• Use short sentences for instructions. Tell Copilot this if you want it.
• Be careful with compliance language. Confirm exact wording before accepting changes.

Common mistakes

• Accepting all suggestions without reading. Some ‘improvements’ change meaning subtly.
• Letting Copilot strip your voice. If your writing sounds like you, that’s a feature, not a bug.
• Not learning from edits. The patterns Copilot catches are usually patterns you repeat.

Sample Copilot prompts

• Proofread this and improve clarity while keeping my tone: [paste].
• Rewrite this to be more direct and easier to scan: [paste].
• Suggest a better structure with headings and bullets for this content: [paste].
• Identify any ambiguous wording and propose clearer alternatives: [paste].
• Explain your edits so I understand what I’m getting wrong.

↑ Back to top ↑ Back to list

Conversations produce decisions and actions, but rarely in a structured format. Copilot can turn a messy chat into a clean action list — owners, dates, priorities.

Most actions in modern work emerge from conversations — meetings, Teams chats, hallway discussions, email threads. The actions are usually clear in the moment (‘Sarah will get back to us by Friday with the costings’) but rarely captured systematically. A week later, half the actions have been forgotten, the other half are being done by the wrong people.

Copilot solves this in seconds. Paste a chat transcript, meeting notes, or email thread, and ask for the action items in a structured format. Out comes a table: Action, Owner, Due Date, Notes. Send it back to the group for confirmation and you’ve got a clean record of what was agreed — without anyone having to be a heroic note-taker.

The bigger win is consistency. If every conversation that produces actions ends with a Copilot-generated action list, your team has a reliable accountability system. Decisions don’t get lost. Actions have owners. Due dates exist. The system works because it doesn’t depend on individual heroics.

When you’ll use this

• When a meeting or chat ended with a flurry of actions but no clean list.
• When you’re following up on a decision and need to know who’s doing what.
• When emails are turning into a decision-by-attrition mess.
• When you want a paste-into-Planner action list from a conversation.

How to do it

1. Paste the conversation text or notes (remove sensitive details first).
2. Ask Copilot to extract action items with Owner and Due Date.
3. Request prioritisation — urgent vs later.
4. Ask for output in a format you can paste into Planner or To Do.
5. Verify owners and dates were actually said in the conversation.
6. Send the action list back to the group for confirmation.
7. Add to your task system and follow up.

Best practices

• Always confirm action owners. Copilot will guess if unclear; verify before sending.
• Keep actions verb-based. ‘Decide’, ‘Confirm’, ‘Draft’, ‘Review’ — clear ownership of the verb.
• Separate actions, decisions, and open questions. They’re different things.
• Send back to the group for confirmation. ‘Did I capture these correctly?’ takes 30 seconds and avoids confusion later.

Common mistakes

• Trusting Copilot to invent owners or dates that weren’t said. Hallucinated assignments are real and embarrassing.
• Not separating actions from decisions. An action implies someone needs to do something; a decision is what was agreed.
• Skipping the confirmation step. If the team didn’t agree to it, it’s not an action.

Sample Copilot prompts

• Create a to-do list from this conversation. Include owner and due date if mentioned: [paste].
• Summarise this chat into actions, decisions, and open questions: [paste].
• Rewrite the actions into a format I can paste into Planner: [paste].
• Prioritise these actions by impact and urgency: [paste].
• Flag any action items that are missing an owner or due date.

↑ Back to top ↑ Back to list

Back-to-back meetings leave no time to prepare. Copilot can give you the context, key questions, and a draft contribution in two minutes.

Most modern professionals attend more meetings than they have time to prepare for. The result is meetings where half the room is winging it — reading the agenda for the first time, scanning the relevant document mid-meeting, missing context. Copilot can fix this for routine prep: paste the agenda and any related files, and within two minutes you have the background, key questions to ask, and a clean version of any update you need to give.

The pattern that works is to do this before each meeting as part of your routine. Five minutes of Copilot prep — context summary, your update drafted, three questions you want to ask — turns a meeting where you’d be passive into one where you contribute meaningfully. Done across a week of meetings, the difference in your impact is significant.

What Copilot can’t do is replace genuine engagement. If a meeting matters and you don’t know the topic, you still need to read the document, talk to colleagues, and form your own view. Copilot prep is a force-multiplier for engagement, not a substitute for it.

When you’ll use this

• When you have back-to-back meetings and no time to prepare.
• When you’ve been invited to a meeting outside your usual area.
• When you need to walk into a meeting prepared to contribute.
• When you want to ask better questions, not just react.

How to do it

1. Gather the meeting invite, agenda, and any related files or links.
2. Ask Copilot to summarise the background and the decisions to be made.
3. Request a short list of questions you should ask in the meeting.
4. Ask for a 30-second draft of your update or contribution.
5. Skim the key document sections before joining.
6. After the meeting, capture actions immediately while it’s fresh.

Best practices

• Focus on decisions, risks, and what you need from others. These are what makes meetings worthwhile.
• Prepare one clear update and one clear ask. Don’t try to dominate.
• Reuse your prep prompt template. Same format every time speeds it up.
• Capture actions immediately after. Don’t let the meeting end without writing down what was agreed.

Common mistakes

• Skipping prep entirely. Even five minutes is dramatically better than zero.
• Letting Copilot prep replace engagement on important meetings. Read the document for the meetings that matter.
• Forgetting to capture actions afterwards. Prep is wasted if the outputs aren’t preserved.

Sample Copilot prompts

• Help me prepare for this meeting. Agenda: [paste]. What should I know and what should I ask?
• Summarise the background from these notes and list key decisions to make: [paste].
• Draft a 30-second update I can say in the meeting based on: [paste].
• Create a short checklist for what I should bring to this meeting.
• Three questions I should ask in this meeting that would add value: [agenda].

↑ Back to top ↑ Back to list

When an email is annoying, accusatory, or politically charged, your first draft response is usually wrong. Copilot helps you find the version that won’t backfire.

Most professionals have at least one difficult email per week — the one that’s accusatory, the one that’s misinformed, the one that’s politically charged, the one where you really want to fire back. Your first response is rarely your best response. Copilot is excellent at this exact moment: the cooling-off rewrite that gets your point across without escalating.

Tell Copilot the situation: the email you received, your raw response (even if it’s a vent), and the outcome you actually want (resolve, clarify, set a boundary, decline). Ask for a calm, professional reply with clear next steps. Out comes something that achieves your actual goal — without the fallout your first draft would have caused.

The deeper habit is recognising when to reach for this. The rule of thumb: if you’d be embarrassed to read your draft response back in a year, run it through Copilot. The tone-down loses nothing important and saves a lot of relationship damage. Same content, different tone — very different email.

When you’ll use this

• When you’ve received a difficult email and need to respond professionally.
• When you’ve drafted an angry response and need a calmer alternative.
• When you need to deliver bad news, decline, or push back politely.
• When the situation is politically sensitive and tone matters more than usual.

How to do it

1. Draft your raw response (even messy or angry — get it out first).
2. Paste both the original email and your draft into Copilot.
3. Tell Copilot the outcome you want (resolve, clarify, set boundary).
4. Ask for a calm, professional reply with clear next steps.
5. Verify facts are correct in the rewrite.
6. If the situation is heated, wait 10 minutes before sending.
7. Send.

Best practices

• Focus on facts, impact, and next steps. Avoid blame language.
• Use boundaries: what you can do, what you can’t, what you need. Clear and professional.
• Keep the ask explicit. ‘Please confirm by Friday’ beats vague hopes.
• Don’t CC extra people unless there’s a clear reason. Larger audiences raise the stakes for everyone.

Common mistakes

• Sending your raw response without rewriting. First drafts in difficult situations are rarely the right send.
• Over-softening to the point of unclear. Polite still has to communicate the actual point.
• Not pausing before sending. The 10-minute rule isn’t optional for genuinely heated emails.

Sample Copilot prompts

• Rewrite my reply to be professional and calm. Outcome: resolve and agree next steps. Draft: [paste].
• Write a response that acknowledges concerns, clarifies facts, and proposes next steps: [paste].
• Give me two options: one firm and one more collaborative: [paste].
• Shorten this reply to under 120 words while keeping it polite: [paste].
• How would I respond to this email if my goal was to set a clear boundary?

↑ Back to top ↑ Back to list

Onboarding is rarely a priority — until someone joins your team. Copilot can build a real onboarding plan in 5 minutes, instead of the chaotic first week most new starters get.

Most teams onboard new members badly. There’s no plan; the first week is chaotic; the new person spends a month trying to figure out who to talk to and where things live. The cost is real — slow ramp-up, frustration, sometimes early attrition. Copilot can fix the planning side of this in minutes: structured day 1, week 1, and month 1 plans tailored to the role.

Tell Copilot the role, the key responsibilities, and the team’s actual workflow. Ask for an onboarding checklist — accounts to set up, tools to learn, people to meet, key documents to read, first practical tasks. What you get is a structured plan you can hand to the new starter and their buddy. Five minutes of effort that saves the new person two weeks of confusion.

The real magic is doing this in advance, not reactively. If a new starter joins on Monday and you build the plan on Sunday, you’re already ahead of 80% of teams. Combine the Copilot-generated plan with a named buddy, scheduled 1:1s for the first month, and a ‘how we work here’ guide, and your onboarding becomes a competitive advantage.

When you’ll use this

• When someone new is joining your team and you have to plan their onboarding.
• When you’ve inherited a team without a real onboarding process.
• When you want to standardise how you onboard people across the team.
• When a new starter is struggling and you need to course-correct.

How to do it

1. List the role, key responsibilities, and the team’s main workflows.
2. Ask Copilot for a day 1 / week 1 / month 1 plan.
3. Request a list of key tools, links, and people the new starter should know.
4. Ask for a ‘how we work here’ one-page guide.
5. Combine into a single onboarding pack — checklist, links, schedule.
6. Assign a buddy for the new starter.
7. Review with the new starter at end of week 1 to adjust.

Best practices

• Keep onboarding practical. Tools, access, real tasks first. Strategy and history later.
• Include ‘how we work’ norms. Where files live, how decisions are made, what ‘good’ looks like.
• Assign a buddy. Having someone to ask the dumb questions of changes everything.
• Update the plan after every onboarding. Today’s onboarding is tomorrow’s reusable template.

Common mistakes

• No plan, just ‘figure it out’. The new starter’s ramp-up cost is much higher than your planning cost.
• Too much in week 1. Information overload — pace it across the first month.
• No ‘how we work’ guide. The implicit norms are the hardest part for new starters; make them explicit.

Sample Copilot prompts

• Create a day 1 / week 1 / month 1 onboarding plan for a new [role].
• Write a one-page ‘How we work’ guide for our team. Context: [paste].
• Generate an onboarding checklist for tools and access we use: [list tools].
• Create a simple FAQ a new starter would ask based on these notes: [paste].
• What questions should I ask a new starter at the end of their first week?

↑ Back to top ↑ Back to list

If three people have asked the same question, ten more probably want to. Copilot can turn your scattered answers into a clean FAQ that scales support.

Every team has a small set of questions that come up over and over — from new starters, from stakeholders, from customers, from other teams. Answering them individually is fine for the first few; by the tenth, you should have an FAQ. Copilot can build one from your existing answers (emails, chat threads, support tickets) in minutes.

Paste a batch of common questions and your existing answers. Ask Copilot to group them into categories, draft consistent answers in a clean format, and suggest a logical structure. What you get is a reusable FAQ document you can publish on a wiki, intranet page, or Teams tab. Suddenly the same question gets answered by the FAQ instead of by you, every time.

The bigger win is reducing repetitive low-value work. If you (or your team) spend 30 minutes a day answering the same five questions, that’s 130 hours a year. A well-built FAQ collapses that to almost zero. The time you save goes to the higher-value work that’s currently being crowded out.

When you’ll use this

• When you keep getting the same questions and want to stop answering them individually.
• When you’re building a self-service support resource for staff or customers.
• When onboarding new starters and want to give them a reference document.
• When you’ve built up a backlog of email answers that should become structured.

How to do it

1. Collect common questions (emails, chat, support tickets, meeting questions).
2. Ask Copilot to group questions into categories.
3. Request consistent answers in a clean format (short answer + more detail).
4. Review answers for accuracy and policy alignment.
5. Add links to authoritative sources where they help.
6. Publish in a place people will actually find (wiki, intranet, Teams tab).
7. Update regularly as new questions emerge.

Best practices

• Use real wording from users. The FAQ should match how people actually ask, not how you think they ask.
• Keep answers short by default. Provide a ‘more detail’ link for those who want depth.
• Link to authoritative sources. Policies, forms, official pages.
• Review the FAQ regularly. Outdated FAQs create more confusion than no FAQ.

Common mistakes

• Building an FAQ nobody knows exists. Promote it, link to it, refer questions to it.
• Letting answers go stale. The FAQ is a living document; review quarterly.
• Answering questions abstractly. Concrete examples beat principles for FAQ content.

Sample Copilot prompts

• Create an FAQ from these questions and draft clear answers: [paste].
• Group these FAQs into categories and suggest a good page structure: [paste].
• Rewrite these answers to be simpler and less technical: [paste].
• Turn this FAQ into a short internal article with headings: [paste].
• What questions are missing from this FAQ that I should anticipate?

↑ Back to top ↑ Back to list

Decisions land badly when the rationale isn’t clear. Copilot can help you explain why — in a way that builds buy-in instead of resistance.

Communicating a decision is harder than making it. You know the reasoning; your team doesn’t. The constraints that drove the decision are obvious to you but invisible to them. The result is decisions that look arbitrary from the outside, and resistance that the right communication would have prevented.

Copilot is excellent at structuring this kind of communication. Tell it the decision, the context, the constraints, and the impact. Ask for an explanation that includes rationale, what changes, what stays the same, and when it takes effect. Out comes a draft that frames the decision in terms your team can engage with — and that anticipates the questions they’ll ask.

The most useful pattern is to ask for two versions: an executive summary (for leadership) and a team-friendly explanation (for the people affected). Same decision, different framing. The executive summary is brief and outcome-focused. The team-friendly version acknowledges the human impact and explains the reasoning more carefully.

When you’ll use this

• When you’ve made a decision and need to communicate it to a team.
• When the decision is unpopular and you want to maximise buy-in.
• When you’re announcing a change and want to anticipate questions.
• When you need to explain a constraint that drove a decision the team disagrees with.

How to do it

1. State the decision, the context, and the constraints.
2. Ask Copilot to draft an explanation with rationale and impact.
3. Request two versions: executive summary and team-friendly explanation.
4. Add specific next steps and when changes take effect.
5. Anticipate likely questions and draft answers.
6. Share the message and invite questions in person or in chat.
7. Follow up if any questions arise after the announcement.

Best practices

• Be transparent about constraints. ‘We didn’t have a choice because of X’ is more credible than ‘we decided X’.
• Explain impact clearly. What changes, what stays the same, when it happens.
• Anticipate objections. If you can address them before they’re raised, the conversation is much smoother.
• Use consistent messaging across channels. Email, Teams, meeting — same framing.

Common mistakes

• Skipping the rationale. ‘Here’s the decision’ without ‘here’s why’ creates resentment.
• Burying the impact. What changes for the team should be unmissable.
• Avoiding the questions you know are coming. Better to address them upfront.

Sample Copilot prompts

• Draft a message explaining this decision to the team. Decision: [x]. Reasons: [y]. Impact: [z].
• Create two versions: executive summary and team-friendly explanation.
• List likely questions people will ask and suggested answers.
• Rewrite this message to be more empathetic while staying clear: [paste].
• How would I explain this decision to someone who disagrees with it?

↑ Back to top ↑ Back to list

Most project updates are reinvented every week. Copilot can build a reusable template once — and your team’s reporting becomes consistent forever.

Project status reporting is one of those tasks that everyone does and nobody does well. Each project has its own format. Each project manager invents their own structure. Each report takes longer than it should because the writer is figuring out what to include while writing. The fix is a template — and Copilot can build one in 5 minutes that you’ll use for years.

Tell Copilot the kind of projects you run, the audience for the status updates, and the cadence. Ask for a reusable template with the right sections (Status, Progress, Risks, Next steps, Help needed) and the right level of detail. Save the template somewhere durable, and use it for every status update going forward. The reporting cost drops dramatically because the structure is already done.

The deeper benefit is consistency. When every status report uses the same template, leadership can scan them quickly and compare across projects. Patterns become visible (which projects are slipping, which are stable, which need help). The template doesn’t just save time — it improves the quality of decisions made on top of project reporting.

When you’ll use this

• When you’re standardising project reporting across a team.
• When you want consistent status updates without reinventing each time.
• When you’ve inherited messy project reporting and want to clean it up.
• When leadership has asked for better visibility across projects.

How to do it

1. Decide the sections you need (Status, Progress, Risks, Next steps, Help needed).
2. Ask Copilot to draft a simple reusable template.
3. Request a short version (Teams) and a longer version (formal report).
4. Include guidance text inside the template (what to fill in for each section).
5. Save somewhere central for the team to reuse.
6. Update as your project rhythm and reporting needs evolve.
7. Build a habit: every project uses this template, every cycle.

Best practices

• Keep templates lightweight. If they’re too detailed, people skip them.
• Make ‘Help needed’ mandatory. It drives action and is what leadership most wants to see.
• Use consistent status definitions. Green/Amber/Red — defined the same way across projects.
• Date-stamp updates. Otherwise reports become timeless and harder to track.

Common mistakes

• Different templates for every project. Defeats the purpose of standardisation.
• Templates that are too long. 6-10 sections is a status report; 20 sections is a project plan.
• No guidance inside the template. Users guess what each section is for, fill in inconsistently.

Sample Copilot prompts

• Create a project status update template with sections: Status, Progress, Risks, Next steps, Help needed.
• Create a short Teams version (under 80 words) of the same template.
• Suggest a weekly project reporting cadence and what to include each week.
• Rewrite this template to be more executive-friendly: [paste].
• What sections should a status report have for a leadership audience vs a team audience?

↑ Back to top ↑ Back to list

Email threads sprawl. Decisions get buried. Copilot can collapse a 30-message thread into a clean summary — what was decided, what’s still open, what to do next.

Long email threads are one of the worst things in modern work. By message 15, nobody knows what was decided. By message 25, half the participants are arguing about points that were resolved 10 messages ago. By message 30, the original question has been completely forgotten. Copilot can summarise the whole thread in seconds: what was decided, what’s still open, what each person committed to.

The pattern that works is to ask for both the summary and the action: ‘summarise this thread, list decisions and open questions, and draft a reply that confirms the agreed next step.’ Copilot does all of it. You verify the facts, send the reply, and the thread is finally resolved. What would have been another five round-trips is done in one.

Where this is most valuable is when you’re catching up on a thread you weren’t part of from the start. Joining a 40-message thread on Monday morning is overwhelming. Copilot’s summary turns it into a 90-second briefing, and you’re up to speed without reading every message. Your time is preserved for the work, not the catch-up.

When you’ll use this

• When an email thread has gone on too long and decisions are getting lost.
• When you’ve been added to a thread mid-way and need to catch up.
• When you need to send a clean recap of a long discussion.
• When you want to close out a thread with confirmation of the agreed next step.

How to do it

1. Open the email thread or copy the relevant messages (remove sensitive details).
2. Ask Copilot to summarise into decisions, actions, and open questions.
3. Request a short reply draft based on the agreed next step.
4. Verify the details (names, dates, commitments) match the source.
5. Send the reply with a clear action and deadline.
6. Close the loop by restating what’s agreed.

Best practices

• Ask for structured output. What happened, where we are now, next step — three sections, easy to scan.
• Verify commitments against the source. Especially names and dates.
• Make replies outcome-focused. One action, one owner, one date.
• Close threads cleanly. ‘This is what we agreed; please confirm by Friday’ beats letting threads die.

Common mistakes

• Trusting summaries blindly for commitments. Verify what was actually said.
• Vague replies that don’t close the thread. Be specific about what happens next.
• Letting threads run beyond resolution. Once a decision is made, end the thread.

Sample Copilot prompts

• Summarise this email thread into decisions, actions, and open questions: [paste].
• What is the current status and what do we need to do next based on this thread?
• Draft a reply that confirms the agreed next step and asks for confirmation by [date].
• Rewrite this reply to be shorter and clearer: [paste].
• What’s the question that started this thread, and has it been answered?

↑ Back to top ↑ Back to list