Explain turnaround from a defined start point and distinguish your working time from time waiting for client input or approval. State dependencies and review stages that affect delivery. Use a range when uncertainty remains, and explain how you communicate a revised schedule instead of promising unconditional speed.
Define when the clock starts
Name the event that makes the work ready to begin. It may be an agreed scope, receipt of approved source material and confirmed access to the required systems. An enquiry date is rarely the same thing as a project start. Explain whether a published turnaround refers to a typical delivery window after those conditions are met or to your current booking availability. Without this distinction, a reader can reasonably interpret the same number in several incompatible ways.
Choose units that match the actual process. Working days, calendar days and scheduled sessions are different. Clarify time-zone expectations when meetings or same-day reviews depend on them. Avoid offering a global reader a deadline based on an unexplained local calendar. If timing is agreed individually, state the factors you consider rather than inventing a standard promise. A useful estimate describes what you can plan while acknowledging what the brief has not yet established.
Show the dependencies between stages
Identify the decisions that must happen before later work can proceed. A draft cannot be finalized while factual questions remain unresolved; a workshop agenda may depend on attendance confirmation. Separate the time you spend working from time reserved for review. Explain what the client needs to provide and who consolidates feedback. A schedule becomes more realistic when it identifies responsibilities instead of assuming every reviewer responds immediately or every source arrives complete.
List the situations likely to change the estimate, such as additional scope, missing access or conflicting comments. Keep the explanation practical rather than writing a catalogue of possible disasters. If the client needs a fixed event date, discuss it early enough to evaluate what scope can fit. Reducing scope may be more appropriate than compressing review into an unusable window. Do not describe a faster route as equivalent when it omits checks that materially affect the handover.
Describe how the schedule is maintained
Explain what happens when a dependency slips. Confirm the outstanding item, assess the effect on later stages and agree an updated plan. Avoid saying that a delayed input simply shifts every deadline by the same amount; existing commitments or reviewer availability may mean the next opening is different. State the actual process you use. A public service page can describe this principle without promising that every schedule change can be absorbed automatically.
Keep published timing information current and consistent with enquiries. If an offer has a typical turnaround but is temporarily unavailable, display both facts clearly. Do not present an old availability statement as evidence that a new project can begin immediately. At handover, distinguish delivery of your artifact from the client’s subsequent approval or launch. Completing a review within an agreed window does not establish that the full organizational change has happened on the same schedule.
Fictional example: separating drafting and review time
A fictional writer, Zoe, drafts an offer for an internal-guide update. Her initial description says “delivered in two weeks” without explaining the starting point. In the revised fictional offer, timing is discussed after the scope, source pack and client reviewer are confirmed. The schedule includes separate periods for drafting and consolidated factual feedback, with publication handled by the client afterward.
When the invented client cannot provide an approved procedure, Zoe identifies which sections can proceed and which must wait. She discusses a revised handover rather than completing the missing instructions from guesswork. The example illustrates a schedule conversation and its dependencies. It does not establish that a particular two-week window is appropriate for other guides or that client approval can be guaranteed.
A checklist for your next step
- Define the readiness conditions.
- Distinguish booking from delivery time.
- Show review dependencies.
- Explain the rescheduling process.
- Keep availability statements current.
Common questions
Can I promise a fixed turnaround?
Only for a scope and process you can support. State the start conditions and any dependencies that remain outside your control.
Should client review time count in the estimate?
Explain whether it does. Separating work and review periods often makes the overall schedule easier to understand.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveProfile.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.