You have a 40-minute meeting transcript, a spreadsheet your director expects, and ten minutes until the next call. Copilot can help with that kind of backlog, provided you tell it which reading job to do. Summarizing reduces a source while preserving what matters. Analyzing uses the source to compare, calculate, classify, or recommend. In either case, you need to trace each claim back to the material and label whatever the material doesn't contain.
Summarizing and simplifying do different jobs
People say "make this shorter" when they mean four different things. Be specific:
- Summarize reduces the amount of information while keeping the important meaning: conclusions, decisions, risks, owners, dates, numbers.
- Simplify makes information easier to understand: plainer words, defined jargon, shorter sentences, without necessarily making it shorter.
"Give me the five most important points from this policy" is a summary. "Rewrite this policy for a new employee in plain language" is a simplification. "Explain this policy in six plain-language bullets, then list the actions employees must take" asks for both. If you only say "make this shorter," Copilot has to guess which one you meant, and it might drop the exact detail you needed.
The opposite mix-up happens too. If your director needs five decisions on one screen, "rewrite this for a new hire" may return a clearer document at nearly the original length. Name both the job and the output: "Explain this in six plain-language bullets, then list the actions employees must take." A simple distinction helps. Summarizing changes how much information remains. Simplifying changes how difficult it is to read.
Good summary prompts preserve the right details
A fluent summary can still be wrong. It can promote a proposal to a decision without you noticing, or lose an action item because nobody was assigned to it. The fix is to name what must survive compression and how to handle what's missing. A reusable shape:
Summarize [source] for [audience and purpose].
Focus on [decisions, risks, actions, owners, dates].
Return [format and length].
If an owner, date, or amount is missing, write "Not stated."
Do not turn a discussion or proposal into a decision.
Use only [named source].
Two rules do most of the work. First, keep incomplete actions visible: include every stated action even when its owner or due date is blank, and mark the blank "Not stated" rather than dropping the item. Second, don't let discussion become decision: if something was raised but not resolved, it belongs under "Open questions." A summary that hides an unassigned task or upgrades a maybe into a plan is worse than no summary, because it reads as confident.
What "the important meaning" includes depends on the source, so tune the preservation list to it. From a Teams meeting, keep decisions, actions, owners, and open questions distinct. From a Word document, keep the arguments, requirements, deadlines, and conclusions. From an Outlook thread, let later messages revise earlier ones: a proposal in the first email shouldn't outrank a decision in the last. In every case, preserve the qualifiers: "proposed," "under review," "subject to approval," "before release." Those small words carry the difference between a plan and a wish, and a summary that drops them changes the meaning while still looking faithful to anyone who didn't read the original.
Questions retrieve facts, analysis combines them
The second pattern is analysis, and it starts by noticing that "ask Copilot about this data" hides two very different tasks. A question retrieves or explains one stated fact. An analysis combines information (comparing, calculating, classifying, or recommending) to reach a conclusion the source doesn't state outright.
The question reads a cell. The analysis pulls two columns, does arithmetic, compares the results, and draws a conclusion. Naming which one you want, and defining the calculation, separates a number you can trust from a number you have to re-check by hand anyway.
An analysis prompt earns trust by being checkable. Define the formula, ask for the source values, and require the arithmetic to be shown, then reproduce one row yourself. Just as important, keep three categories apart:
- Evidence: what the source explicitly states ("manager approval delay").
- Inference: what you derived from it ("West has a 13-point gap").
- Missing information: what the task needs but the source lacks (no owner column, so "Not stated").
Vague requests like "find the trends" invite Copilot to invent a comparison, for instance reporting month-over-month movement when you wanted actual-versus-target. Pin the math down: "Calculate variance as Actual minus Target for each row. Show the arithmetic. Do not compare one row to another." Then define ties and blanks in advance ("if two rows tie, report both. If a value is missing, mark it 'Not calculable' and exclude it from the ranking") so Copilot never invents a tie-breaker on its own.
Give Copilot six months of Target and Actual figures. Define variance as Actual minus Target for each row, ask for the two largest shortfalls, and require the arithmetic. You can check April's "118 − 130 = −12" and February's "103 − 110 = −7" yourself. If it says "April fell versus March," it switched to month-over-month. Re-prompt: "Recalculate using only Actual minus Target for each row. Do not compare one month to another."
Conflicting sources need a traceable resolution
Real work spans a planning note and a later chat message, and they don't always match. Two judgments keep you honest here, and they're separate. A conflict exists only when two sources make incompatible assertions about the same claim: different starting regions, opposite approval statuses. A later message merely mentioning the topic, staying silent, or floating a proposal is not a conflict.
Supersession, deciding the later statement replaces the earlier one, needs more than recency. The newest message is not automatically right. Accept it as superseding only when the evidence establishes both its approval status ("I approve replacing South with West") and the author's authority to make that change (the charter says the sponsor may approve region changes). If either is missing, report the conflict but keep the original decision, and flag that authority isn't established. This one habit stops a specific failure: a confident chat message overriding an approved plan it had no standing to change.
The check runs as a short sequence you can memorize. First, name the shared claim: the starting regions. Second, confirm the values are incompatible, for example North-and-South versus North-and-West. Two mentions of the same topic alone don't qualify. Third, check approval: does the later message explicitly say "approve"? Fourth, check authority: does any source establish that this author may make this change? Only when both approval and authority pass do you accept the update. Otherwise you record the conflict and hold the original. Keep every unrelated claim tied to its own evidence, too: an approved change to regions doesn't re-open the legal review or the owners nobody touched.
