Change request form template

What this is about

A change request is not a complaint mechanism; it is how a project stays priced while it changes. Productions change constantly, and most changes are reasonable: a new location, a second product variant, one more language. The problem is that requests arrive as sentences in a meeting, get absorbed, and become invisible until the schedule slips or the margin is gone. This form makes the arithmetic visible at the moment of asking, which usually settles it faster than a negotiation later — a surprising number of requests are withdrawn once someone can see two extra days written next to them.

A template is the starting point, not the goal: once it has been filled in by hand twice, it is worth asking whether the document should come out of the plan instead.

What runs differently here

In planning terms, that means:

• A description of the requested change in one paragraph, written by the production rather than quoted from the message, and confirmed back to the requester
• The reference point it deviates from: the briefing line, the approved treatment or the agreed deliverable list, named so the deviation is demonstrable
• Impact in three units — working days, external costs and the delivery date — because a change that costs no money can still cost the deadline
• The consequences for work already done, including anything that has to be redone, and any earlier approval the change invalidates
• A decision block with options, a named approver, a date, and a deadline after which the answer itself starts moving the delivery date

Step by step

This order gets you there fastest:

1. Write the request down the same day it is made, in your own words, and send it back for confirmation before estimating anything.
2. Name the reference it departs from — briefing, treatment, deliverable list — so the conversation is about a documented deviation and not about goodwill.
3. Estimate impact in days first and in money second, because the schedule consequence is what the client can least easily absorb.
4. State what already finished work becomes invalid, and whether any approval already given has to be repeated afterwards.
5. Offer alternatives where they exist: the same effect with a smaller impact is often accepted immediately, and the offer keeps the relationship intact.
6. Set a response deadline and state plainly that waiting also has a cost, since an undecided change blocks the same resources as an approved one.
7. Once approved, update the schedule, the budget and the deliverable list in the same pass, then file the signed request with them.

Common pitfalls

What most often goes wrong in practice:

• Accepting the change verbally and writing it up afterwards, at which point the estimate reads as an invoice rather than as a decision
• Costing only the direct work and not the rework, so the second grade pass and the reissued subtitles are absorbed silently
• No response deadline, leaving the team blocked while a request neither approved nor withdrawn sits in someone's inbox
• Using the form for everything, including trivial adjustments, until it becomes an obstacle nobody wants to trigger

With TillyGen

Because the schedule, the shot list and the deliverables sit in one connected plan, TillyGen shows what a requested change actually touches — which days move and which documents have to be reissued — before anyone commits to it.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.