Approval deadlines that survive Black Friday.

A holiday campaign has one fixed moment: the sale opens, the gift guide goes out, the video has to be live. Everything before that moment can bend except the day the client answers. When feedback arrives two days late, those two days do not come out of the client's calendar. They come out of your revision day, your export and the buffer you were quietly counting on.

November makes it worse. Reviewers are running their own campaigns, approvals pass through more people and a single bank holiday can remove a day for one side of the project and not the other. The plan that looked comfortable on a calendar in October has no room left by the second week of November.

The fix is not working faster. It is writing the chain of dates down once, from the publish moment backwards, so you can see exactly how much lateness a project can absorb before it fails, and say so before the draft goes out.

Every holiday project, however small, is the same chain. Your draft goes to the client. The client reviews it, which takes a number of working days that belongs to them. You revise. The client reviews again. After the last revision the client approves, and only then do you deliver the final files. Nothing in that chain can overlap: a revision cannot start before feedback exists, and delivery cannot start before approval.

1. Draft. Your production days, with your hours spread across them.
2. Feedback. The client's review window for the draft, and again after each revision.
3. Revision. One block of your days for each round you included.
4. Approval. The last review window. With zero revisions it is the only one.
5. Delivery. Export, upload and hand-off, before the buffer.

The number of client review windows is always the number of revision rounds plus one. That detail matters, because it is the line most quotes get wrong: two included rounds means three trips to the client, not two.

Settle the rounds and the review turnaround before you start, in the same place you settle dates. The holiday UGC brief template has rows for both, and the usage rights guide covers the dates that decide when the finished video can run.

Now let the first feedback window run long. Everything after it keeps its full length: revision 1 is still one day, the approval window is still two working days, and delivery is still one day. The only thing that changes is where each stage starts, because each one waits for the one before. Nothing is squeezed to make the original date look possible.

The first late day is cheap. It moves delivery from Monday 23 to Tuesday 24 November and spends one of the two buffer days. A second day spends the other, and delivery lands on Wednesday 25, the last working day before publish. The third late day is where the plan breaks, and it breaks harder than you might expect: because Thursday 26 is a holiday, delivery does not move to Thursday, it jumps to Friday 27, the publish day itself, after the 09:00 moment.

That jump is why the planner flags a missed publish deadline instead of quietly compressing something. When you see it, you still have options, and they are all conversations rather than heroics: ask for a later publish time, give up the second revision round, agree a one-day review for the last window, or lock a date the client confirms in writing.

A buffer of two working days is a starting point, not a rule. The better question is how late this particular client usually is. Look at your last few projects with them and write down how many working days each feedback window ran past what they promised. Set the buffer to roughly that number, then add a day if the project has more than two review windows, because lateness compounds across windows.

A buffer is also a promise to yourself. If a project consumes it, nothing is wrong yet, but the next late reply is no longer free. The planner marks that state separately from a miss: delivery after the buffer deadline but before the publish moment shows as using the buffer, so you can warn the client while there is still room to act.

If a client will not hold dates, shorten nothing and shift the burden to them in writing: send the approval request with the date each reply is due and the plain consequence of missing it. The date you can show on paper is worth more than the reminder you send later.

Zero revisions is a legitimate project. The chain shortens to draft, approval and delivery, with a single review window that doubles as the approval. You still need that window on the calendar, and you still need to say when it closes.

Weekends are skipped for the client's review always, and for your own work unless you tick the box that says you work them. If you do work weekends, a weekend day carries hours like any other, and the capacity check counts it. Nonworking dates apply to both sides, so a shared holiday pushes a window by a full day without you touching anything.

Time zones move dates in both directions. If you are in Sydney and the client is in Chicago, a hand-off at 17:00 on a Monday in Sydney arrives at midnight the same Monday in Chicago, so their window can start that day. Reverse it for a creator in London: a 17:00 hand-off arrives at 11:00 in Chicago, too late to count, so their window starts the next working day. The same arithmetic runs on the publish time. A 09:00 Friday sale in Chicago is already Saturday morning in Sydney, which makes Friday your last working day before it, with the buffer to take off that.

Enter the publish time on the client's clock, pick their time zone on the project, and the planner does the conversion for every window and for the checklist you send.

Plans age. Set a stage to done when it is finished, and give it the day it actually finished if that was not the planned day. A review window that has passed without an answer is marked overdue, and the planner treats it as arriving today, because that is the earliest it can honestly arrive. Everything after it moves, and the project is flagged if that costs the publish date.

Locks are for dates somebody else has confirmed. If the client replies that Revision 1 must reach them on Thursday 19 November, lock it. It stays on that day while earlier stages shift around it. If earlier work cannot reach the locked date, the stage shows a conflict, the lock stays visible, and the stages after it follow the earliest finish that is actually possible, so the delivery date you see is never optimistic.