Skip to content
Arc
Sign In Get started
Workflow-specific products Content, decks, visuals, briefs, proposals, legal, books, and project delivery each have a clearer buying path.
Review before delivery Draft, edit, collaborate, approve, and export in the same workspace.
Security + procurement path Security policy, support, and Azure Marketplace buying are public.

Proposal Format

The standard order of a proposal, why it is in that order, and where it legitimately changes — RFP responses, internal approvals, and short-form offers each format differently. Includes the formatting decisions that actually affect whether a proposal is read.

Draft a Proposal in This Format Check a proposal for gaps (free)

Proposal format is the order and presentation of a proposal's sections. The standard order is: summary, the problem, approach, scope, deliverables, timeline, pricing, proof, terms, next step. It is in that order because a reader decides early whether you understood the brief, and every section after the problem statement is answering a question the previous one raised. The order changes in three situations — an RFP response follows the buyer's structure, an internal approval leads with the ask, and a short-form offer compresses to a letter. Everything below covers when to depart from the standard and when not to.

The standard proposal format

Ten sections in the order a reader needs them. Departing from this order is fine when there is a reason; departing from it by accident is what makes proposals hard to follow.

1
Executive summary
The whole proposal in a paragraph: what they need, what you propose, what it costs, what happens next. Written last, read first, and often the only part a senior approver reads. It should be able to stand alone.
2
The problem
Their situation restated in their language. This is the section that establishes whether the rest is worth reading.
3
Approach
How you would solve it, at the level of detail the decision needs.
4
Scope, in and out
The boundary. Explicit exclusions belong here, not in the terms, where nobody reads them until there is a dispute.
5
Deliverables
Named, countable artifacts.
6
Timeline
Milestones, dependencies, and what you need from them.
7
Pricing
Broken into components that map to the scope, so a reader can trace what each number buys.
8
Proof
Comparable work with outcomes.
9
Terms
Validity, assumptions, IP, confidentiality. Short, and never the place where a scope exclusion first appears.
10
Next step
One action, named owner, date.

Formatting choices that change the outcome

What winsWhat loses
Summary that stands alone on page oneA summary that only makes sense after reading the rest
Pricing components map to scope itemsPricing structured differently from the scope, so nothing reconciles
Exclusions in the scope sectionExclusions buried in terms and conditions
Section order follows the RFP when respondingYour house order imposed on the buyer's evaluation sheet
Numbered sections when the buyer must cross-referenceUnnumbered prose in a formal evaluation process

When the format should change

Responding to an RFP, use the buyer's structure and their numbering, even where it is worse than yours — evaluators score against their own sheet and a well-organised proposal in the wrong order loses points it earned. For an internal approval, lead with the ask and the budget, because the approver's first question is the number. Gixo Arc's RFP requirement extractor pulls the buyer's structure out of the document so the response can be built against it rather than reformatted afterwards.

Proposal format: FAQ

What is the standard proposal format?

Summary, problem, approach, scope, deliverables, timeline, pricing, proof, terms, next step. The order matters more than the section names, which vary by industry.

Should a proposal be a PDF or a document?

A PDF for anything formal or externally evaluated, because pagination and layout stay as you set them. A living document is fine where the proposal is a working draft between two parties who trust each other.

How do I format a proposal for an RFP?

Follow the RFP's own structure and numbering exactly, and answer each requirement where the buyer expects it. Evaluators score section by section; making them hunt costs marks.

Does proposal formatting actually affect win rate?

Presentation is not why you win, but poor format is a common reason for losing marks in scored evaluations, where an unanswered requirement scores zero whether or not the answer is elsewhere in the document.

Answer the requirement, not just the matching words

Start with the buyer’s actual requirements

A bid response lists the buyer’s requirements as its workspace opens. Inspect them against the RFP and its addenda, then use the focused answer editor. If automatic listing could not finish, List the requirements remains the way to retry. Other proposal kinds keep their scope, deliverables and commercial structure.

Judge reuse in the context of this bid

Find approved answers beside the response you are writing. Arc labels whether a match answers the requirement, answers part of it, limits the commitment, only repeats the question or concerns something else. Review the quoted passage and its current applicability. A Not checked label means the review did not establish an answer; a similarity score alone is not approval.

Keep the answer, reviewer and commercial promise together

The side panel holds reusable answers, owner, reviewer, due date and permitted comments. Ask Arc and Draft unanswered can use approved library evidence, with off-subject matches left out when the relevance review is available. Partial answers keep their limits. Inspect passage-level citations and the buyer’s price table before locking and sending the proposal; AI review does not authorize the commitment.

Read the relevance label and quoted passage beside the answer
Read the relevance label and quoted passage beside the answer. Fictional requirement and supplied review result; no AI assessment performed. Captured locally on 2 November 2026. Open full-size example.

Updated