I Replaced a Weekly Slide Deck With a Video Job Queue

My weekly update process used to end in a slide deck that nobody quite owned. The metrics came from one place, screenshots from another, the narrative lived in a document, and the final export depended on whoever had time to assemble it. The deck existed, but the workflow behind it was mostly memory.nn!Structured weekly report data moving into an organized video job queuennI did not need a more elaborate presentation tool. I needed a source of truth that could turn the same weekly inputs into a short, reviewable video update. So I started treating each update as a video job rather than a tiny creative project.nnVideoFlow made that idea practical for me because it treats a video as structured VideoJSON. The same definition can be previewed in the browser, edited in an embedded React editor, and rendered in a browser or server environment. That gave me a path from repeatable data to a repeatable output without rebuilding a timeline every week.nn## The slide deck was hiding too many decisionsnnA slide deck looks simple at the end, but it hides a surprising number of decisions: which metric matters, which screenshot explains it, which sentence goes on the title slide, whether a chart needs a caveat, and how long someone should spend explaining the update.nnThe problem was not that people made those decisions. The problem was that we made them again from scratch. The recurring format had no durable structure. If the person who made last week's deck was busy, the next version changed shape.nnA video job queue forced me to write down the repeatable parts. Each job had a reporting period, data source, audience, selected metrics, media references, short narrative, template version, and output destination. That was enough to make the workflow inspectable before a single frame existed.nn!Structured business data cards feeding a reusable short video blueprintnn## I separated data assembly from video assemblynnThe first phase became data assembly. A small script or workflow gathers the approved metrics, selects the supporting image or chart, and creates a draft record. The record is not a video file. It is the explanation of the video we intend to make.nnFor a customer recap, the record might include product usage, an outcome statement, a chart image, and a next action. For an internal update, it might include pipeline movement, release notes, and a small risk callout. The exact fields change, but the idea does not: the source material should exist before the creative assembly begins.nnThat also made me more honest about weak updates. If the narrative field was empty, the problem was not the video renderer. We did not yet have a useful story to tell.nn## The template became an operating boundarynnI keep the visual rules in a template: opening frame, metric scenes, supporting media slot, closing action, aspect ratio, font, motion rules, and caption style. The job record fills the allowed fields.nnThat is a good balance for recurring work. It keeps the output recognizably consistent, but it still allows the week to have its own facts. I do not need someone to decide where the title goes each time. I do need someone to decide whether this week's metric is meaningful enough to lead the story.nnVideoFlow's core builder can define those scene rules in TypeScript and compile them into VideoJSON. That JSON is useful because it becomes the portable source of truth. I can store it, compare revisions, let another tool inspect it, or send it to a different renderer without translating the video into a new format.nn## I added a small approval lane instead of a big meetingnnThe queue did not remove review. It made review smaller. Each draft enters a preview_ready state with the data summary and a live preview. The reviewer does not have to comment on every transition. They answer a few clear questions: are the numbers right, is the takeaway fair, is the selected media appropriate, and is the next action useful?nn!Approval lane with live video preview and a clear final render decisionnnIf a change is needed, the job returns to the draft stage. If it is approved, I freeze the VideoJSON snapshot and send that snapshot to rendering. That small separation avoids an annoying problem: a reviewer approves one draft while a late edit changes the version that actually renders.nnThe approval lane also gives each failed job a clear next move. Missing metric? Fix the data source. Awkward copy? Edit the narrative field. Wrong image? Replace the asset reference. A generic “render failed” state does not tell anyone what to do.nn## I choose the renderer based on the jobnnFor a short, one-off update, browser rendering can be a practical path. It keeps the work close to the person exporting and can avoid a server job. For recurring customer recaps or a larger weekly batch, server rendering makes more sense. The queue can send approved jobs to a backend renderer and keep status updates visible to the person who requested the output.nn!Scheduled recap video jobs moving through a server queue toward completed delivery cardsnnThe key detail is that both paths receive the same approved VideoJSON. That makes the workflow less dependent on where the render happens. The preview, the browser export, and the server batch all start from the same structured project.nn## Trade-offs I acceptednnThis approach requires a little setup. You have to choose a template, define the job fields, and decide what the review state means. It is not worth it for a single handmade launch film. A traditional editor can still be better for expressive, one-off creative work.nnBut for recurring updates, the queue has made the process calmer. The data appears before the video work begins. The review is focused. The output can be reproduced. And the weekly update no longer depends on who remembers the last slide deck.nnMy next improvement is simple: I want to add a few more template fields for localization and audience level while keeping the core story stable. The useful lesson has been that a recurring video does not need more creative freedom. It needs a better place to hold the decisions that repeat.