Proposal Templates

This is the general-purpose structure, and the one to choose when the work does not fit neatly into a discipline-specific template. It assumes the reader is evaluating whether to hire you at all, not just comparing your price to someone else's, so it spends its first page establishing that you understood the problem before it moves on to what you propose to do about it.

It works well for mixed engagements — a piece of strategy followed by delivery, or a project that touches several services at once — because the scope and deliverables sections are written as lists you shape rather than as a fixed menu. It is also the safest choice when several people at the client's organisation will read the document, since it explains the reasoning rather than assuming shared context.

A freelance proposal is usually read by one person who is deciding quickly, often between two or three options. It should be shorter than an agency document and more direct about what you will personally do, how you work, and what you need from the client to keep things moving.

The structure keeps a brief introduction to you and your relevant experience, then moves straight into the project: what you understood, what you will produce, when, and for how much. The revisions and availability sections matter more here than in most templates — solo work stalls when the number of review rounds and the client's response time were never agreed, and naming both in the proposal prevents an uncomfortable conversation later.

Website projects go wrong over page counts, content, and features, so this structure asks you to be explicit about all three. The scope section lists the pages or page templates included and states what happens when the client wants more. The functionality section separates what is standard — a contact form, a blog listing, basic on-page SEO fields — from what is custom work with its own cost.

Content is the single most common cause of delay, so the template gives it a named section: who writes the copy, who supplies images, and what the schedule assumes about when that material arrives. Milestones follow the way the work actually runs, from discovery and wireframes to design, build, review, and launch, with a short post-launch support window described in plain terms.

Marketing work is judged on outcomes, but the proposal has to be honest that outcomes depend on budget, market, and time. This structure opens with the objective in the client's terms — more qualified leads, a lower cost per acquisition, a launch that reaches the right audience — and then sets out the channels and activities you propose to get there.

The deliverables section counts things: how many campaigns, how many pieces of content, how many creative variants per month. The reporting section states what the client will receive and how often, which is what turns a retainer from a vague monthly fee into something reviewable. Where results cannot be guaranteed, the template says so, and names the leading indicators you will report against instead.

SEO is easy to sell badly and hard to explain well, mostly because the value arrives months after the invoices start. This structure front-loads the diagnosis: what is happening on the site now, what is holding it back, and which of those problems are worth fixing first.

From there it separates the work into the categories a client can follow — technical fixes, on-page optimisation, content, and off-page work — and attaches deliverables and a rough sequence to each. The reporting section defines the metrics you will report and the cadence, and the timeline section is explicit that ranking and traffic changes take time, which protects both sides from a review meeting in week six that nobody planned for.

Software proposals need to be precise about requirements, because everything downstream — estimate, schedule, and price — rests on them. This structure begins with the requirements as you understood them, stated plainly enough that a non-technical stakeholder can confirm or correct them, and lists explicitly what is out of scope for this phase.

The delivery section breaks the work into phases with what is completed at the end of each, so progress is visible before the final handover. Testing, deployment, and handover are named as deliverables rather than assumed, and the maintenance section describes what happens after launch: what a bug fix covers, what counts as a new feature, and what support arrangement, if any, is included.

Consulting is bought on confidence, so the proposal has to show the thinking. This structure opens with the problem as the client described it, restated with whatever additional definition your experience adds, because a sharper problem statement is often the first piece of value you deliver.

It then sets out your recommendation and the methodology behind it — the phases, the people you will need access to, the data you will need, and the decisions the client will have to make along the way. Deliverables are concrete artefacts: an assessment, a roadmap, a workshop, a written recommendation. Fees are presented against the phases so the client can see what they are paying for at each stage, and the assumptions section names the access and availability the plan depends on.

Creative work is subjective, which makes an explicit brief and an explicit revision policy the two most valuable parts of the document. This structure starts with the brief as you understood it — the audience, the tone, the constraints, the things the client has said they dislike — so that later feedback can be measured against something agreed.

Deliverables are listed as specific assets and file formats rather than as “design work”, and the revisions section states how many rounds are included and what happens beyond them. Usage rights are named directly: what the client may use the work for, and whether source files are included. Presentation stages give the client a predictable rhythm of concepts, refinement, and final artwork rather than one nervous reveal at the end.