The timeline section of a proposal does two jobs. It shows the client you’ve mapped the actual work, not just the outcome. And it creates a shared reference point that matters the moment the client asks “why is this taking longer than expected?” or “can we add this feature before launch?” Without a written timeline, you’re arguing from memory. With one, you’re pointing to a document you both signed off on.
What a proposal timeline should include
A proposal timeline is not a project plan. It’s a summary. The right level of detail is enough for the client to understand how the project will unfold — not every task, just the phases and how long each one takes.
For each phase, you need three things:
- Phase name: Something descriptive. “Discovery,” “Design Concepts,” “Revisions,” “Final Delivery” — clear, not jargon-heavy.
- What happens in that phase: One sentence. What’s the main activity? “Review existing materials and conduct stakeholder interview” or “Deliver two initial design concepts for review.”
- Duration: How many days or weeks. Don’t use specific calendar dates in the proposal — use relative durations. Specific dates go in the project contract or kickoff document, after the start date is confirmed.
Format: table beats prose
Don’t write the timeline as a paragraph. A table is faster to read and easier for the client to reference later.
Basic structure:
| Phase | Description | Duration |
|---|---|---|
| 1. Discovery | Review brief, assets, and competitor landscape. Kickoff call. | 3 days |
| 2. Concepts | Develop two homepage concepts (mobile and desktop). | 1 week |
| 3. Revision round 1 | Incorporate your feedback on preferred direction. | 3 days |
| 4. Revision round 2 | Final refinements based on second review. | 2 days |
| 5. Delivery | Final files handed off in agreed formats. | 1 day |
Total: approximately 3 weeks from project start.
That’s it. The client can see the sequence, understand what they need to do (and when), and have a clear sense of the total duration.
Noting client dependencies
This is the part most freelancers leave out. If your timeline depends on the client doing something — delivering brand assets, approving a concept, scheduling a call — say so explicitly.
Add a row or a note below the table:
“Timeline assumes client feedback on Phase 2 concepts within 3 business days of delivery. Delays in feedback will push subsequent phases accordingly.”
That sentence protects you. It converts a vague expectation into a written term. When Phase 3 starts late because the client took 10 days to respond, you have a documented reference point for why.
Client-caused delays are the most common reason freelance projects run over. A one-sentence dependency note in the proposal prevents 80% of the awkward conversations that would otherwise happen mid-project.
How specific to be
More specific is better up to a point, then it backfires. If your timeline has 15 rows of daily tasks, it reads like a project plan — and the client will hold you to every line, even when real-world adjustments are necessary.
Rules of thumb:
- Phases, not tasks: “Strategy development” is a phase. “Write keyword list” and “run competitor audit” are tasks. Keep them rolled up.
- Durations, not dates: “2 weeks” instead of “June 3–14.” Specific dates become wrong the moment the project starts a few days late.
- 3–6 phases for most freelance projects. Fewer than 3 and the timeline feels skeletal; more than 6 and it feels like you’re padding.
- Buffer honestly: If the work takes 4 weeks but you’re building in a week of buffer, say “approximately 5 weeks” rather than committing to exactly 4 and consistently running over.
What to do when the timeline changes
Timelines shift. Clients change their minds, add scope, or take longer to respond than expected. When that happens, address it proactively — don’t wait for the client to ask why things are running behind.
Send a short update: “Phase 2 is taking 3 extra days because the competitor analysis uncovered additional positioning work worth addressing properly. Revised delivery for Phase 2: [new date]. Overall project end date moves to [new date]. Let me know if that works.”
Short, factual, no apologizing for doing the job well. Clients generally respond well to transparent updates. They respond poorly to surprises.
Proposal timeline vs. project plan
These are different documents with different purposes:
| Proposal Timeline | Project Plan | |
|---|---|---|
| Purpose | Help client understand scope | Guide actual execution |
| Detail | Phase-level | Task-level |
| When created | Before contract | After kickoff |
| Binding? | Reference point | Working document |
Your proposal timeline informs the project plan. Once the contract is signed and the start date is set, you build the actual task-level plan in your project management tool. The proposal timeline is the sketch; the project plan is the blueprint.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
