The Timeline Section of a Proposal
Give the client a clear, credible picture of how the engagement unfolds — what happens when, how long each phase takes, and what they need to do to keep things on track.
What the Timeline Section of a Proposal Does
The timeline section of a proposal gives the client a clear, credible picture of how the engagement unfolds — what happens in each phase, how long it takes, and what they need to do to keep things on track. It sits after the scope of work and before the commercial terms, bridging the 'what we'll do' and 'what it costs' with a concrete answer to 'when will we get there.'
Unlike a project plan, a proposal timeline is written for a decision-maker, not a project manager. It groups related tasks into named phases — typically Discovery, Design, Build, QA, and Launch — and describes what each phase produces and what sign-off unlocks the next one. That structure reassures the client that the work is sequenced logically and that you've delivered this kind of engagement before.
A well-written timeline also defines the conditions the schedule depends on. Relative durations rather than calendar dates keep the proposal valid regardless of when signing happens. Explicit client dependencies — assets, feedback windows, approvals — create a written record that protects you if a delay originates on their side. Post-launch phases like handover, training, and a support period round out the picture so nothing feels unfinished.
What to Include in the Timeline Section
Phased structure with named groups
Organise work into five to seven named phases — Discovery, Design, Build, QA, Launch — rather than a flat list of tasks. Each phase name should signal a distinct mode of work and a clear output.
Relative durations per phase
Express each phase in working days or weeks, not calendar dates. Relative durations keep the proposal accurate regardless of when the contract is signed.
Phase deliverable and sign-off trigger
State what each phase produces and what decision or approval is required before the next phase begins. This prevents phases from running in parallel when they shouldn't, and gives the client a clear sense of their role.
Client dependencies called out explicitly
Name the assets, access, or decisions you need from the client within each phase, and specify the turnaround window. Written dependencies create accountability and protect the schedule if inputs arrive late.
Start-date assumption
Anchor the whole schedule to a single trigger — for example, 'timeline assumes project kick-off within five business days of contract signing.' Without this, clients assume the clock starts when they feel ready.
Contingency note
Add one or two sentences acknowledging that durations assume timely feedback and that delays from late approvals shift subsequent phases by an equivalent period. This protects both sides without padding every phase estimate.
Post-launch phases
Include handover, training, and a defined support or warranty period as named phases. Clients who don't see these upfront feel abandoned after launch — spelling them out closes the emotional gap between delivery and done.
Proposal Timeline Dos and Don'ts
Do
- Express every phase as a relative duration — 'three working weeks' — so the timeline stays valid no matter when the contract is signed.
- Name what each phase produces and state the client sign-off or decision that triggers the next phase to begin.
- Call out client dependencies — brand assets, credentials, feedback windows — explicitly within the phase they affect, not buried in the contract.
- Include post-launch phases such as handover, training, and a defined support period so the client can see where the engagement ends.
- Add a short contingency note stating that durations assume timely approvals and that late client inputs shift subsequent phases by an equivalent period.
Avoid
- Don't list calendar dates — the moment signing slips by a day, every milestone in the proposal becomes wrong.
- Don't itemise every granular task; a 40-row list overwhelms decision-makers and makes the proposal read like a project plan, not a sales document.
- Don't omit what triggers the start of each phase — clients assume phases run automatically rather than on sign-off, which leads to scope-creep disputes.
- Don't pad every phase estimate in secret to create a hidden buffer — pad estimates erode trust when the client notices the work completed well before the stated deadline.
- Don't make the timeline unrealistically short to win the deal; the first missed milestone destroys credibility that takes the rest of the project to rebuild.
How Waxe Generates the Timeline Section
- 1
Pull the scope and phase structure from the proposal context
Waxe reads the scope of work already in the proposal and identifies the logical phases for this engagement — Discovery, Design, Build, QA, Launch, and any post-launch support. It doesn't apply a generic sequence; it derives the phases from what the project actually involves, so the timeline matches the scope that precedes it.
- 2
Assign relative durations to each phase
For each phase, Waxe estimates a duration in working days or weeks based on the scope and deliverable complexity. All durations are relative — never calendar dates — and the whole schedule is anchored to a kick-off trigger so the timeline stays valid regardless of when the contract is signed.
- 3
Identify and name client dependencies per phase
Waxe flags what the client must supply within each phase — assets, credentials, stakeholder sign-off, feedback within an agreed window — and states these explicitly in the phase description. This creates a written record of the conditions the schedule depends on, protecting both sides if inputs arrive late.
- 4
Write phase deliverables and sign-off triggers
Each phase gets a one- or two-sentence description of what it produces and what decision or approval unlocks the next phase. Waxe keeps the language direct and deliverable-focused — not a task list, but a clear statement of what the client will have in hand at each milestone.
- 5
Add the contingency note and post-launch phases
Waxe closes the timeline with a short contingency note — one to two sentences acknowledging that durations assume timely approvals — and appends any post-launch phases such as handover, training, and a defined support period. The result is a timeline section the client can read in two minutes and sign with confidence.
What the Timeline Section Should Cover
- Named phases that group related work (e.g. Discovery, Design, Build, QA, Launch)
- Relative duration for each phase in working days or weeks
- A brief description of what each phase produces
- The sign-off or decision that triggers each subsequent phase
- Client dependencies called out explicitly within each phase
- A single start-date assumption tied to contract signing
- A short contingency note covering late approvals and feedback delays
- Post-launch phases including handover, training, and a defined support period
Building the Timeline Section: The Old Way vs. waxTable
Frequently asked
What is the timeline section of a proposal, and why does it matter?
The timeline section of a proposal maps the full engagement into distinct phases — Discovery, Design, Build, QA, Launch — each with an estimated duration, a description of its deliverable, and the client dependency that unlocks the next phase. It matters because clients use it to assess risk: a vague or missing timeline signals that you haven't delivered this kind of project before. A well-constructed timeline reduces anxiety, sets realistic expectations, and gives you written evidence if the client causes a delay. Done right, it's one of the most persuasive pages in a proposal.
Should I use calendar dates or relative durations in a proposal timeline?
Always use relative durations — 'two weeks' rather than 'March 10 to March 24.' Calendar dates make your proposal go stale the moment signing slips by even a day, forcing a revision before the project has started. Relative durations stay valid regardless of when the contract is signed. Anchor the whole schedule to a single trigger: for example, 'timeline assumes project kick-off within five business days of contract signing.' That one sentence preserves the integrity of every phase that follows.
How should client dependencies be shown in the proposal timeline?
Name them explicitly within the phase they affect — don't bury them in the contract or leave them implied. For each phase, state what you need from the client, in what form, and by when relative to that phase's start. Common dependencies include brand assets, access credentials, stakeholder sign-off on the previous deliverable, and feedback turnaround within an agreed number of working days. Calling these out upfront shifts accountability in writing. If a client misses a dependency and the timeline slips, your proposal already documented that the schedule was conditional on their inputs.
How many phases should a proposal timeline include?
Five to seven phases cover most service engagements without overwhelming the reader. Group related tasks into a named phase rather than listing every granular action — a 40-row task list in a proposal looks like a project plan, not a sales document, and it signals that you're handing risk to the client rather than managing it yourself. Each phase should name what it produces and what decision or sign-off triggers the next one. Post-launch phases — handover, training, a defined support period — belong here too; clients feel abandoned if those aren't set out from the start.
What is a realistic way to handle contingency in a proposal timeline?
Add a brief contingency note at the end of the timeline, not hidden inside a phase. One or two sentences is enough: acknowledge that durations assume timely feedback and approvals within the agreed windows, and state that delays caused by late client inputs will shift subsequent phases by an equivalent period. Avoid the temptation to pad every phase secretly instead — that approach obscures the real schedule and erodes trust when the client notices. An honest contingency note signals confidence, not weakness, and it protects both sides if approvals run late.
Skip the writing — generate the whole proposal
Waxe drafts it on your brand in about five minutes, then you refine it. From two days of work to a few cents.
Your next proposal, in five minutes
Tell Waxe about the client and get a complete, on-brand proposal to review — the work of two days for a few cents. There is no blank page to start from and nothing to format by hand; you answer a short brief, Waxe does the drafting, and you keep full control of the final document in the editor.