Rush fees when turnaround is hours, not weeks
The rush fee used to price overtime, and generation removed the overtime. Price review-side displacement instead, with tiers, triggers and a reset script.
You did it once. A client asked on a Thursday evening, you turned the cutdown around by Saturday morning because you could, and it felt like a relationship investment. Six weeks later, "can we get this by Monday?" arrives with no acknowledgement that Monday is unusual, because for that client it is no longer unusual. You set the baseline yourself, and you did it for free.
The instinct is to reintroduce a rush fee and hope nobody notices it was absent. That rarely survives the first pushback call, because the traditional justification for a rush fee has genuinely stopped being true, and the client can tell. What still holds is a different justification entirely, and it is worth building the policy on that one instead.
The old justification is gone, and the client knows it
Rush fees were originally priced against a visible input cost. Overtime hours. A weekend crew. An express courier. A colourist bumped onto a night shift. The client could point at the thing they were paying extra for, which is why the fee felt fair rather than opportunistic.
When the production step is a batch of generations, that visible input disappears. There is no plausible story in which a request submitted at 6pm consumes more machine time than the same request submitted at 9am the following Tuesday. If your rush-fee argument is "it costs more to make quickly," you will lose it, and you will deserve to.
This is the same structural problem that pushed the whole category off hourly billing. Billing for time when the time collapsed means invoicing yourself down, and it hands the client your cost structure to negotiate against. The rush fee has the identical flaw in miniature.
Worth noting before you brace for a fight: the closely related fear, that clients would demand an "AI discount," turned out smaller than the anxiety about it. Reported survey figures put most agencies as never having been asked to cut prices despite adopting AI. Clients raise the subject. They mostly do not win on it. Expect the rush conversation to behave the same way if your reasoning is sound.
What a rush actually displaces now
Here is the counterintuitive finding that should shape the policy. Superside's Breakpoint research found 80% of creative teams at or beyond capacity and 70% of creative leaders reporting burnout despite AI adoption. Capacity pressure did not ease. It moved.
The reason is that generation stopped being the bottleneck and filtering, provenance, rights, brand governance and human taste became it. Volume relocated the constraint downstream rather than removing it. That relocation is the entire basis for a modern rush fee: what the client is compressing is not your render, it is your review.
There is a second reason, less discussed. Output is not deterministic. Community-reported figures put usable output at roughly one in four clips and three to five attempts per usable clip, rising for specific character action or complex motion. Those numbers are aggregated anecdote rather than measured data, and nobody has published a real benchmark, which is itself the point: your own usable rate is the number that matters, and it has variance. A normal schedule absorbs a bad run silently. A twelve-hour schedule does not.
So a rush displaces three specific things:
- Your quality-control pass, which is the step that keeps brand standards from slipping at volume.
- Somebody else's approval slot, because approval capacity is finite even when generation is not.
- The reroll buffer that absorbs an unlucky seed without anyone noticing.
That is a real, explainable, defensible cost. It is also one the client can verify, because they have watched their own review queue behave the same way.
A tiered policy priced on the review calendar
Write the standard turnaround into the statement of work as a review-window commitment rather than a delivery date. Something like: "Standard turnaround is five working days from approved brief, comprising two days production, one day internal QC, and a two-day client review window." Now a rush has a definition that does not depend on how long a render takes.
The ladder below is a starting shape, not a market rate. Day rates and rush multipliers for AI-first production are not published anywhere credible, and anyone quoting you a benchmark is guessing. Calibrate against your own displaced capacity.
| Trigger | What gets compressed | Fee shape |
|---|---|---|
| Delivery pulled forward inside the standard window | Internal QC pass shortened | +25% of the deliverable fee |
| Delivery required across a weekend or holiday | Another client's approval slot moves | +50% |
| Under one working day from approved brief | Reroll buffer removed entirely | +100%, variant count capped |
| Brief still changing while production runs | All three, repeatedly | Rush fee plus change-order rate |
That last row is the one people forget. A moving brief inside a compressed window is not a rush, it is two problems stacked, and it should price like both. If you already run a base-plus-change-order structure, the rush fee sits on top of it rather than replacing it.
Equally important is the exclusion list. A rush fee buys queue priority and a compressed calendar. State plainly that it does not buy extra revision rounds, does not raise the variant count, and does not skip disclosure or labelling steps. If anything, a rush should reduce the revision allowance, because there is no calendar left to spend it in. Pair the policy with a revision definition that separates a revision from a new deliverable or the two clauses will contradict each other on the first difficult job.
One practical lever that makes a compressed window survivable without discounting the fee: run the client's look-approval on low-resolution passes before committing to final renders. In an EDL-based editor the timeline is re-renderable, so a 480p preview pass costs no credits and can be iterated on directly, subject to a short per-user cooldown; the charge lands once on the final export regardless of how many clips are on the timeline. That is how you buy back some of the QC time the rush took, rather than skipping QC and hoping.
Resetting after you already delivered one for free
The awkward case is the client who has three unbilled rushes behind them. Three rules make this survivable.
Do not retro-invoice. It reads as a trap and it will cost more in goodwill than the invoice recovers.
Name the precedent out loud rather than pretending it did not happen. The version that works on a call is roughly: "The last three of these have landed inside a day and I have absorbed the schedule cost. That worked while it was occasional. It has become the pattern, and it is now pushing other work. From September I am putting a rush tier on the rate card. Standard turnaround stays what it is and costs what it costs. Anything that compresses the review window carries the tier. You will always see it on the estimate before I start, never after."
Then give it a notice window and hold the date. The mechanics are the same as repricing any legacy arrangement: evidence, notice, a clear start date, no negotiation on whether the policy exists, some flexibility on when it begins.
The clients who push hardest on the fee are usually the ones whose own approval chain is the reason the window is compressed. That conversation frequently ends with them fixing their side instead of paying yours, which is a better outcome than the fee.
FAQ
Should the rush fee be a percentage or a flat amount?
Percentage, if the deliverable is priced per item, because it scales with the size of the thing being disrupted. Flat, if you work on retainer, because a percentage of a monthly fee is a strange thing to compute for a single asset. On retainer arrangements, the cleaner mechanism is a stated number of priority slots per month with a flat fee for anything beyond them.
What if the client says the work only took two hours?
Agree with them, then redirect. The two hours is the part that got cheap. What they compressed is the review calendar, the QC pass and the buffer that catches a bad output before they see it. Ask what happens in their organisation when a request jumps the approval queue. They know the answer, and it is the same answer.
Does a rush fee apply when the delay was on my side?
No, and saying so unprompted is worth more than the fee. Build the trigger around when the brief was approved, not when the client first mentioned the project. If your own turnaround slipped, the compressed window is yours to absorb. A rush policy that quietly charges for your own overruns will not survive contact with a client who keeps records.
How do I stop rush requests turning into the default?
Report them. Include a line in the monthly summary showing how many deliverables ran on standard turnaround versus rush, and what the rush tier added. Once the pattern is visible on a page rather than felt in a calendar, most clients self-correct, because the person requesting the rush is usually not the person approving the invoice.