Framework 03

Process Proposal

Pitch one automation on a single page, so a decision maker can read it in ninety seconds and answer on the spot.

The Problem

You have done the arithmetic. One row sits at the top of your Process Map, green risk and a payback measured in months, and you are certain it is the right thing to build. Now somebody who was not in the room has to agree.

This is where good automations die. The idea gets pitched in a hallway and forgotten by Thursday. Or it gets written up properly, as a fourteen page document full of tools and architecture, and the person who could approve it never finishes reading. Or it gets a vague nod that is not quite a yes, so nobody starts and nobody kills it, and it floats for a quarter.

An automation needs a decision before it needs a spec. The two get confused constantly, and the confusion is expensive: you spend weeks specifying something that was never going to be approved.

The Idea

Put the idea, the value and the ask on a single page that a decision maker can read in ninety seconds and answer on the spot. Six blocks, each held to a line or two, with the decision written at the top once it is made.

The one page limit is the point, not a formatting preference. If the idea cannot survive on one page, it is not ready to be decided on. And what the page asks for is small: not a build, just the hours to go and specify one properly. That is a much easier yes, and it is the only yes you actually need at this stage.

Here is what one looks like finished, for the top row of a finished Process Map:

Ninety seconds of reading, and the reader knows what it costs today, what it would look like after, what it is worth, what could go wrong, and exactly what they are approving. The rest of this module is how you fill those six blocks in.

How It Works

The Format: One Page, Six Blocks

The proposal is a fixed page. The blocks always appear in the same order, because the order is an argument: what it costs now, why that hurts, what it could be, what that is worth, what could go wrong, and what you want.

Blocks 1 and 2: The Setup

The first two blocks earn the reader’s attention. No story and no jargon, just the fact and the pain:

• The Process Today: one verb. Who does it, how often it runs, and what it costs per month. Pull the numbers you already have instead of inventing new ones.
• The Problem: why it hurts, in plain English. Money, hours, mistakes, or missed customers. Name the one that matters most and leave the rest out.

If you have run the Process Map, both of these are already written. Block 1 is that row restated as a sentence, and the monthly cost is the number the calculator produced.

Blocks 3 and 4: The Pitch

The middle two blocks sell the automation. The picture makes the reader want it, and the numbers make it defensible:

• The Idea: the work after the automation, described as a picture rather than a spec. No tools, no architecture, no vendor names. What does a Tuesday look like once this exists?
• The Value: two numbers. Dollars back per month, and how many months until the automation pays for itself. Two numbers are memorable. Ten are homework.

Both of the numbers in Block 4 come straight off the Map: Monthly Savings and Payback. This is the whole reason the Map comes first. Without it you are guessing, and a guessed number is worse than no number, because the first person who checks it kills the proposal and your credibility with it.

Blocks 5 and 6: The Close

The last two blocks remove the reasons to say no. Show the risk is understood and the start is small, then make the ask so specific that a yes needs no follow up questions:

• Risk & Starting Point: the risk colour and why, in one line. How small the first version starts, in one line. Naming the risk yourself is what makes it survivable; the reader was going to think of it anyway.
• The Ask: what a yes means, exactly. Hours or dollars, a number the reader can approve on the spot.

The Decision

The page exists to force one of three answers, written at the top and dated. Every answer moves things forward, because even a no ends the idea cheaply instead of letting it float:

A yes buys requirements, not a build. The full spec, the decisions, and the quote come next, and they cost real money to produce. This page only decides whether that work starts. Keeping the two separate is what makes the ask small enough to approve and stops you specifying things nobody wanted.

The revisit-when answer is the one people skip, and it is the most useful of the three. Most good automations are not wrong, just early. Writing the condition down, in numbers, means the idea comes back on its own instead of depending on whether you remember it.

Get the Worksheet

The Process Proposal worksheet is an eight page PDF. Six instruction pages walk through the format, the three block pairs and the decision, then the seventh page is the one page proposal form itself, blank and ready to fill in. Print one per automation. It is free.

Working on something like this?

I build full stack AI systems for companies that want to improve how they work or do things that were not possible before. If you are working on this kind of problem, message me on LinkedIn or shoot me an email.

Where It Fits

The Proposal is the third of four tools. The Business System Blueprint made the business visible. The Process Map priced every process and ranked the automations. The Proposal turns the top of that ranking into a decision, and a yes hands the automation to the TRACE Method, which turns it into a build spec.

It stands on its own if you already know which automation you want. But it is much easier to write when the two numbers in Block 4 come from a Map instead of from instinct.