Video editing project management: track every edit from intake to sign-off

Video editing project management is the job of tracking each edit as its own object: where the footage came from, who is cutting it, which version a reviewer actually watched, how many revision rounds are left, and whether the cut is approved and paid. A pipeline decides the stages work passes through. This is the layer underneath it — the state of one edit at one moment.

If your team already has stage names and handoff rules, you have the pipeline half. This article is about the card-level half, which is where most editing deadlines actually die: an unassigned card, a note buried in a DM, a second file called final, an invoice nobody chased.

Why an edit doesn't behave like a normal task

Three properties separate an edit from a generic to-do item, and each one breaks a tracker that ignores it.

• The input isn't a document. A task usually starts with a brief or a file. An edit starts with a pile of footage, a script or voiceover, and an export spec. If the tracker only holds a title and a due date, the editor still has to go hunting before they can start.
• Feedback is version-bound. "Change the music at 0:42" means nothing unless you know which cut was being watched. Notes that aren't tied to a version create a second round that repeats the first.
• Done is two states, not one. Creatively approved and paid. Teams that collapse these into a single checkbox ship the file, then spend six weeks asking about the invoice.

If your team hasn't agreed what "in review" means yet, fix that first — how to set up a video editing team workflow chart covers the stage-and-role layer. Everything below assumes the stages already exist.

The per-edit record: six fields worth maintaining

You can hold these as card fields, labels, or the first six lines of the card description. What matters is that they sit on the edit itself, so anyone can answer "where is this?" without asking a person.

Intake: one card per edit, and no local file paths

Intake is where editing weeks are lost, and the missing piece is rarely skill. It is the brief, or the one shot that lives on the director's laptop. One card per deliverable keeps that in one place: card title as client, episode or campaign, and cut number.

Files attached to a card are stored in the workspace Drive, and drag-and-drop onto a card uploads into workspace storage. That means the raw folder, the cut, and the export can all sit on the same card without a copy on anyone's desktop. A local path on someone's machine isn't a handoff — it's a promise to send a file later.

Scripts belong on the card too. You can write one as a document in Playground > Script writing, or paste an existing script into the description. Audio and video files can't be attached to a chat message, so voiceover recordings go to the Brain, where they're transcribed automatically — the transcript becomes the reference an editor can work from without asking what you meant.

Before the editor opens the timeline, the card should pass a short check.

New edit intake checklist

Confirms a card is complete enough for an editor to start without a follow-up question, and prevents the round-one failures that come from missing specs or missing sources.

Ten minutes of intake prevents the two most expensive failures: an editor waiting on a brief, and a revision round spent on the wrong runtime.

Assigning editors without handing over the whole workspace

The guest tier is the right shape for freelance editors. Guests are free and don't count as paid seats, and a guest without the "view all cards" permission sees only the cards they're assigned to. So the scoping is two switches: the person's permission profile (Settings > Team, pick the editor, adjust the toggles) and the board's member list (from the board's settings).

Verify it once rather than trusting it. Create a test card, assign it to the editor, leave another card unassigned, and ask them what they can see. An unassigned card should be invisible to a scoped guest. The full setup is in how to give freelance editors access to only their assigned projects.

Drive access is a separate switch, and it's the one that catches teams out. The built-in Guest preset leaves the Drive page disabled, so an editor who can see their card may still be unable to upload a rough cut. Enable Drive for that guest, set Drive access to Editor, and share the intended folder — sharing files with freelance editors without giving full Drive access walks through it. Viewer access allows viewing, downloading and adding comments but not uploading. That's fine for a client, wrong for an editor who needs to deliver a file.

One notification detail worth knowing: assigning a card to someone else creates an in-app notification unless they've turned that preference off. It isn't an email, so don't build a deadline on it, and self-assignment notifies nobody.

Running revision rounds that close

Open the board card and use the "Review" action beside the attached media file or PDF. The review view supports timestamped comments and @mentions on videos and documents, and files keep version history: uploading a new version to the same file preserves the old ones, and reviewers can switch between them. That combination is what makes a round defensible — when someone says a note was already addressed, there's a version to check.

The mechanics matter less than the rules around them. One round is one consolidated pass inside an agreed window, and everything from that pass lands in the review tool, not in three different chat threads. The editor returns a numbered change list so each item can be closed. A note that changes scope becomes a new card rather than a round item. The round count lives on the card, where the client can see it.

Honest tradeoff: no annotation feature fixes a client who sends three contradicting notes. A single named approver and a printed cap on included rounds fixes more than any review tool. If your rounds never end, the problem is usually routing, not software — how to use Review in kloudboard covers the mechanics, and the round cap belongs in your contract, not in a settings menu.

Delivery and payment are two separate finish lines

Approval and payment are different events. Teams that merge them deliver work they haven't been paid for and pay for work they haven't approved.

On sign-off, mark which version is approved and treat that file as the delivered copy. If the client later wants a change to an approved cut, that's a new card with a new number, not a reopened round.

On payment, keep the states distinct. In kloudboard, payouts and withdrawals are open in the economy area, but individual wallets can still be held for review or be missing a payout method, so check the live wallet status rather than assuming. Use the actual payout preview for fees and method availability instead of estimating provider rates. A pending request, an approval, a submitted transfer and a confirmed settlement are four different states, and an approved ledger record is not proof that money was sent.

If you pay an editor outside kloudboard, you can record it as an external payment, but recording one doesn't move funds. Don't create or mark an external payment as paid unless you actually authorize that record and the payment happened.

Worked example: seven deliveries, three editors, one week

Assume each editor has 20 hours of editing time in a week once calls, ingestion and admin are removed: 3 × 20 = 60 hours. Assume a first cut of a 10-minute video takes 5 hours, and a revision round takes 1.5 hours, with two rounds as the average. That's 5 + (2 × 1.5) = 8 hours per delivered edit. 60 ÷ 8 = 7.5, so plan seven deliveries, not the twelve that the first-cut number suggests.

That gap is the point. Capacity for first cuts alone looks like 12 (60 ÷ 5), which is why teams promise twelve videos and deliver eight. Revision rounds are what actually cap the week. If you plan to full first-cut capacity, round two has nowhere to go.

A Wednesday snapshot of the board might read: three cards in cut 1, two in review, one in revision round 2, one delivered and waiting on payment. Seven cards, three editors, no ambiguity about which cut is live.

Those numbers are illustrative, not benchmarks — replace 5 and 1.5 with the averages from your own last ten edits before you use them to quote a client. And if a client sends notes four days late, that revision collides with next week's first cuts. That collision is the argument for putting the feedback window on the card, not in an email signature.

What to do next: take the next edit that lands and put the six fields on its card before assigning it. Assign the editor as a guest, confirm they can see the card and not the unassigned one beside it, run one review round through the Review action, and record the payment state when it's settled. If that works once, the card is your template — and the second week is faster than the first.