Estimating turnaround when generation is instant

Coca-Cola's AI-assisted holiday campaign compressed a timeline reported at roughly a year down to roughly a month. That is a dramatic compression and it is worth understanding precisely, because of what it is not: it is not a compression to an afternoon. A large brand production with AI in the pipeline still took weeks, and the weeks were not spent waiting for renders.

This is the gap that wrecks estimates. A client watches a clip appear in under a minute, reasonably concludes that production is now instant, and asks for delivery tomorrow. You know the date is two weeks out and you cannot articulate why without sounding like you are padding.

The answer is that render time was never the variable. Four other clocks set the calendar, and only one of them got faster.

Render time is the smallest number on your schedule

Take a typical 30-second brand video: six or seven shots, a voiceover, music, captions, three deliverable aspect ratios. Add up the actual machine time and it is minutes, not hours. On a 25 fps timeline the finished piece is a few hundred frames, and the editor's final export is a single charged render regardless of how many clips are on the timeline.

Now add up everything else in that job. Brief clarification. Attempts that did not work. A round of client notes. A second round. Music licensing confirmation. A legal read on the claim. Disclosure labelling for the EU-facing cut. Export, check, deliver.

Render time is usually somewhere under 5% of elapsed time. Estimating from it is like estimating a house build from how long the concrete takes to set.

The four clocks that actually set the date

Clock 1: the attempt clock. Not "how long does one generation take" but "how many attempts until one is usable, and how much human judgement sits between attempts." Log attempts per accepted shot for a month and you have a real multiplier for every future estimate. Reroll rates and the shots you throw away covers how to instrument it; estimating credit cost before you dispatch a batch is the budget half of the same number. Note the asymmetry: this clock is mostly your time, so it is the one that scales with headcount.

Clock 2: the approval clock. This is nearly always the largest block, and it is almost entirely waiting rather than working. Measure it as calendar time from "sent for review" to "verdict received," per round, and measure it separately per client — the variance between clients is enormous and it is the single most useful number in your estimating file.

Clock 3: the rights and compliance clock. Music licence confirmation, likeness clearance if a real person's face or voice appears, claim substantiation, and disclosure labelling. Article 50 of the EU AI Act became binding on 2 August 2026, so for anything reaching an EU audience the labelling decision is now part of the schedule rather than a nice-to-have. This clock has a nasty property: it is usually short in working hours and long in elapsed hours, because it depends on someone outside your team replying.

Clock 4: the export and delivery clock. Final renders per aspect ratio, caption burn-in, provenance metadata surviving the export, filenames, upload, platform processing. Small per item, but it multiplies by deliverable count and it happens at the end when there is no slack left. Verify that Content Credentials survived your delivery encode rather than assuming — content credentials through a real pipeline shows where they get stripped.

Assembling the estimate

Build it as a table, in business days, with your own measured numbers in the middle column. The figures below are placeholders to show the shape, not benchmarks to copy.

Stage	Driver	Illustrative	Who controls it
Intake to startable	Completeness of the brief	0.5 day	Client
Shot production	Shots × your attempts-per-accepted-shot	1.5 days	You
Assembly and preview	Timeline build, captions, music	0.5 day	You
Review round 1	Client approval latency	2 days	Client
Revision pass	Notes volume, whether they need new shots	0.5 day	You
Review round 2	Client approval latency	1.5 days	Client
Rights and compliance	Licences, likeness, labelling	1 day, parallel	Third parties
Export and delivery	Deliverable count × formats	0.5 day	You

Two things fall out of the table immediately.

First, more than half the elapsed time in the illustrative version belongs to the client. That is not a complaint, it is a negotiating position: "we can deliver in six working days if notes come back within one day of each preview" is a commitment they can act on, and it moves the conversation from your speed to shared responsibility.

Second, the only row that headcount or faster models shrink is shot production. If shot production is 20% of your calendar, then a model twice as fast improves your delivery date by at most 10%. That arithmetic is why "we got a faster model" almost never shows up as a shorter turnaround, and it is worth explaining once to whoever asks why.

Run the rights row in parallel, starting at intake. It is the one clock that costs nothing to start early and can cost you the whole schedule if you start it late.

What to say to the client

Quote a date, not a duration, and attach the conditions that make it real. The version that works reads roughly like this:

Delivery on the 4th, assuming the brief is complete by Friday and each review round comes back within one business day. Generation itself takes minutes; what sets the date is the two review rounds and the music licence confirmation, which we have already started. If notes come back same-day on both rounds, the 2nd is achievable.

Three things that paragraph is doing. It names a date so there is something to hold. It states the two dependencies that are not yours. And it explicitly concedes that generation is fast, which is the point the client already believes and will not let go of. Arguing with it makes you sound slow; agreeing with it and immediately reframing to the real constraint makes you sound like someone who has run this before.

Never quote your fastest possible path as the estimate. The vendor-published case studies floating around — one unnamed mid-size e-commerce brand reportedly live in 48 hours versus a three-week baseline — are unaudited, best-case, and describe an account with everything pre-cleared. Treat them as proof that fast is possible, not as a schedule.

Where you can compress, and where you cannot

The compressible time is almost all in the review loop, and almost none of it is in production.

Make review cost the reviewer nothing. Send a link, not a file. Sharing a generation with a link means review is a tap on a phone rather than a download, and the difference between a two-tap review and a four-step one shows up directly in clock 2. A client review loop built on previews and share links is the full build.

Stop spending review rounds on mechanical questions. Timing, wording, crop and pacing should be settled before anything reaches the client. The editor is EDL-based, so the cut is one re-renderable timeline, preview: true returns a 480p pass at no credit cost with a short per-user cooldown between passes, and the final export is charged once regardless of clip count. Use those passes to arrive at review with a cut you would defend. Previews and the final export has the billing behaviour.

Fix the gate structure, not the people. Most stalled approvals are structural: the gate is at the wrong stage, there are too many reviewers, or nobody knows what verdict they are supposed to give. Approval workflows that don't stall diagnoses which one you have.

Pre-approve repeating formats. For a series, approve the template once and review only what varies. This removes entire review rounds rather than shortening them, which is the only compression that compounds.

What you cannot compress is the rights clock when a third party has to answer, and you should stop trying. Build it into the estimate as a parallel row, start it at intake, and flag the day it becomes the critical path. From brief to published in under an hour shows what the schedule looks like when every one of these dependencies has already been cleared — which is exactly the point: the hour is real, and it is only available on the jobs where the other clocks were handled in advance.

FAQ

How do I estimate for a client I have never worked with?

Use your median approval latency across existing clients for the first job, and say explicitly in the quote that the estimate assumes one-business-day turnaround on notes. Then measure their actual latency on job one and re-baseline. First estimates for new clients should carry a wider range than repeat work, and it is fine to say so.

The client says "but it's AI, why does it take two weeks?" What do I say?

Agree with the premise, then show the split. "Generation is about two hours of the two weeks. The rest is your two review rounds, the music licence, and the compliance pass. If you can turn notes around same-day we save four days." Numbers end that conversation faster than principles, and it converts a complaint into a request they can actually grant.

Should I quote a range or a date?

A date, with named conditions. Ranges get read as the optimistic end and then remembered as a commitment, so you get the risk of the wide estimate and the credit for none of it. A date plus "assuming notes within one business day per round" is precise, honest, and puts the variance where it actually lives.

Does an extra aspect ratio really add time if the edit is done?

Less than a full deliverable, more than nothing. The export is quick, but each format needs its own safe-area and caption check, and each is separately approvable, so each can generate its own note. Budget a fraction of a day and quote it as a separate deliverable.