Making several product videos from a shared layout sounds straightforward until one record has no usable image, another has twice as much copy, and a third is ready to go. If you treat the whole spreadsheet as one finished brief, those differences tend to appear late in production.
A useful batch plan says what each record needs, what happens when something is missing, and how the resulting file gets approved. This is about producing separate videos for separate records, rather than resizing one announcement for several channels.
Decide which parts can really stay the same
Start by describing the common structure. Imagine a fictional software team making a short announcement for each new feature: a heading, a current product image, a sentence explaining the change and a destination for more information. The visual arrangement can be shared while the facts differ by record.
Some production tools support this directly. Creatomate describes a workflow where editable template elements correspond to spreadsheet columns and each row supplies one output. You still need to check whether your features fit the same design; putting them in a spreadsheet doesn't resolve that.
If one feature needs a sequence of actions and another can be explained by a single image, don't force both into the same structure. Give them different layouts or take the more involved feature out of the batch. The template should serve the explanation rather than determine which product facts survive.
Define required fields before collecting the rows
For this example, require a stable record ID, an approved heading, an explanation, a product image, a destination and a source reference. The source reference tells the reviewer where to check the feature claim; the image alone may not explain its permissions or availability.
Keep optional material separate. A category label or decorative background can be optional if the composition still works without it. An image that demonstrates the feature isn't interchangeable with a decorative image, so leaving it out changes whether the announcement is ready.
Record who approved the facts and which version of the layout the row is intended to use. These are production controls, not claims that the video is already approved. A complete row can be ready to make while its rendered output still needs a separate review.
Use a small dataset to make the exceptions concrete
Here are three fictional records for the same announcement layout. The readiness decisions are part of the example, not results from a render or a tested template. The image names describe assets that would need to exist in a real project.
Record A: saved-filters Heading: Reopen your saved filters Explanation: Save a filter setup and select it again later. Image: saved-filters-result.png Destination: /features/saved-filters Source: Approved feature note A, version 1 Optional category: Workflow Decision: Ready for production; output review still required. Record B: review-assignment Heading: Assign the next reviewer Explanation: Choose who reviews the request next. Image: Missing Destination: /features/review-assignment Source: Approved feature note B, version 1 Optional category: Empty Decision: Hold this row until its product image is supplied. Record C: scheduled-summary Heading: Schedule a summary of the selected report to arrive in your team's inbox every Monday morning Explanation: Choose a report and a weekly email schedule. Image: scheduled-summary-settings.png Destination: /features/scheduled-summary Source: Approved feature note C, version 1 Optional category: Reports Decision: Hold for copy/layout review; heading contains several ideas.
For record C, a reviewer could propose 'Schedule a weekly report email' as the heading and move the precise schedule into the supporting explanation. That is an editing proposal to check against the fictional feature note, not permission to silently change the approved wording.
Choose rejection or fallback for each missing field
Record B can omit the optional category, provided the layout has a deliberate treatment for that empty space. It shouldn't quietly use record A's image or a generic dashboard in place of the missing product evidence. Hold that row and identify the owner of the missing capture.
Write the fallback rule beside the field so it is predictable. For example, an absent category means omit the category label; an absent product image means don't produce that record yet. If you want a text-only alternative, approve it as a separate layout with its own explanation, rather than improvising it during the batch.
The rejected row doesn't automatically mean the other records must stop. Decide whether they can proceed independently, then keep B out of the release list until its own issue is resolved. Make that decision visible so a partial batch isn't mistaken for a complete one.
Review duration and layout with the actual record content
A shared duration doesn't guarantee a shared reading effort. Record A's heading is short, while record C asks someone to understand the report, recipient and schedule. Preview the real text in the composition before assuming both fit the same timing.
Review the complete sequence for each layout you use. Check whether the heading is still being read when the image appears, whether the image is legible at the intended size, and whether the ending leaves time to understand the next step. If narration is included, check it against that record's pacing rather than borrowing the timing from another row.
Resolve crowding by changing the copy with approval, simplifying the scene or assigning another layout. Automatically shrinking long text can make a file technically complete while making its explanation much harder to use.
Track the input version alongside the rendered file
Give every output a clear connection to its record, approved input revision and layout revision. If record A's image changes, you should be able to identify which file used the earlier image without opening every video in the folder.
Keep production status separate from approval status. A completed render still needs a content and delivery check; a failed render needs an explicit next action. If you rerun one record, identify the replacement so the publisher doesn't accidentally choose the earlier file.
Release manifest fields: record_id input_revision layout_revision output_filename render_status review_status reviewer publish_destination replaces_output Example before production: saved-filters | input-1 | layout-1 | not created | pending | pending | assigned | feature page | none review-assignment | input-1 | layout-1 | not created | held: missing image | not started | assigned | feature page | none scheduled-summary | input-1 | layout-1 | not created | held: copy/layout decision | not started | assigned | feature page | none
Release only the records that have passed their own review
Before handing over the batch, compare each approved output with its row. Check the image, feature wording and destination together, then make sure the manifest points to that exact file. An accurate video linked to another feature's page is still the wrong delivery.
Publish from the approved list rather than everything in an export folder. Keep held and superseded records visible in the manifest so their absence is explained and their replacements can be followed later.
That gives you a useful basis for the next batch: a shared structure where it fits, explicit exceptions where it doesn't, and a record of which explanation actually reached the audience.