Freelance Proposal Template: Scope, Deliverables and Fees

A good freelance proposal gives the client enough information to decide: what problem you will address, what you will deliver, what is excluded, when the work can happen and what it will cost. I would rather send a short, specific proposal than a polished document that leaves those decisions unresolved.

Below is an editable template and a fictional £600 website-copy example. Use them after a discovery conversation, when you understand the task. If you are still looking for suitable prospects, my first-client guide covers that earlier step.

This is a commercial planning template for service work, not a lawyer-reviewed contract. Use it alongside appropriate agreed terms. Consumer, regulated, international or high-risk projects may need different protections and qualified advice.

Check the fit before writing

Before I recommend preparing a proposal, I would want answers to five questions:

• What needs to change, and why now?
• What specific piece of work can you reasonably deliver?
• Who makes the decision and provides feedback?
• What budget, deadline and access constraints matter?
• What does the client expect to receive at the end?

If the answers are still vague, ask a focused question or propose an appropriately scoped discovery stage. Do not fill the gaps with an elaborate solution and assume the client shares your assumptions.

Copy the freelance proposal template

Download the editable freelance proposal template. Open the plain-text file in a text editor or paste it into your usual document. The reusable structure is also here:

FREELANCE PROJECT PROPOSAL
Project / version / date:
Prepared for: [client legal name and contact]
Prepared by: [freelancer legal/trading name and contact]
Proposal review date: [date to revisit availability and assumptions]

1. The situation
You want to [specific task or change] because [relevant context].
This proposal covers [defined piece of work].

2. Deliverables
I will provide:
- [quantity, format and description]
- [quantity, format and description]
The work will be checked against [agreed requirements].

3. Exclusions
This does not include [specific adjacent tasks].

4. Process and client inputs
Stages: [briefing / preparation / review / revision / handover].
You will provide [inputs] by [dates].
[Person/role] will consolidate feedback and [person/role] will approve.
Included revisions: [number, type and response window].

5. Timing
Proposed start: [date], dependent on [start conditions].
First milestone: [deliverable/date].
Feedback due: [date/window].
Final handover: [deliverable/date], dependent on [inputs/approvals].
If a dependency changes, we will review the effect before confirming new dates.

6. Fee and payment
Fee: [GBP amount and pricing basis].
VAT treatment: [actual applicable position].
Payment schedule: [amount, trigger and due date for each instalment].
Expenses: [included / prior-approval process and cap].
Invoice recipient / purchase-order requirements: [details].

7. Terms and changes to resolve before starting
Agreement/terms reference: [current document/version].
Confirm rights, confidentiality, relevant data responsibilities,
cancellation and liability in the appropriate agreement.
Changes to scope, fee or timing require approval through the agreed process.
Outstanding decisions: [list, or none].

8. Next action
Please [specific action] by [realistic date].
Before delivery begins, we will confirm the final scope, terms,
start conditions and project-start record.

I would remove irrelevant fields rather than leave a long form full of blanks. Keep a dated version of what you send. If scope changes, issue an updated version so nobody has to assemble the agreement from several conflicting attachments.

Worked example: two website pages for £600

This example is fictional. It is not a client engagement, a recommended market rate or a promise of results. It assumes a freelancer who is not VAT registered; no VAT is charged in the example.

Project: homepage and service-page copy for a small UK service business.

Situation: the business wants prospective customers to understand its core service and how to enquire. The current pages describe several activities without making the main offer clear. The project will produce revised copy; improved enquiries are a goal, not an outcome the freelancer can guarantee.

My proposed schedule for this example would be:

• Before day 1: scope and terms agreed, initial payment received, required inputs and permissions checked.
• Day 1: briefing call and confirmation of the writing brief.
• By the end of working day 5: first draft supplied.
• Within the following two working days: client sends one consolidated set of comments.
• Within three working days of receiving that feedback: final files delivered, assuming the comments stay within the agreed scope.

Those are illustrative intervals, not a universal timetable. In a real proposal I would turn them into dates after checking availability and dependencies. A delay in essential client input needs a revised plan, not an invisible promise to make up the time.

For the agreement, the parties still need to settle how the final copy may be used, confidentiality and other relevant terms before work begins. The intended use here is the client's own website. Supplying final files does not by itself explain every ownership or licensing question.

Make scope and revisions specific

“Help with the website” is difficult to price and difficult to finish. “Two page drafts, up to 1,000 words combined, with one consolidated revision round” gives both sides something more concrete to evaluate.

I would distinguish corrections within the agreed brief from a new request. In this example, clarifying a paragraph during the included review is different from adding a third service page or changing the target customer after the first draft.

For a new request, I would respond along these lines:

I can include [new request], but it sits outside the agreed [scope version].
I will confirm the additional fee and effect on delivery before proceeding.
Alternatively, we can keep the current scope and consider that as a later stage.

Do not describe revisions as unlimited unless you understand and intend the commitment. My contract checklist helps connect scope, acceptance and change control.

Check the fee and payment assumptions

For a fixed-fee proposal, I would estimate the delivery work, included meetings, revisions and administration before deciding whether the fee is viable. The freelance rate calculator can help establish a planning floor; it does not tell you what every client will pay.

Name the currency, VAT position, payment triggers and due dates. Do not put “50% upfront” in one paragraph and invoice the whole project again at the end. In the worked example, the two £300 instalments total £600.

GOV.UK explains that businesses can set payment terms, including upfront payment. I would agree those terms before issuing the invoice, rather than introduce a new condition afterwards. See GOV.UK's payment guidance and my invoice guide for the next step.

If the client requires a purchase order or uses a separate finance contact, establish that early. A good proposal should not promise a starting date that depends on a payment process nobody has discussed.

Keep the proposal and agreement consistent

I would compare the proposal with the agreement before asking either side to proceed. The same deliverables, fee, revision allowance and dates should appear in both, or the relationship between the documents should be clear.

Check rights and permissions as well as price. The Intellectual Property Office explains that commissioning work does not automatically make the commissioning party its first copyright owner. Its ownership guidance is a starting point; record the intended arrangement in the appropriate agreement and get advice where needed.

I would also keep portfolio permission separate. If you include previous work as evidence, use only material you are entitled to share, and describe your actual contribution. The portfolio case-study guide helps distinguish an evidenced result from a goal or an illustrative sample.

Do not rely on a document's title to settle its legal effect. This template helps organise the commercial discussion; it does not certify the resulting arrangement or replace qualified review.

Do you need proposal software?

For an occasional proposal, I would start with an editable document and send a clearly named version for review. A paid tool becomes more relevant when proposal handling is a repeated administrative task and you also need related invoicing or project records.

I have used FreshBooks. My recommendation here is to check the specific workflow you need before choosing a plan. Its UK comparison currently lists full proposals on Plus and higher plans; Lite lists quotes, so I would not assume the two features are interchangeable. Check FreshBooks plans ↗ for current features and costs.

Do not buy a subscription simply to make one proposal look more formal. Software cannot resolve an unclear brief, guarantee acceptance or replace the agreement. Keep the free document route if it already works for the volume of proposals you send.

Send a proposal with a clear decision

I would send the proposal with a short message that names the proposed work and the decision needed. Use genuine availability dates, not manufactured urgency.

Subject: Proposal for [project]

Hi [name],

Here is the proposal for [specific work]: [link or attachment].
It covers [main deliverables] for [fee and VAT position], with the proposed
timing and client inputs set out in the document.

The points I would like you to check are [scope point] and [timing/input point].
If the direction looks right, please let me know by [date] so we can resolve
any questions and confirm the final terms and start conditions.

If the scope or timing is not suitable, that is useful to know too.

Thanks,
[name]

Before sending, check the recipient, attachment, version, arithmetic and permissions on the document link. Remove internal notes and another client's details. Make the next action possible without forcing the prospect to create an account just to understand the offer.

Follow up on the decision, not the pressure

I would agree a review date where possible. If the date passes, send a brief follow-up that asks whether the work, timing or budget has changed. Do not send a string of escalating reminders to force a response.

Hi [name], checking in on the [project] proposal we planned to review by [date].
Is the work still a priority, or has the scope or timing changed?
I am happy to clarify [specific point]. If it is not moving forward,
please let me know and I will close the proposal for now.

If the client asks for a lower price, I would first examine whether the scope can be reduced sensibly. A smaller deliverable is clearer than leaving the work unchanged while quietly removing the time needed to do it properly.

Once the client wants to proceed

Confirm the final document version, relevant terms and start conditions. Then move into the client onboarding checklist, rather than treating an enthusiastic reply as proof that the materials, payment and approvals are ready.

My aim is a proposal both sides can use: the client understands the choice, and you understand what you are committing to deliver.

Spot something that needs correcting? See the corrections process.