Drafting a Real Document in Word With Copilot, Start to Finish
Most people's first attempt at using Copilot in Word looks like this: they type "write a remote work policy" into the chat pane, get back three paragraphs of generic HR boilerplate, and conclude Copilot isn't very good at real documents. It isn't that Copilot can't do it. It's that a one-line prompt for a multi-page document gives it nothing to work from except whatever's most common on the internet, which is exactly what generic boilerplate is.
A real document, drafted well, goes through the same stages whether a person or Copilot writes the first pass: an outline, a rough draft against that outline, then a review and tightening pass. Skipping straight to "write the whole thing" skips the stage where most of the actual thinking happens.
Note
This walkthrough assumes you're already comfortable with the Copilot basics in Word. If not, the Complete Beginner's Guide to Copilot covers account setup and the chat pane. And if you haven't seen how agent mode changed what Copilot can do in a single request, that overview is worth reading first, since it's what makes this whole workflow possible in one document instead of several back-and-forth passes.
The document: a remote work policy nobody's written down
Here's the scenario for this walkthrough. A 40-person company has been operating with an informal remote work arrangement for two years: people mostly know the unwritten rules, but a new hire just asked a question nobody could answer consistently, and leadership wants an actual policy document. You have the rough shape in your head. You don't have three hours to write it from a blank page.
Step one: build the outline before you build the prose
Open the document (blank or with whatever rough notes you already have), open Copilot, and ask for structure first, not content.
I need to draft a remote work policy for a 40-person software company. We currently have no written policy, just informal norms: most people work from home 3 days a week, core hours are 10am-3pm in whatever timezone they're in, and expenses for home office equipment are reimbursed up to a set amount with manager approval. Before writing anything, give me a proposed section outline for this policy, with a one-sentence description of what each section covers.
”This does two things a direct "write the policy" request doesn't. It surfaces the actual shape of the document before you've committed to any wording, so you can catch a missing section (say, what happens for roles that can't be remote at all, like on-site support staff) while it's still a bullet point instead of after it's a paragraph you have to unwind. And it gives Copilot the specific facts of your situation instead of letting it default to whatever a generic remote work policy usually contains.
- 1
Review the outline like a table of contents
Read it as a list of decisions, not prose. Cut a section that doesn't apply to your company, add one that's missing, and reorder anything that reads oddly out of sequence, all before a single paragraph gets written.
- 2
Approve it explicitly
Tell Copilot which sections to keep, drop, or add. This is the cheapest point in the whole process to make a structural change, so it's worth taking seriously even though it feels like it's slowing you down.
- 3
Ask for the highest-stakes section first
Once the outline is settled, don't ask for the whole document at once. Ask for the section most likely to cause disagreement, here, probably eligibility and core hours, so you can react to the part that actually matters before the rest gets built around it.
Step two: draft one section at a time
With the outline approved, ask for the section that carries the most risk of being wrong.
Draft the "Eligibility and Core Hours" section based on the outline above. Roles eligible for remote work: engineering, design, marketing, and operations. Not eligible: on-site IT support and office administration, who need to be physically present. Core hours are 10am-3pm in the employee's local timezone, with the expectation that meetings get scheduled inside that window when possible. Tone: clear and matter-of-fact, like an actual company policy, not a memo. Keep it to about 200 words.
”Notice the prompt restates the specific facts even though they were mentioned in the outline request. Copilot holds context within the conversation, but restating the exact numbers and role names for the section that's actually being drafted removes any chance it drifts toward a plausible-sounding but wrong detail, like assuming core hours are in company time rather than the employee's own.
Here's a representative version of what that prompt actually produces, dropped into the document:
Word
Drafted section, illustrated
Eligibility and Core Hours
Employees in engineering, design, marketing, and operations are eligible for remote work under this policy. On-site IT support and office administration roles are not eligible, since these roles require physical presence to perform their core functions.
Core hours are 10:00 AM to 3:00 PM in each employee's local time zone. Teams should schedule meetings inside this window whenever possible.
Note: an employee whose role changes to include an on-site requirement should discuss eligibility with their manager before the change takes effect.
- 1
The heading matches the approved outline exactly: Copilot used the section name from the outline step word for word instead of rephrasing it, so the finished document and the approved plan still line up when someone checks them side by side.
- 2
The tone stays matter-of-fact: Short, declarative sentences instead of a warmer, hedging tone, because the prompt specifically asked for something that reads like an actual policy, not a memo.
- 3
A boxed note for the edge case: Rather than burying the role-change scenario inside the eligibility paragraph, this version sets it off as its own note, which is exactly the kind of edge case a reader skims past when it's just one more sentence in a block of text. Copilot's formatting choices vary from run to run, so treat this as one possible outcome, not a guarantee.
That third choice is worth noticing on its own. Nothing in the prompt asked for a separate note, and Copilot won't always make that call, but here it made a structural decision about what deserved visual separation, and it happened to be the right one: an edge case about changing roles is precisely the kind of detail that gets missed later if it's not set apart from the main rule.
Once that section reads correctly, move to the next one the same way, one section per request, rather than asking for the remaining four sections all at once. A single big request tends to produce four thinner sections instead of one solid one; that's the same shallow-vs-deep tradeoff that shows up any time you bundle unrelated asks into one message.
Why this worked: the prompt gave Copilot three things at once, the exact facts, an explicit tone instruction, and a length limit, which is what let it make a confident structural call (the callout) instead of a generic one. A prompt missing any of those three tends to produce a technically correct paragraph that still reads like it could belong to a different company's policy.
Next move: once this section is approved, the natural next request isn't "draft the rest of the document." It's the same single-section prompt pattern, repeated for whichever section carries the next-highest amount of risk, here, probably the equipment reimbursement section, since that's the other place a specific dollar figure or approval step could get drafted wrong with the same fluent confidence.
Step three: let agent mode assemble and format the whole document
Once every section is drafted and approved individually, this is where agent mode earns its keep. Instead of manually copying each drafted section into a clean document and formatting it by hand, ask Copilot to assemble it.
Combine all the sections we've drafted into one formatted policy document. Add a title page with "Remote Work Policy" and today's date, a numbered heading for each section matching the approved outline, and a one-paragraph introduction at the top explaining who this policy applies to. Use our standard heading style throughout.
”Agent mode handles the structural work in one pass: the title page, the numbered headings, consistent styling, and the introduction, instead of you doing that formatting by hand after the fact. This is exactly the kind of multi-step, whole-document action that agent mode was built for, as opposed to a single suggested sentence.
Step four: the review pass that actually matters
Read it as the person who'll enforce it, not the person who wrote it
A remote work policy reads fine in isolation and then falls apart the first time someone asks an edge-case question: what happens to a new hire during their first 90 days, or someone who moves to a different timezone mid-year. Read the finished draft specifically hunting for the situations it doesn't address, not just whether the prose sounds right.
This is the pass a person has to do, not Copilot. Ask a colleague, ideally someone in HR or management who'll actually have to apply this policy, to read it for gaps before it goes out. Copilot is good at producing a document that reads as complete. Whether it's actually complete for your specific company is a judgment call that needs a human who knows the company.
What this workflow gets you that a single prompt doesn't
The difference between "write a remote work policy" and this four-step process isn't really about Copilot's writing quality; a single big prompt and a section-by-section build can both produce grammatically fine paragraphs. The difference is that the section-by-section version forces the actual decisions, who's eligible, what the core hours mean, what happens at the edges, to surface early, while they're still cheap to change. A document built the fast way tends to look finished and then generate three follow-up questions the week after it's published, because nobody actually decided those edge cases; Copilot just wrote around them convincingly.