Guides / Guide

Prompt templates that get a structured business document, not a wall of waffle

By Michael Shreeves · 9 June 2026 · AI & Copilot · 7 min read

Background

A policy document, a proposal, a briefing note and a one-page summary are four completely different documents that solve four completely different problems - who has to comply with what, why someone should approve a course of action, what a busy reader needs to know before a decision, and what happened in five sentences. Ask an AI tool for any of them with a one-line prompt ("write me a proposal for X") and it will produce something that reads fluently and has almost none of the structure that actually makes that document type work.

This isn't the model being lazy - it's answering the only question you actually asked, which was for prose about the topic, not for the specific document type with its specific job to do. A proposal without a clear "what I'm asking you to approve" section reads nicely and gets nobody's sign-off. A policy without a scope statement gets argued about the first time someone claims it doesn't apply to them. The document type has a job; a generic prompt doesn't tell the model what that job is.

The fix is the same one that works for diagrams and prompts generally: stop asking for prose about a topic and start asking for the specific document type's fixed shape, with your actual content dropped into it. The templates below are built the same way as the diagram prompt templates - one template per document type, each with the same five parts (role, context, inputs, task, constraints), reused rather than rebuilt from scratch every time.

Setup

The shape every template below follows:

  • Role - what kind of document-writer to be, because a policy writer and a business-case writer default to different things.
  • Context - what this document has to do and who reads it.
  • Inputs - the actual specifics in brackets, so nothing gets invented.
  • Task - the document's fixed sections, in order.
  • Constraints - the failure mode to rule out: waffle, missing the one section that actually matters for that document type, or a length nobody will read.

Policy or procedure document

For anything that has to tell someone what's required, what's allowed, and what happens if it isn't followed:

You're drafting a policy/procedure document that has to be enforceable,
not just descriptive.

Context: this will be published and referenced when someone asks "am I
allowed to..." or "what's the process for...". It needs to answer that
question without anyone having to interpret intent.

Inputs:
- Subject: [e.g. EXPENSE CLAIMS OVER £500]
- Who it applies to, and who it explicitly doesn't: [SCOPE]
- The actual rule(s): [STATE THEM PLAINLY - DON'T LET THE MODEL INFER
  THEM FROM A GENERAL PRINCIPLE]
- The process to follow, step by step: [LIST]
- What happens if it isn't followed: [CONSEQUENCE, OR "ESCALATES TO
  [ROLE]"]
- Who owns this policy and when it's next reviewed: [NAME/ROLE, DATE]

Task: Purpose (one sentence), Scope (who's in, who's out - explicitly),
Policy (the rule, stated as a rule not a suggestion), Process (numbered
steps), Non-compliance, Ownership and review date.

Constraints: every rule stated has to come from what I gave you - never
let the model add a "best practice" rule I didn't ask for. Plain language,
no legal-sounding padding. Flag anywhere the scope is ambiguous rather
than silently picking an interpretation.

Proposal or business case

For anything that needs someone to say yes to spending money, time, or approving a change in direction:

You're writing a proposal that has to get a specific decision made, not
just inform someone.

Context: the reader has to be able to say yes or no by the end of this
document without needing a follow-up meeting to understand what they're
being asked.

Inputs:
- What you're asking for approval of, in one sentence: [STATE IT]
- The problem this solves: [DESCRIBE, WITH A REAL EXAMPLE IF YOU HAVE ONE]
- Options considered, including "do nothing": [LIST, EVEN BRIEFLY]
- Cost and effort of your recommended option: [FIGURES/ESTIMATE]
- What you need from the reader, specifically: [e.g. BUDGET SIGN-OFF,
  A DECISION BY A DATE, ACCESS TO A TEAM]

Task: the ask (one sentence, first thing on the page), the problem,
options considered with why you're not recommending the others, your
recommendation with cost/effort, and exactly what you need from the
reader and by when.

Constraints: the ask has to be the first thing the reader sees, not the
last thing after three pages of context. Don't inflate the problem to
justify the ask - if the real benefit is modest, say so; an
over-claimed case is the one that gets picked apart in the room.

Briefing note

For getting someone up to speed before a meeting or a decision, fast:

You're writing a briefing note for someone who has five minutes before
they need to know this, not someone doing background reading.

Context: the reader needs to walk into a meeting or conversation able to
speak on this topic without having read anything else first.

Inputs:
- Topic and why it's relevant right now: [DESCRIBE]
- What the reader already knows (don't re-explain this): [DESCRIBE, OR
  "ASSUME NO PRIOR CONTEXT"]
- The key facts they need: [LIST]
- Any decision or position they'll be expected to have: [DESCRIBE, OR
  "INFORMATION ONLY, NO DECISION NEEDED"]

Task: one-sentence summary of what this is and why it matters now, three
to five key facts as bullet points (not paragraphs), and - only if
relevant - what decision or position the reader needs to be ready with.

Constraints: half a page, not two. No history the reader doesn't need for
the immediate conversation. If a fact is uncertain or unconfirmed, mark it
as such rather than stating it as settled.

One-page summary

For compressing something long (a report, a project, a quarter) into what a busy reader will actually get through:

You're compressing a longer document or body of work into a genuine
one-page summary - not a shorter version that's still three pages.

Inputs:
- The full document or the key points to draw from: [PASTE OR LIST]
- Reader and what they need to take away: [e.g. "SHOULD THEY KEEP
  FUNDING THIS", "SHOULD THEY BE WORRIED"]
- Anything that must be included regardless of length: [LIST, OR "NONE
  - USE JUDGEMENT"]

Task: a genuine single page - headline in one sentence, three to five
supporting points, and a clear "so what" line at the end stating what,
if anything, the reader needs to do or decide.

Constraints: if it doesn't fit on one page without shrinking the font,
cut content, don't shrink the font - ask which points to drop rather than
keeping everything at the cost of readability. No section headers that
just repeat the document type ("Summary", "Overview") - get straight to
content.

Edge Cases & BCP

  • A document that reads well is not the same as a document that's correct. Fluent prose makes a missing approval step or an unstated assumption just as easy to miss as a badly written one does - read every draft against your own inputs, not against how confident it sounds.
  • The model will happily fill a structural gap with something plausible if you leave a section thin. A policy with a vague scope, or a proposal with no real numbers, will get a plausible-sounding paragraph invented to fill the space rather than a flag that the input was missing. Give it "not yet decided" explicitly where that's true, rather than leaving a blank it can guess into.
  • A document built once from a template drifts the moment the underlying facts change and nobody updates it. A policy that references a rule that's since changed is worse than no policy - it's actively wrong and still looks authoritative. Note a review date on anything that will need revisiting, and actually revisit it.
  • Different readers need different documents from the same facts, and reusing one for both under-serves someone. A board briefing note and a proposal built from the same underlying facts should still be built as two separate documents from their own templates - don't hand a board the proposal's version and call it a briefing.
  • Long documents invite scope creep in a single prompt. Asking for the whole policy, proposal or report in one shot on a genuinely complex topic tends to produce something that's thin everywhere rather than solid throughout - build it section by section, approving each before moving to the next, for anything that actually matters.

← All guides