[NTTP]
Work & Meetings

How to write an internal proposal for a decision or spend

September 22, 2026 · 4 min read

A decision proposal is written to your own organisation, not to a customer. The goal is not to sell someone on working with you; it is to get a colleague or a manager to say yes to something you already believe is the right call, a purchase, a hire, a change in approach, or a chunk of your own time. Getting it approved usually comes down to structure more than persuasion: show the problem, show the thinking, then make the ask unmissable.

Why this is a different document from a sales proposal or a client quote

A sales proposal has to persuade a stranger who has other options and no reason yet to trust you. A client quote sets scope and price for work someone has already agreed to buy. An internal decision proposal starts from a different place: the reader already trusts you, and the request is really for a resource they control, time, budget, headcount, or approval. Treat it like a pitch and it reads as overblown for an audience that does not need selling to. Treat it like a plain, well reasoned case and it reads as credible, because that is what it actually is.

Show the options, but only if they are real

If you genuinely looked at more than one way to solve the problem, say so, and be honest about each option’s downsides as well as its upsides. A leader who sees that you weighed the alternatives, and can explain why you did not pick them, trusts your recommendation more than one that arrives with no visible thinking behind it. But do not manufacture options you never seriously considered just to look thorough. If there was genuinely one sensible path, say so and move straight to the recommendation and the ask. An invented second option that nobody would ever choose does not add credibility, it just pads the document and slows the reader down.

State the recommendation, do not hedge it

Internal documents that hedge, phrases like “it might possibly be worth considering” or “we could potentially look into”, read as unsure, and an unsure recommendation gives a busy decision maker no reason to act. State plainly which option you recommend and why, tied back to the problem you opened with, and defend that view in a sentence or two. Stating a clear view and inviting a decision is not the same as demanding one; a good decision maker still wants to see your reasoning, just not buried under qualifiers.

A missing number is a placeholder, never a guess

If you do not have an exact cost, a firm date, or a specific figure yet, say so with a bracketed placeholder such as [insert cost] rather than writing something that sounds plausible. A wrong number in a document that gets forwarded, quoted, and budgeted against causes real problems later, and it is far easier to fix a visible gap than a number nobody realised was invented. The same goes for the ask itself: be exact about what you want approved and by when, so the reader never has to guess what a yes actually commits them to.

Example

Problem: Our current file storage plan is nearly at capacity, and if we hit the limit mid-project uploads will start failing. Fixing this after it breaks will cost more in lost time than fixing it now. Options: We could upgrade our existing plan to the next tier ($40/month more, no migration needed), or move to a different provider entirely (potentially cheaper long term, but a multi-week migration with real risk of disruption). Recommendation: Upgrade the existing plan. It solves the immediate problem with no migration risk, and we can revisit a bigger platform change later if it still makes sense once we're not under time pressure. Ask: Approval to upgrade to the next tier at $40/month. If approved, I'll action it this week; if not, I need an alternative by Friday before we hit the current limit.

Common mistakes

← All guides