How do I structure a proposal so a decision-maker can approve, reject, or revise it easily?
Quick answer
Put the decision you need near the beginning, then explain the problem, your proposed approach, alternatives, uncertainties, and the next step. Make it easy to respond by stating what approval would authorize and by inviting a clear choice: approve, reject, or request revisions. Use placeholders for unknowns and distinguish facts from assumptions so the decision-maker can judge the proposal without treating uncertain claims as settled.
The question, the details, the next step.
I need to write a proposal for a decision-maker. How do I make it easy for them to approve, reject, or revise it instead of just reading a long pitch?
Treat the proposal as a decision aid, not an argument that approval is inevitable. Start by naming the decision and the response you need. Then give enough context to evaluate it: the problem, your proposed approach, alternatives, uncertainties, and a practical next step.
A useful outline is:
- Decision requested
- Problem and why it needs attention
- Proposed approach and what it includes
- Alternatives considered
- Assumptions, uncertainties, and constraints
- Next step and requested response
Keep the main proposal understandable on its own. Put supporting detail after the decision-relevant points, not in front of them.
What belongs in the opening, and how much should I explain the problem before presenting the solution? I don't want to sound pushy.
State the decision plainly, without framing agreement as the only reasonable choice. Specify what approval would authorize, and include who needs to respond or by when only if you know. If you do not know, use a placeholder rather than inventing a deadline.
For example, assuming this is a proposal to try a new meeting format: “Decision requested: approve a [length]-week trial of a weekly [meeting format] for [team or group], or suggest revisions to its length or scope. Please respond by [date, if applicable].” This makes the request concrete while leaving room to decline or adjust it.
Explain enough of the problem for the reader to understand why a decision is needed: what is happening, whom or what it affects, and what gap the proposal addresses. Separate observed information from interpretation. Label assumptions and identify information that is missing. Then describe the proposed approach in terms the reader can assess: scope, intended result, people involved if known, and dependencies or limits. Avoid promising an outcome you cannot establish.
Should I include alternatives even if I think my recommendation is best?
Include meaningful alternatives when the decision-maker has a real choice. Briefly describe options they could actually choose, including your proposal and, where relevant, doing nothing for now. Compare them using the same considerations, such as scope, effort, timing, or fit with the stated need. Do not use a straw alternative just to make your recommendation look better.
For the meeting-format example, you might write: “Option A: run the proposed trial. Option B: keep the current format. Option C: revise the meeting schedule without changing its format.” These are illustrative possibilities, not recommendations for a particular workplace. Note what you do not yet know, such as the time commitment or participant availability.
Can you give me a copyable outline that also makes revision straightforward?
Use this fill-in template. Replace brackets with information you can support, and remove sections that genuinely do not apply.
Decision requested: Please [approve / reject / revise] [specific proposal]. Approval would authorize [scope or action]. Response requested by [date, if applicable].
Problem: [What is happening? What need does this create?]
Proposed approach: [What would be done, for whom, and within what scope?] The intended result is [result], not a guaranteed outcome.
Alternatives: [Option 1 and its trade-offs]; [Option 2 and its trade-offs]; [another reasonable option, including deferring if relevant].
Uncertainties and constraints: We know [supported information]. We are assuming [assumption]. We still need to confirm [open question]. Relevant limits include [constraint].
Next step: If approved, [first action and responsible person, if known]. If revisions are needed, please indicate [decision point that needs changing]. If rejected, [whether a different option or no action is preferred].
End with a neutral response path: “Please indicate whether you approve the proposal, prefer one of the alternatives, or want revisions.” Make follow-up actions conditional and use them only if they match the actual situation. The outline helps someone respond or identify what to change; it does not establish that the proposal is feasible.
A practical checklist
Put the requested decision and what approval authorizes near the beginning.
Explain the problem using information you can support; label assumptions and unknowns.
Describe the proposed approach with a clear scope and realistic limits.
Include meaningful alternatives and compare them using consistent considerations.
Give a next step for approval, revision, and rejection, using placeholders for unknown details.
A few more useful answers
Should I include a budget or timeline if I do not know the figures yet?
Do not guess. Mark the figures as [to be confirmed] and say whether the decision can be made before they are known or depends on confirming them.
How many alternatives should I present?
Include the options that are genuinely available and relevant to the decision. A small, clear set is easier to compare than a long list of minor variations.
What if the decision-maker asks for revisions?
Ask which decision point needs to change, such as scope, timing, or approach, then revise that part and make the changes visible. Avoid treating a request for revision as approval.