How to write proposal timelines clients trust

Try SpecBot free — send proposals with a clear timeline that clients accept in one click.

A bad timeline in a proposal creates problems before the project starts. Too aggressive: you overpromise and miss. Too conservative: the client goes with someone faster. Too vague (“about 4-6 weeks”): nobody knows what they’re committing to.

A good timeline does three things: it sets realistic expectations, it defines what you need from the client and when, and it builds enough credibility that the client trusts the estimate. Here’s how to build one.

Why proposal timelines fail

Most timeline problems trace back to one of four causes:

Optimism bias. Freelancers estimate the “everything goes perfectly” case. In reality, clients take longer to give feedback than expected, there are revision rounds that go deeper than planned, and unexpected technical issues emerge. Best-case timelines are almost always wrong.

Missing client dependencies. A proposal timeline that shows “Week 2: Design review” without stating that the client needs to provide feedback within 5 days is incomplete. If the client takes 10 days, the timeline is broken — but they don’t know that, and they blame you.

Vague phases. “Week 1-2: Design” doesn’t tell the client what they’ll see, when they’ll see it, or what decisions they need to make. It just creates mystery.

No actual dates. “6 weeks” sounds definitive, but “6 weeks starting from when?” is always the question. A timeline that starts on an assumption fails whenever that assumption is wrong.

The principles of a trustworthy timeline

Use actual calendar dates. Map phases to specific weeks or dates, not just “Week 1, Week 2.” “Design concepts delivered by March 14” is clearer and more actionable than “Week 2.”

Show what you deliver at each phase end. Every phase should produce something the client receives. “Phase 1 delivers: discovery questionnaire + site architecture diagram.”

Show what you need from the client. Explicitly state when and what you need the client to provide. “Client provides content by March 7” or “Client reviews and provides consolidated feedback by March 20.”

Buffer generously. Add 15-20% to your honest time estimate for each phase. Unforeseen delays are the rule, not the exception. Building buffer into your estimates means you beat the timeline instead of missing it.

State the dependency. Include language like “Timeline assumes client feedback within the windows above. Delays push subsequent milestones proportionally.”

A phase structure that works for most projects

Phase structure template

Phase 1: Discovery & Setup (1-2 weeks)

• What happens: Requirements review, access and credentials, initial planning
• What you deliver: [Discovery questionnaire / kickoff call summary / site map / whatever applies]
• What you need from client: [Filled brief / account access / existing assets]
• Client action: Provide required materials by [date]

Phase 2: [First Major Work Phase] (2-3 weeks)

• What happens: [First deliverable created]
• What you deliver: [Specific deliverables] by [date]
• What you need from client: Review and consolidated feedback within [5] business days
• Client review window: [date] to [date]

Phase 3: [Revisions / Round 2] (1-2 weeks)

• What happens: Revisions based on client feedback
• What you deliver: Revised [deliverables] by [date]
• Client review window (if second round): [date] to [date]

Phase 4: [Final Phase / Launch] (3-5 days)

• What happens: Final QA, launch, handoff
• What you deliver: [Final outputs — live site / delivered files / etc.]
• Launch date: [date]

Note: This structure adapts based on project type. A branding project might have: Discovery → Concepts → Selected direction refinement → Brand guidelines. A content retainer might just have a monthly rhythm with no phases.

Example timeline table (web design project)

Key assumptions:

• Client provides all page content (copy and images) by March 10
• Client feedback provided within 5 business days at each review stage
• Delays in feedback push downstream milestones proportionally

This table is scannable, specific, and unambiguous. The client knows exactly what happens when, what they’ll receive, and what they need to do.

How to set realistic phase durations

Discovery phase: Usually 3-7 days. Depends on complexity of requirements review. Add time if you expect the client to take a while returning the questionnaire.

First major deliverable phase: Use your honest estimate for the work, then add 20%. If you think a design concept takes 7 days, put 9 days in the timeline.

Client feedback window: 5 business days is standard for most clients. Some clients need 7-10 days (larger organizations with multiple stakeholders). Use your judgment based on the client’s organization size and decision-making process.

Revision phase: Estimate based on the scope of revisions. For a design revision round, 3-5 days is typical. For a full copy revision on a large site, 5-7 days.

QA and launch: Often underestimated. Allow 3-5 days for a typical website. More for complex builds, integrations, or anything with a payment system.

The buffer rule: Your stated timeline should be achievable in the “things go reasonably smoothly” case, not the “everything is perfect” case. Reserve a week of undeclared buffer somewhere (usually between phases or in the final phase).

Language that makes timelines hold

The dependency clause (include in every proposal):

“The timeline above assumes client provides content and feedback within the windows specified. Delays on the client side push all subsequent milestones proportionally, and SpecBot will communicate any impact to the launch date immediately.”

The revision window clause:

“Client review periods are [X] business days for each phase. Feedback must be consolidated (not sequential comments over multiple days) to maintain the timeline.”

The scope change clause:

“Significant changes to project scope after [Phase X] may require a revised timeline. SpecBot will notify client immediately if scope changes affect the delivery date.”

What to do when the client needs it faster

If a client has a deadline that requires a faster timeline than you’d normally propose:

Option 1: Accept with a rush rate. Add 25-50% to the project price for a compressed timeline. Rush work requires prioritizing this project over others and working faster — that has a real cost.

Option 2: Reduce scope to fit the timeline. “To hit [date], we’d need to scope this to [X]. Can you live with [reduced scope] for now and phase in [the rest] after launch?”

Option 3: Decline if the deadline is unrealistic. A client who needs a website in 3 days is either expecting very low quality or has unrealistic expectations. It’s better to decline than to overpromise and underdeliver.

Handling missed deadlines (yours and theirs)

If you miss a milestone: Communicate immediately, don’t hide it. “I hit an unexpected [issue] that pushed me back 2 days. I’ll have [deliverable] to you by [new date]. This doesn’t affect the launch date because I have buffer built in.”

If the client misses a feedback window: Reference the dependency clause from your proposal. “You mentioned you’d have feedback by [date] — I want to flag that this pushes the [next phase] to [new date], and if we slip by more than [X] days, our launch date will need to move to [new date]. Just want to make sure we’re aligned.”

This is professional, clear, and documented. You’re not being aggressive — you’re managing a project professionally.

Start free on SpecBot — SpecBot turns your offers into proposals clients accept in one click, with a signed PDF for both sides. Free is 3 proposals a month with every feature; Pro is unlimited proposals at €12/month, or €9/month billed yearly. Write them in the web app, by voice, or inside ChatGPT and Claude.