What is proposal organization?

Proposal organization is the planned structure of a proposal: which sections exist, in what order, what each one says first and how the reader moves through it. In the APMP Body of Knowledge, a well-organized proposal gives a roadmap, makes key points easy to spot, is arranged from the customer's point of view, tells customers what matters to them and uses headings, graphics and other highlighting so evaluators can scan it and find what they need.

What is a content plan in proposal writing?

A content plan is a working document prepared before writing that lays out each section of the proposal: who writes it, the requirements it must answer, the key message it should leave, where the win themes and value propositions appear, the proof to use and a page or word limit. It gives every writer a view of the whole proposal, keeps team writing consistent and lets senior management review the approach before much writing has been done.

Should a proposal follow the RFP's structure?

Yes. Use the RFP's exact headings, include every section it requires and copy its numbering, naming and order, because evaluators score against that structure and a different one can lower the score. If the RFP says nothing about format, mirror the structure of the request itself and, inside it, choose the order that suits this particular customer best.

What does BLUF mean in a proposal?

BLUF stands for "bottom line up front." It means stating the most important information first, then adding details for context and credibility, then general information that reinforces the message. It can structure a whole proposal, a section, a paragraph or a bullet list. For example, a solution section opens with what you will do and how the customer benefits, not with technical details or staffing.

How do you layer information in a proposal section?

Where the RFP allows flexibility, build a section in layers: introduce the topic at a high level, add supporting claims such as features and benefits, prove them with examples and case studies, deal with possible drawbacks or competing approaches, and close with a summary that restates your position. An evaluator who reads only the first layer still gets the main point, and one who reads further finds the evidence.

Proposal Organization: Decide the Shape Before You Write

Here is this episode's question: do you decide the shape of your proposal before you write it, or after?

Many teams start writing the moment the outline is copied from the RFP, and only discover the shape of their argument when the pages are already full. The APMP Body of Knowledge asks for the opposite order. Organization is planned: you decide what each section must say, in what order and with what emphasis, and only then do people write. The reason is simple. Evaluators rarely read a proposal from start to finish. They scan it for the answers they need to score, so the proposal that is easiest to navigate is the one that gets credit for what it says.

This series works through the APMP Body of Knowledge as summarized in the APMP Foundation Study Guide. Earlier episodes covered what to say: win themes, value propositions, theme statements and proof points. This episode is about where those things go, so the evaluator actually finds them.

Illustration: two team members pin section cards onto a wall board shaped like an outline tree under a sign reading Plan, while a desk with a closed laptop and blank pages waits under a sign reading Write — Plan the structure on the wall first. The desk can wait.

What a well-organized proposal looks like

The Study Guide describes a well-organized proposal as one that is easy to understand and easy to evaluate, and it lists the attributes such proposals share. Here they are, with the question each one answers for the evaluator:

Attribute	What it looks like	The evaluator's question it answers
A roadmap	The proposal and each section open by saying what follows and in what order	"Where is the part I need to score?"
Visible key points	The main message of each section stands out instead of hiding mid-paragraph	"What is their answer, in one line?"
The customer's point of view	The structure follows the customer's priorities and vocabulary, not your org chart or product catalogue	"Did they understand what we asked for?"
What matters to the customer	Sections lead with the customer's issues and the outcomes it cares about	"Why should this matter to us?"
Several highlighting techniques	Headings, roadmaps, graphics, callouts and summaries work together	"Can I find it again at the scoring meeting?"

Notice that none of these is about writing style. They are decisions about structure and emphasis, and they are much cheaper to make before the text exists than after.

Illustration: a hurried evaluator at a desk runs a finger down an open proposal while a wall clock ticks; bold headings, a small graphic and an orange signpost box labeled Roadmap stand out from gray body text — Evaluators scan. Headings, roadmaps and graphics are what they actually read first.

Plan content before anyone writes

The Body of Knowledge treats content planning as essential whenever more than one person writes the proposal. A content plan is built by the key members of the team and does several jobs at once:

It assigns the work. Every section has an owner, so nothing is left without one and nothing is written twice.
It names the key points of each section. Writers know what message the section must leave before they write a word.
It carries the strategy into the text. The plan shows where each win theme, discriminator and value proposition should appear, so strategy doesn't stay in the kick-off slides.
It sets size limits. Once the plan is ready, each writer gets a page or word budget, which keeps the proposal within the customer's limits and in proportion to what is scored.
It allows an early review. Senior managers can read the plan, spot a weak approach or a missing message, and fix it while changing course is still cheap.

The Study Guide goes further: writers should complete the content plan for their own sections and be challenged to state what the message of each section is. Draft value propositions belong in the plan too. Its summary line is blunt: planning always comes before writing, and writing should be the last stage.

Here is what one entry of a content plan might look like, written for this article:

Content plan: Section 3.2, Transition approach
Owner: transition lead. Reviewer: capture manager. Limit: 6 pages.
Requirements answered: transition plan, service continuity, knowledge transfer (RFP 3.2.1 to 3.2.4).
Key message: services keep running during the transition because we move one site at a time with a tested rollback at each step.
Win theme placed here: "no disruption to residents" (theme 2). Value proposition draft: zero unplanned downtime during transition, at no extra cost to the customer.
Proof to use: past cutover record and the customer reference from the 2024 municipal contract.
Graphic: a timeline of site cutovers with the rollback checkpoints marked.

An entry like this takes a few minutes to write, and a reviewer can tell in thirty seconds whether the section will say the right thing.

Choosing a planning tool

The Body of Knowledge doesn't prescribe one format. It asks you to use a tool your organization already knows that suits the size of the bid and the time available, and it names several common ones:

Tool	What it is	Works well when
Content plan	A table or form per section: owner, requirements, key message, themes, proof, size	A team writes a large proposal and needs one shared view
Outline	The heading structure with numbering	Time is short and the RFP structure is clear
Annotated outline	The outline plus notes under each heading on what to cover and which requirement it answers	Writers need guidance but a full content plan is too heavy
Mind map	A visual web of topics and how they connect	Early thinking, or a solution with many linked parts
Presentation software	One slide per page or section, with the headline and the planned visual	Slide-based proposals, or when reviewers think in pages
Mock-up	A rough draft of each page's layout: headings, graphics, callouts, placeholder text	Page limits are tight and layout carries much of the message
Bid directive	Written instructions to writers on strategy, themes and rules for the bid	Many contributors need the same direction

Follow the customer's structure

The first rule of organization isn't yours to choose. If the customer tells you how to organize the response, do exactly that. The Body of Knowledge asks you to:

Reuse the RFP's headings word for word.
Include every section the customer requires.
Build a top-level outline that follows the customer's priorities, copying its numbering, naming conventions and order.

Evaluators usually score with a sheet that follows the RFP's structure. If your section 4 answers their section 2, they have to search for it, and an evaluator who cannot find an answer may score it as missing. This is the compliance side of organization.

There is often pressure inside the company to do it differently: a product team wants its standard brochure order, or an executive wants to open with company history. The Study Guide's advice is to tell those stakeholders plainly that leaving the customer's format may lower the score.

Our structure

1. About us · 2. Our platform · 3. Our methodology · 4. Team · 5. Price

The customer's structure

1. Understanding of the requirement · 2. Technical approach · 3. Management approach · 4. Key personnel · 5. Past performance · 6. Price

Illustration: a gray RFP document with an outline numbered 1, 2 and 3 on the left, and a proposal binder on the right with orange tabs numbered 1, 2 and 3 in the same order, joined by dotted lines — Mirror the customer's headings, numbering and order, so every answer sits where the evaluator looks for it.

When the RFP leaves you freedom

Not every request spells out the structure. If there are no explicit instructions, the Body of Knowledge says to follow the outline of the request itself and, inside that frame, arrange things in the order that makes the most sense given what you know about this customer.

That second step is a real choice, and it is where organization becomes strategy. Imagine a section of seventeen pages that must answer twelve requirements. You could arrange it in at least three sensible ways:

Organizing principle	How the section unfolds	Strength	Risk
RFP order	One block per requirement, in the order the RFP lists them	Easiest for the evaluator to cross-check	A theme that cuts across requirements gets split into pieces
Around a structure	Start with the core design (for example, the permission model), then build the other requirements on top of it	One clear spine that matches the section's key message	Departs from RFP order, so it needs a good roadmap and cross-references
A user's journey	Follow one case or one user from the first step to the last	Reads as a story the evaluator can picture	A requirement the customer cares about most may appear late

All three can cover every requirement. They differ in what the evaluator meets first and what it remembers. Pick the one that puts the customer's top concern and your key message at the front, and when you leave RFP order, add a short table that maps each requirement to its page.

The same question, asked in several places

Some RFPs scatter similar questions across different volumes. The Study Guide warns that this confuses both the bidder and the reviewers: different authors may answer the same question in two different ways, leaving the customer unsure what you are actually proposing. A content plan is the natural place to catch this. List repeated questions, decide on one answer, give it one owner and have the other sections say the same thing, or refer to it if the instructions allow.

Make information easy to find

The Body of Knowledge asks for a roadmap at the start of the proposal and at the start of every section after it: a short passage that tells the reader what the section covers and in what order. It also asks you to plan summaries at every level, from the executive summary down to the opening of each subsection, so that the key information is repeated where a scanning reader will see it.

Roadmaps and summaries work together with the other highlighting techniques: headings that state a point rather than just a topic, graphics with action captions, callout boxes and tables. An evaluator should be able to read only the headings, roadmaps and captions of a section and still come away with its message. If that test fails, the section is relying on the evaluator to read every paragraph, and most won't.

Layer the information

Where the solicitation lets you choose the structure, the Body of Knowledge recommends building it in layers, so the reader gets the point first and the support after it. In our own words, the layers are:

Introduce the topic and explain it at a high level, such as what your solution is.
Add the supporting claims, such as its features and the benefits they bring.
Prove the claims with examples, case studies and specific details.
Handle the doubts: address possible drawbacks, or strengthen your position against other approaches (the ghosting idea from earlier episodes).
Conclude with a summary of the main points that restates your position.

For example, imagine a section on a records digitization service. Layer one says in two sentences that you will scan and index the archive within twelve months without closing the reading room. Layer two explains the mobile scanning teams and the indexing rules, and what each means for staff. Layer three gives results from a similar archive. Layer four addresses the obvious worry, damage to fragile documents, and explains why a bulk off-site approach carries more of that risk. Layer five restates the promise in one line. An evaluator who stops after layer one already knows your answer; one who reads on finds the evidence.

Illustration: a reader climbs a staircase of four stacked slabs labeled Topic, Claims, Proof and Summary from bottom to top, with the top slab in orange — Layers let every reader stop at a different depth and still leave with the main point.

Put the bottom line up front

The last principle applies at every level, from the whole proposal down to a bullet list: the most important point goes first. The Study Guide mentions a technique widely used by bidders to the U.S. military, called BLUF, "bottom line up front." It works in three steps:

State the most important information first.
Add the details that give context and credibility and make the reader care.
Add general information that reinforces the message.

Its value is speed and clarity, for the writer as much as the reader: you cannot put the bottom line first until you have decided what it is. The Body of Knowledge's own illustration is a solution section. Don't open with the technical details or the staffing plan. Open with what you will do and how the customer will benefit.

Background first

"Our platform is built on a microservices architecture with 24 modules, supported by a team of 35 certified engineers. Founded in 2009, we have served many public agencies. As a result, we can process applications faster."

Bottom line first

"Residents will get a decision on their permit application in 3 days instead of 14. We get there by automating the completeness check, which currently takes most of the waiting time. The details follow in 2.1 to 2.4."

Illustration: an inverted triangle in three bands, with the wide top band in orange labeled Bottom line, and a small evaluator figure nodding beside it — Bottom line up front: the point first, then the support, then the reinforcement.

Checklist for your next proposal

Build the outline from the RFP: exact headings, every required section, the customer's numbering, naming and order.
Write a content plan in the tool your team knows, with an owner, the requirements, the key message, the themes, the proof and a page limit for every section.
Have writers state each section's message and draft its value proposition before they write.
Review the plan with senior management before writing gets far.
Find questions the RFP asks more than once and settle one answer with one owner.
Where the RFP leaves freedom, choose an organizing principle for each section on purpose, and map requirements to pages if you leave RFP order.
Open the proposal and every section with a roadmap, and plan summaries at every level.
Layer each section: topic, claims, proof, doubts, conclusion.
Put the bottom line first in every section, paragraph and list, and test it by reading only headings, roadmaps and captions.

Where Contrl fits

The choice that matters most in this episode is made before any page is written: how a section will unfold. In Contrl, after you have picked a section's key sentence, it proposes three plans for that section, each built on a different organizing principle, such as RFP order, a central structure or one user's journey. Every plan covers all of the section's requirements and shows its page ranges, its strength and its weakness, so you compare structures side by side and choose one before a single slide exists. Only then does it write the slides, each citing the RFP requirements it answers, which keeps the mapping visible even when you leave RFP order.

Contrl's development step for one 17-page section: three plans covering the same 12 requirements, in RFP order, around a three-tier permission structure, and as one student's journey, each with page ranges, a strength and a weakness; plan B is selected — Three ways to unfold the same 17 pages. Each covers every requirement; they differ in what the evaluator meets first.

Next in the series

A good structure gets the evaluator to the right page; the words on that page still have to persuade. Episode 16 covers Persuasive Writing: how to write sentences that are clear, customer-focused and easy to score.

This article is an independent study companion based on the APMP Foundation Study Guide, version 4.2 (© 2025 APMP), which summarizes the APMP Body of Knowledge. It paraphrases and comments on that material and is not endorsed by APMP. The attribute table's questions, the sample content plan entry, the tool comparison, the two outlines, the table of organizing principles, the records digitization example and the before-and-after paragraphs were written for this article, and their figures are illustrative. For the authoritative text and certification information, see apmp.org.