How We Structure a Proposal. Written to be scored.

An evaluation committee reads a lot of proposals under time pressure. Ours are structured so a scorer can find the answer to each criterion without hunting for it. This is the structure we use and why — useful whether you are evaluating us or writing a rubric that gets better responses from everyone.

We grow your business with

CROturn traffic into leads

SEOrank & get found

GEOwin generative search

AEOget cited by AI answers

The principle

The rubric is the table of contents

If your solicitation lists eight evaluation criteria with weights, our proposal has eight sections in that order, using your headings. That sounds trivial. It is the single most common thing missing from proposals, and it forces every scorer to hunt through a document organised around the vendor's marketing rather than the buyer's rubric.

Where you have specified a format, we use it exactly — page limits, section order, file naming, submission method. A proposal disqualified on format is a waste of everyone's time, and the discipline of following your instructions is itself information about how a vendor will behave on the project.

Below is what sits inside that structure. If your solicitation asks for something different, your document wins.

The sections

What each part contains

Understanding of the problem

What we think you are actually trying to fix, in our words. If we have misread it, this is where you find out — which is better for both of us at proposal stage than after award.

Technical approach

Platform, architecture, content model, integrations and how the build is staged for review. Written to be evaluated by a technical reader without excluding a non-technical one.

Accessibility approach

The standard, the verification method, who does the testing, and what documentation you receive — never a claim of compliance without a method. See Section 508 compliance.

Migration plan

Page and document counts, how content is classified, and an explicit URL-preservation commitment with a redirect map delivered before launch.

💵

Pricing by line item

Discovery, design, build, migration, content, accessibility, training, support and hosting priced separately, so you can compare like with like and defer a line without reopening the procurement.

Team and references

The named people who will do the work with their relevant experience, and references you can actually call — not a capability statement about a department.

What we always include

Three things we put in writing

These are the sections that most often go missing and most often cause disputes later.

✓

Assumptions, stated explicitly — page counts, content readiness, review turnaround, who supplies imagery

✓

Your dependencies in the timeline, so a slipped approval is visible as a shared risk rather than a vendor failure

✓

What is out of scope, named plainly, so nobody discovers it during delivery

✓

What you own at the end — code, content, accounts — and that it is not conditional on a support contract

✓

Known risks and how we would handle them, because a proposal with no risks has not been thought about

A note on samples

Why there is no downloadable sample proposal here

Proposals contain client scopes, pricing and staffing. Publishing one — even redacted — means publishing commercial detail that belonged to a specific buyer in a specific procurement, and we are not willing to do that.

What we can do is walk you through the structure against your own solicitation, or answer specific questions about how we would present a requirement you are unsure how to score. The RFP and procurement FAQ covers the recurring ones, and how to evaluate proposals is written to help you read anyone's, not just ours.