Proposal One-Pager

---
name: proposal-one-pager
description: Turns a rough idea into a one-page proposal a decision-maker can approve or reject without a meeting: the problem in their terms, the solution in plain words, the honest cost, the expected return, and one specific ask with a date. Use to pitch a project, a purchase, a hire, a pilot, or a change to whoever controls the budget.
---

# Proposal One-Pager

You write the page that gets a decision. Not the page that explains the idea well, and not the page that wins an argument. The test is whether someone who was not in your head can say yes, no, or "tell me one more thing" without scheduling anything.

## Workflow

The order matters. Writing the solution before you know the reader produces a page about your idea rather than about their problem.

1. **Take the six inputs.** Ask for them together, not one at a time.
2. **Name the decision-maker and their currency.** Money, time, risk, growth, or reputation. Pick one.
3. **Write the problem in their terms,** with a cost attached.
4. **Write the solution as the obvious next move,** in plain words.
5. **Cost it honestly,** including the parts that are inconvenient.
6. **State the expected return,** marking every estimate as one.
7. **Write one ask, with a date.**
8. **Cut to one page.** Trim detail, never sections.

```text
Proposal checklist
[ ] Six inputs collected: idea, problem, who feels it, reader, cost, ask
[ ] Reader's currency identified and the page written in it
[ ] Problem has a number or a named consequence attached
[ ] Solution stated in one plain sentence before any detail
[ ] Cost includes money, time, and the ongoing burden after launch
[ ] Every estimate labelled as an estimate with its basis
[ ] One risk stated honestly in one line
[ ] The ask is a single decision with a date
[ ] Fits on one page
```

## Step 1: the six inputs

Ask for all six in one message:

- **The idea,** in their own words. Rough is fine.
- **The problem it solves,** and who currently feels it.
- **The reader:** who approves this, and what they are measured on.
- **What it costs:** money, hours, people, in rough numbers.
- **What they are asking for:** approval, budget, a pilot, a decision by a date.
- **What happens if nobody does anything.** This is the one people forget, and it is usually the strongest paragraph on the page.

If cost figures are missing, ask for a rough estimate rather than proceeding without one. A proposal with no cost is a wish, and readers treat it as one.

## Step 2: the reader's currency

Every decision-maker converts your proposal into one unit before they judge it. Find out which.

| Currency | What the problem paragraph should lead with |
|---|---|
| Money | The amount being lost or spent now, per month or per year |
| Time | Hours going somewhere they should not, and whose hours |
| Risk | What breaks, who finds out, and how bad the day is |
| Growth | The deals, users or capacity the current situation is blocking |
| Reputation | What a customer, regulator or candidate currently sees |

Writing a time-saving proposal for a risk-focused reader is the most common way a good idea fails. Same facts, wrong unit.

If the user does not know which, ask what their reader complained about most recently. That is the currency.

## Step 3: the problem paragraph

Two to three sentences, and the hardest part of the page. It must contain:

1. **What is wrong,** stated as a fact rather than a feeling.
2. **A cost,** in the reader's currency, with a number if one exists.
3. **The trend or the trigger** if there is one, because a problem that is getting worse is a different decision from one that is stable.

> We lose about three hours a week arranging meetings by email. Across the six of us that is roughly 150 hours a year, and it has grown since we added the two contractors.

Do not open with the idea. A reader who has not felt the problem will read the solution as a preference.

Do not exaggerate. One inflated number found is enough to make a reader distrust the whole page, including the accurate parts.

## Step 4: the solution

Two to four sentences. The first one must be a complete answer on its own, because some readers will read only that.

> Buy a shared scheduling tool that lets people book directly against our calendars.

Then the detail that makes it real: what changes, who does the work, how long it takes to be running. Plain nouns, no product-marketing vocabulary, no phrases the reader would have to look up.

Alternatives considered belong here in one line, if there are obvious ones: "We tried a shared calendar block in March; it failed because external people cannot see it." This closes off the reader's first objection before they raise it.

## Step 5: costing it honestly

Three parts, and the third is the one people leave out:

- **Money.** The price, stated as it will appear on an invoice. Monthly and annual if it recurs.
- **Effort to set up.** Whose hours, roughly how many.
- **The ongoing burden.** Who maintains it, who administers it, what happens when the person who set it up leaves.

Hidden costs surface later and cost more than the money did. A proposal that names its own inconvenient parts reads as trustworthy, and trustworthy is what gets a yes.

State one genuine risk in a single line. Not a fake risk you can immediately dismiss. A real one, with what you would do about it.

## Step 6: the return

What the reader gets. Real numbers where they exist, and every estimate labelled with its basis:

> Estimated 100 hours a year returned to the team. Based on the three hours a week we currently spend, assuming the tool removes two of them.

Never present an estimate as a measurement. "Saves 150 hours" and "estimated 100 hours, based on X" are read completely differently, and the second one survives scrutiny.

If the return is not quantifiable, say so and describe what changes concretely instead. "Customers stop receiving two different answers from two people" is a real benefit without a number attached.

## Step 7: the ask

One decision, one date, one named person.

- Works: "Approve a one-month trial at £40 a month. I will report time saved on 30 April."
- Fails: "Support this initiative." "Let me know your thoughts." "Approve budget for tooling."

The ask should be the smallest thing that lets the work start. A pilot is easier to approve than a rollout, and a pilot that reports back on a date is easier still, because it gives the reader a second decision point rather than a commitment.

## The page

```text
[Title: the idea in one plain line]

The problem
[2-3 sentences. What is wrong, what it costs, whether it is growing.]

What I propose
[2-4 sentences. The solution in the first one. Alternatives ruled out, if any.]

What it costs
- Money: [amount, and whether it recurs]
- Setup: [whose hours, how many]
- Ongoing: [who owns it afterwards]
- Risk: [one real one, and what you would do]

What we get
[The return. Estimates labelled as estimates, with their basis.]

The ask
[One decision, one date, one person.]
```

## Example

**Situation:** a six-person team wants a scheduling tool. Reader is an operations director measured on cost per head.

> **A shared scheduling tool for the support team**
>
> **The problem.** We lose about three hours a week arranging meetings by email, mostly with external customers who cannot see our calendars. Across six people that is roughly 150 hours a year. It has got worse since the two contractors joined in March, because they are in a different time zone.
>
> **What I propose.** Buy a shared scheduling tool so customers book directly against our real availability. Setup is one afternoon and the calendars we already use stay as they are. We tried blocking time in a shared calendar in March; it failed because external people cannot see it.
>
> **What it costs.**
> - Money: £40 a month for six seats, £480 a year.
> - Setup: one afternoon of my time.
> - Ongoing: I own the account. If I leave, it transfers with the team inbox.
> - Risk: customers may book badly timed slots. We can set booking rules, and I would rather fix that than keep the email back-and-forth.
>
> **What we get.** Estimated 100 hours a year returned to the team, based on removing two of the three hours we currently spend each week. At our loaded rate that is worth roughly £3,000 against a £480 cost.
>
> **The ask.** Approve a one-month trial at £40. I will report actual hours saved on 30 April, and cancel it myself if the number is not there.

Note what the page does: it leads with the reader's currency, it names the failed previous attempt before the reader can, it labels the 100 hours as an estimate with a basis, it states a risk the author cannot dismiss, and it asks for a trial rather than a commitment.

## Rules

- One page. If it runs long, cut detail, never a section. A proposal missing its cost section reads as a proposal hiding its cost.
- Never invent a number. Every estimate is labelled, with the assumption it rests on.
- State one real risk. A page with no downside reads as a sales pitch.
- Plain words only. No "synergy", no "drives value", no "strategic enabler". If the reader would not use the word, do not use it.
- The ask must be specific and doable this week.
- Do not bury the cost. A reader who has to hunt for it assumes it is bad.
- Write in the reader's currency even when yours is different.

## Edge cases

- **The user has no numbers at all.** Do not proceed silently. Ask for the roughest possible estimate, label it clearly as rough, and say what would firm it up. "Roughly three hours a week, from asking the team" is honest and usable.
- **The real cost is political,** not financial. Someone loses territory, or a team's process changes. Name it in one line, because the reader already knows and will trust the page more for it.
- **The idea is not ready.** The problem is real but the solution is a guess. Change the ask to the smallest investigative step: two weeks to scope it, a conversation with two customers.
- **The reader has already said no once.** Lead with what has changed since. If nothing has changed, say so plainly and consider whether the page is worth sending.
- **Multiple decision-makers with different currencies.** Write for the one who can say no. Add a line for the others rather than averaging the whole page into something aimed at nobody.
- **The proposal competes with something the reader owns.** Say so directly and early. Discovering it themselves halfway down is far worse.
- **The user wants to include a slide deck's worth of detail.** Put the extra in an appendix that is clearly optional, and keep the page complete without it.

## Files

- `references/examples.md` - three complete one-pagers for very different asks: a software purchase, a hire, and a process change with no budget attached. Read the hire one to see how a page works when the return cannot be quantified.
- `references/template.md` - the fill-in page, the six input questions as a copyable block, phrasing for asks and estimates, and a pre-send checklist. Read it at step 1 and again before delivering.

# Worked one-pagers

Three finished pages for three different kinds of ask. The second one is the important one, because it shows what to do when the benefit cannot be turned into a number.

## Contents

- [Example 1: a software purchase](#example-1-a-software-purchase)
- [Example 2: a hire, where the return has no number](#example-2-a-hire-where-the-return-has-no-number)
- [Example 3: a process change with no budget](#example-3-a-process-change-with-no-budget)
- [What the three pages have in common](#what-the-three-pages-have-in-common)

---

## Example 1: a software purchase

### Inputs

- **Idea:** buy an error-monitoring service.
- **Problem:** we find out about production errors when a customer emails us.
- **Reader:** engineering director, measured on uptime and on customer-reported incidents.
- **Cost:** roughly £180 a month for the tier we need.
- **Ask:** approve a three-month trial.
- **If nobody acts:** we keep learning about outages from customers, on their timeline.

**Currency:** risk. The director's most recent complaint was about a Friday outage nobody noticed until Monday.

### The page

> **Error monitoring for the production API**
>
> **The problem.** We currently find out about production errors when a customer emails support. In the last quarter that happened four times, and the longest gap between an error starting and us knowing about it was 51 hours, over a weekend. Two of those four became escalations because the customer had already told their own users.
>
> **What I propose.** Buy an error-monitoring service that alerts us the moment error rates cross a threshold. It sits alongside the existing logging and needs one library added to the API. No change to how we deploy. We looked at building alerting on top of our existing logs; it is roughly two weeks of work and someone then owns it forever.
>
> **What it costs.**
> - Money: £180 a month, £2,160 a year, cancellable monthly.
> - Setup: one day of one engineer's time to add the library and set thresholds.
> - Ongoing: the on-call rota owns the alerts. No new admin burden.
> - Risk: noisy alerts train people to ignore them. I would start with two alerts only and add more as we learn what is worth waking up for.
>
> **What we get.** Detection in minutes rather than hours. On last quarter's four incidents, we estimate three would have been caught before any customer noticed, based on when the error rates actually started in our logs. The fourth was a data problem no monitoring would have caught.
>
> **The ask.** Approve £180 a month for a three-month trial. I will report on 31 October with the number of incidents we caught first, and cancel it myself if that number is zero.

**Why the page is shaped this way:** the currency is risk, so the problem paragraph leads with the 51-hour gap rather than with engineering effort. The return uses the reader's own incidents rather than a vendor's claim, and it admits that one of the four would not have been caught, which is what makes the other three believable. The alert-noise risk is real and the author cannot dismiss it, so it is stated with a mitigation instead.

---

## Example 2: a hire, where the return has no number

### Inputs

- **Idea:** hire a second technical writer.
- **Problem:** documentation is a year behind the product and support answers the same questions repeatedly.
- **Reader:** VP of product, measured on release velocity and customer satisfaction.
- **Cost:** roughly £55k plus overhead.
- **Ask:** approve the headcount for the next planning round.
- **If nobody acts:** engineers keep writing docs badly and slowly, and support keeps absorbing it.

**Currency:** growth, specifically release velocity. The VP's recent complaint was about releases slipping in the final week.

### The page

> **A second technical writer**
>
> **The problem.** Documentation is roughly a year behind the product. Three of the last five releases slipped in their final week, and in each case docs were on the critical path, written by the engineer who built the feature. Support currently answers about 40 tickets a month that an accurate docs page would have answered, which is roughly a quarter of their volume.
>
> **What I propose.** Hire a second technical writer, focused on release documentation rather than the existing backlog. Our current writer keeps the reference docs; the new person joins release teams from the start, so docs land with the feature rather than after it. The alternative we have been running for two years is engineers writing their own docs in the last week, which is what is causing the slips.
>
> **What it costs.**
> - Money: about £55k plus overhead, permanent.
> - Setup: six to eight weeks of ramp before they are contributing to a release.
> - Ongoing: my time to manage them. Our existing writer would mentor for the first month.
> - Risk: one hire does not fix a year-long backlog. This buys us current documentation, not caught-up documentation, and I would rather be honest about that now than promise both.
>
> **What we get.** I cannot put a reliable number on this, so here is what changes concretely. Release documentation stops being on the critical path in the final week, which is where three of our last five slips happened. Engineers get back roughly two days per release each. Support's repeated-question volume, currently about 40 tickets a month, should fall, though I would not guess by how much until we see which pages get written first.
>
> **The ask.** Approve one headcount in the next planning round, starting Q3. If you want a smaller first step, I will run a contractor for one release cycle and bring you the before-and-after on slip timing.

**Why the page is shaped this way:** the return section says plainly that there is no number, then describes what changes in concrete terms instead. That is more persuasive than a fabricated productivity figure, and far more survivable in a meeting. The risk line refuses the obvious overclaim, which is that one hire clears the backlog. The ask offers a smaller alternative, so a reader who is not ready for permanent headcount has somewhere to land other than no.

---

## Example 3: a process change with no budget

### Inputs

- **Idea:** stop taking support requests in direct messages; route everything through one channel.
- **Problem:** requests get lost, and the same three people absorb everything.
- **Reader:** head of operations, measured on team retention and on response times.
- **Cost:** no money. Some annoyance, and about a week of people forgetting.
- **Ask:** agreement to run it for six weeks starting the first of next month.
- **If nobody acts:** the three people carrying it are the three most likely to leave.

**Currency:** risk, specifically people risk.

### The page

> **Moving support requests out of direct messages**
>
> **The problem.** Support requests currently arrive as direct messages to whoever the requester knows best. In practice that means three people receive about 70% of everything, including at weekends. Two of those three raised workload in their last review. Nothing is tracked, so we cannot say how long anything takes, and requests that arrive while someone is on leave are simply lost.
>
> **What I propose.** One channel for all requests. Anyone can pick one up; the person who picks it up says so in the thread. Direct messages get a one-line reply pointing at the channel. No tool to buy, no process document, no forms. We tried a shared inbox in 2024 and it failed because it lived outside the tool people already have open all day.
>
> **What it costs.**
> - Money: none.
> - Setup: an hour to create the channel and write the pinned message.
> - Ongoing: about a week of gently redirecting people who forget, mostly falling on me.
> - Risk: senior people will keep sending direct messages, because it works for them. If the three of us do not redirect them consistently, this fails in a fortnight. I would rather name that now than discover it in week three.
>
> **What we get.** Work becomes visible, so we can finally say how many requests we get and how long they take. The load spreads past three people. Nothing is lost while someone is on leave. No number attached to any of this yet, which is part of the point.
>
> **The ask.** Agree to run this for six weeks from 1 March. On 15 April I will bring you the request count, the median response time, and the distribution across the team. If it has not spread the load, we stop.

**Why the page is shaped this way:** with no money involved the cost section could have been skipped, and skipping it would have been a mistake. The real cost is social, and naming it ("senior people will keep sending direct messages") is what makes the page credible to a reader who has watched process changes fail before. The return openly says there is no number yet and turns that into the reason for the six-week trial.

---

## What the three pages have in common

1. The problem paragraph is written in the reader's currency, and each one leads with the specific thing that reader last complained about.
2. Every page names the previous attempt that failed and why. Readers reach for that objection first, so answering it before they raise it is worth two paragraphs of argument.
3. Every risk stated is one the author cannot immediately dismiss. Alert noise, a backlog that stays, senior people ignoring the new channel. A page with a strawman risk reads worse than a page with none.
4. Two of the three refused to invent a return figure and described concrete change instead. Neither is weaker for it.
5. Every ask is one decision, with a date, and a reporting-back commitment attached. Each one also offers the author's own exit: cancel it, stop it, bring the numbers back. That is what makes a yes cheap.

# The page, and the words that fill it

Everything you need at the desk: the questions to ask, the blank page, phrasing that survives scrutiny, and the read-through before it goes.

## Contents

- [The six questions, as one message](#the-six-questions-as-one-message)
- [The blank page](#the-blank-page)
- [Problem openers by currency](#problem-openers-by-currency)
- [Stating estimates honestly](#stating-estimates-honestly)
- [Asks that get answered](#asks-that-get-answered)
- [Words to cut](#words-to-cut)
- [The pre-send read-through](#the-pre-send-read-through)

---

## The six questions, as one message

Send all six together. Asking one at a time turns a ten-minute job into a conversation.

```text
Six things and I can draft the page:

1. The idea, in your own words. Rough is fine.
2. What problem does it solve, and who currently feels it?
3. Who approves this, and what are they measured on?
4. Roughly what does it cost - money, hours, people?
5. What exactly are you asking them to do?
6. What happens if nobody does anything?
```

Question six produces the strongest paragraph on the page and the one people never volunteer.

## The blank page

```text
[Title: the idea in one plain line. Not a project name.]

The problem
[2-3 sentences. What is wrong, stated as fact. What it costs, in the reader's
currency, with a number if one exists. Whether it is getting worse.]

What I propose
[First sentence: the solution, complete on its own. Then 1-3 sentences of what
changes, who does it, how long until it is running. One line on the obvious
alternative and why it does not work.]

What it costs
- Money: [amount; monthly and annual if recurring]
- Setup: [whose hours, roughly how many]
- Ongoing: [who owns it afterwards, and what happens if they leave]
- Risk: [one real risk, and what you would do about it]

What we get
[The return. Numbers where real, estimates labelled with their basis. If it
cannot be quantified, say so and describe what concretely changes.]

The ask
[One decision. One date. One named person. Plus what you will report back and when.]
```

## Problem openers by currency

Match the opener to what the reader is measured on.

| Currency | Opener that lands |
|---|---|
| Money | "We are currently spending £X a month on [thing], and it is rising." |
| Money | "This costs us roughly £X a year in [specific waste]." |
| Time | "We lose about [n] hours a week to [thing]. Across the team that is [n] a year." |
| Time | "Three of the last five releases slipped in their final week, and [thing] was on the critical path each time." |
| Risk | "In the last quarter this happened [n] times. The worst gap was [duration]." |
| Risk | "Two of the three people carrying this raised workload in their last review." |
| Growth | "We have turned away [n] customers this year because [thing]." |
| Growth | "[Thing] is the reason we cannot take on more than [n] accounts." |
| Reputation | "Customers currently see [specific thing] when they [action]." |

Every one of these is checkable. That is the point. An opener the reader can verify buys you the rest of the page.

## Stating estimates honestly

| Do not write | Write |
|---|---|
| "Saves 150 hours a year" | "Estimated 100 hours a year, based on removing two of the three hours we currently spend weekly" |
| "Significant cost reduction" | "About £480 a year at current volumes" |
| "Improves customer satisfaction" | "Customers stop receiving two different answers from two people" |
| "10x faster" | "Detection in minutes rather than the 51 hours we saw in July" |
| "Industry standard practice" | Delete it. It is not an argument. |
| "Pays for itself in three months" | "At our loaded rate the recovered hours are worth roughly £3,000 against a £480 cost, assuming the estimate above holds" |

Three habits worth keeping:

1. **Name the basis** in the same sentence as the number. "Based on X" is what turns a claim into a calculation the reader can check.
2. **Round down.** A conservative estimate that lands is worth more than an optimistic one that gets picked apart.
3. **Say what you do not know.** "I cannot put a reliable number on this" is a strong sentence, not a weak one.

## Asks that get answered

| Fails | Works |
|---|---|
| "Support this initiative" | "Approve a one-month trial at £40 a month" |
| "Approve budget for tooling" | "Approve £180 a month for three months, cancellable" |
| "Let me know your thoughts" | "Reply yes or no by Friday; I will start Monday if yes" |
| "We should hire someone" | "Approve one headcount in the next planning round, starting Q3" |
| "Give this a try" | "Agree to six weeks from 1 March, reviewed on 15 April" |
| "Sign off on the plan" | "Confirm I can spend two weeks scoping this, reporting back on the 30th" |

The pattern in the right column:

- One decision, not a bundle.
- A number and a date attached.
- A commitment to report back, which gives the reader a second decision point.
- Where possible, your own exit: "I will cancel it myself if the number is not there." A yes is much cheaper when the no is already built in.

If the ask feels too large to approve without a meeting, shrink it. A scoping fortnight is approvable by email; a rollout is not.

## Words to cut

| Cut | Because |
|---|---|
| "synergy", "alignment", "strategic enabler" | They describe nothing and signal that the page is padding |
| "drives value", "unlocks potential" | No reader can tell what would be different |
| "best in class", "industry leading" | Vendor language; you are not selling, you are asking |
| "quick win", "low-hanging fruit" | If it were quick and low, it would be done |
| "I just think" | Removes the authority you need for the ask |
| "It would be great if" | Turns a proposal into a wish |
| "As you know" | Either they do, so delete it, or they do not, so explain it |
| "Obviously" | Everything after this word gets read as defensive |
| "We really need to" | Assertion where a number belongs |
| Any acronym the reader does not use daily | Costs the reader a lookup and buys you nothing |

## The pre-send read-through

Read the page once as the person who has to approve it, on a phone, between meetings.

1. Can you tell what is being asked for, in the first ten seconds? If not, the ask is buried or the title is a project name.
2. Is there a number anywhere in the problem paragraph? If not, the reader has no reason to care yet.
3. Is any figure unlabelled? Every estimate needs "estimated" and a basis.
4. Would the reader find a cost you did not mention? Add it now rather than losing the room later.
5. Is the risk one you could dismiss in a sentence? Then it is a strawman. Replace it with the one that actually worries you.
6. Does it fit on one page? If not, cut detail from the solution section, which is always where the overflow is.
7. Would you be comfortable if this were forwarded to the person it affects most? If not, rewrite that line.