A client sends a brief and asks when they can have it. The honest answer depends on things that are hard to see in the moment: what each editor already has on, how long current jobs will wait on feedback, and what else might land first.
It is tempting to give the date the client hopes for and work out the rest later.
This is how I'd give a date you can keep.
Map workload weeks ahead, not just this week
Most studios know what everyone is doing today. Fewer can say what each editor will be doing in a few weeks, and that is the question a new brief actually asks.
Keep a view of each editor's committed work for several weeks ahead — which jobs, roughly how much of their week each takes, and when each is due. It doesn't need to be precise to catch the clashes a detailed view of this week can't.
Update it whenever a job is confirmed, moves or finishes. A forward view that is a fortnight stale is worse than none, because it still looks trustworthy.
Count client review wait time
A job's edit time and its delivery time are not the same thing. Between rounds the job waits for the client's notes, and that wait is easy to leave out of a plan because the editor isn't busy during it.
The editor is free for other work, but the delivery date moves with every day the client takes. Plan each job with its review windows included, and agree those windows with the client.
When a client misses their window, move the date openly and say why. Don't absorb the delay by squeezing the edit.
Keep a buffer
Plan editors to less than their full week. Revisions run long, footage arrives late, people get ill.
If every hour is already allocated, any one of those pushes something else back, and the delay spreads across clients. A buffer isn't idle time; it's what lets you absorb ordinary surprises without moving anyone's date.
How much you need depends on how unpredictable your work is. Your own record is the best guide to that.
Track time as work happens
A forward plan is only as good as its estimates, and estimates only improve if you know how long jobs actually took. Time written up at the end of the week from memory is tidy and wrong.
Time recorded as the work happens — roughly, against the job — gives you a record you can trust. Over a few months it shows which kinds of job you consistently underestimate.
This is for planning, not for checking up on anyone. It is worth saying so to the team.
Keep it light. A rough figure against the job, logged the same day, beats a precise one reconstructed on Friday.
When to say “not until the 20th”
If the map shows no room before a certain date, say so, and give that date. A specific later date is far more useful to a client than a vague yes followed by a slip.
It lets them plan their own launch, decide whether the timing works, or tell you which of their other jobs matters less.
When you say it, offer what you can: an earlier start on part of the job, a smaller first deliverable, or the first free slot held for them. A date given with a reason, and then kept, is worth more than an early one that moves.
It also protects your editors. A studio that promises everything at once ends up with one impossible week, and the quality of the work is what gives.