Content production workflow: configure the board, routing and handoffs

A content production workflow is the rule set that decides how a piece of work moves: which column it enters, who owns it at each stage, what must be true before it advances, where the file lives, and who finds out when it moves. A pipeline is the sequence of stages for one asset — script, shoot, edit, review, publish. The workflow is what makes that sequence repeatable across twelve assets and three clients without anyone asking where a card is.

Most teams already know their stages. What they lack is routing. Work sits unassigned, files live in three places, and review happens in messages nobody can search later. This article is the configuration layer underneath the process theory: board structure, handoff rules, and triggers, written for the person who actually sets the system up.

If you are still deciding on the stages themselves, start with the broader creative agency workflow and come back here to implement it.

A production workflow answers six questions, not one

Before touching a board, write down your answers to these. Each one becomes a column rule, a field, or a trigger.

1. What counts as a unit of work — a video, a campaign, a client month?
2. Who owns a card from the moment it enters production to the moment it is delivered?
3. What must exist before a card can move forward (a brief, a file, a due date)?
4. Who reviews internally, and who reviews externally?
5. Where does the file live, and what is it named?
6. What state tells you a card is blocked rather than in progress?

If you cannot answer question six, your board will accumulate cards that look busy and are actually stuck. That is the most common failure in a production board, and no number of columns fixes it.

Board structure: six columns, four fields, three labels

Columns are stages that require a different person or a different file state. If a column changes neither, it is decoration and it will drift out of sync within a month. A working set for a video or content team:

• Brief — intake. Client field and due date are required here.
• Production — script, shoot, or edit. One owner.
• Internal review — producer or senior editor checks the file.
• Client review — the round is open, feedback is being collected.
• Approved — decisions recorded, no further changes without a new round.
• Delivered — published, sent, or invoiced.

Four fields carry most of the routing weight: Client, Owner, Due date, and Round (a number you increment each time client feedback reopens the work). Use Format as a label — short, long, clip, thumbnail — so you can filter without a field. Three labels is usually plenty; a label taxonomy that mirrors your columns just duplicates them.

Card boards, custom fields, labels and automations are covered in more detail in the project boards overview.

Worked example: three clients, 12 deliverables a month, two freelance editors

The numbers below are illustrative, not benchmarks — treat them as a shape to copy, then replace them with your own timings.

Assume a small studio: one owner who produces and edits, two freelance editors invited as guests, three retainer clients, and 12 deliverables per month (three a week plus buffer). Here is the routing that keeps it stable.

Rule 1: one card per deliverable, never one card per client. A card called "Acme — October" cannot be reviewed, versioned, or approved. A card called "Acme — Product X launch, short 04" can.

Rule 2: assignment is what grants access. A workspace owner, or a member with the view-all-cards permission, sees every card. A guest without that permission sees only the cards they are assigned to, and that is enforced server-side. It has a workflow consequence people miss: an editor cannot browse the Brief column to pick up work, because unassigned cards are invisible to them. Assignment has to happen before visibility, not after. If you want editors choosing their own work, you need a different permission setup, and the tradeoffs are set out in giving freelance editors access to only their assigned projects.

Rule 3: a card may have exactly one owner at a time. Two assigned editors means nobody believes they own it. Handoffs are explicit: unassign, reassign, move.

Rule 4: no file, no review. The card does not enter Internal review until the current cut is attached to it. Reviewers then open the card and use the Review action beside its attached media file or PDF, which supports timestamped comments and @mentions on videos and documents. See how to use review for the mechanics.

Rule 5: the round number is part of the card. Client round one is the notes from the first viewing. Round two starts only after the editor has addressed every numbered item. When Round reads 3, that is a scoping conversation, not a workflow problem.

File handoff rules: where the file actually lives

Files attached to a card are stored in the workspace Drive, so a draft an editor uploads to a card also lives in Drive and can be reorganized there without breaking the card link. That single fact collapses most handoff confusion: the card is the context, Drive is the filing system.

For guests, uploading is a permission decision, not a default. In the team settings you choose the guest, enable Drive, and set their Drive access to Editor, then share the intended folder with them in Drive. Two details matter:

• The built-in guest preset leaves the Drive page disabled, so check the saved settings rather than assuming.
• Drive Viewer access allows viewing, downloading and commenting — but not uploading. Sharing a folder with a Viewer does not upgrade them to Editor. The step-by-step is in sharing files with freelance editors without full Drive access.

Versioning is the other half of the rule. Uploading a new version to the same file preserves the earlier ones and reviewers can switch between versions, so the convention should be a new version of the existing file, not a new file name. A workable naming pattern:

client_project_format-sequence_vNN.mp4 — for example acme_launch_short-04_v03.mp4. The card holds the context; the file name only has to be sortable and unique. If you are handling camera originals as well as cuts, extend the same scheme with a shoot or date segment.

Automation triggers: automate the move, verify the state

kloudie builds automations from a chat description of the form "when X happens, do Y"; you approve them before they run and they appear in the Automations area. The practical way to find your first three is to list the manual moves you make every week. Typical candidates in a production board:

Three honest constraints to design around:

• Notifications are in-app, not email. Assigning a task to someone else creates an in-app notification unless that person has turned off the added-to-card notification preference; self-assignment does not notify you. Do not build a workflow that assumes an email will prompt anyone.
• There is no continuous sync with Slack, Discord, WhatsApp or Telegram. Discussion belongs in the workspace chat channel tied to the work. If your team lives in another chat app, the workflow still has to have a home inside the workspace, or the state and the conversation will diverge.
• Automations can fight humans. Decide that a trigger may change status or assign a person, but never closes or deletes work on its own. The person who manually corrects a card should not have to fight a rule that moves it back.

If you want an external system to start a chain — a form submission, a client CMS, an internal script — a webhook-triggered automation gets a hook URL and a secret, and the sender posts JSON to that URL with the secret in the X-Hook-Secret header or a secret query parameter. Two things to know: a wrong recipe id or a missing or wrong secret deliberately returns a 404 rather than a helpful error, and deleting and recreating an automation rotates both the URL and the secret. If a webhook starts returning 404, fetch the automation's current hook URL and secret rather than debugging the sender. The Automations area is described at automations in kloudboard.

Parallel tracks: one board per client, or one board with a client field?

One board per client is easier to reason about and easier to restrict to a member list. One board with a Client field is easier to see across the studio and cheaper to maintain when clients churn. The deciding factors:

• If clients need to see their own work and nothing else, and you invite them into the workspace, per-board restriction plus assignment scoping does the job either way.
• If you need a single view of this week's load across every client, use one board and filter by the Client field.
• If your deliverables differ radically per client (a podcast client and a short-form client), two boards are clearer than one board with twelve columns.

The number that decides how many tracks you can actually run is capacity, not preference. Each client track consumes a fixed number of hours per week, and that is arithmetic you can do before saying yes to a fourth client.

Parallel client track estimator

Work out how many client production tracks one person can carry before adding another client.

Each client track consumes deliverables per week multiplied by hours per deliverable. Divide available production hours by that figure and round down for complete tracks.

Assumptions: Illustrative workload inputs, not measured benchmarks. Assumes one person carries both production and coordination, and that each client track needs the same weekly volume. Excludes review waiting time, admin, and unpaid pitch work.

Worked example: Production hours available per week: 24 hours; Deliverables per client per week: 2 deliverables; Hours per deliverable: 3 hours. Client tracks supported in parallel: 4 active client tracks.

Verify with one deliverable before you scale

Do not migrate three clients onto a new board at once. Run one deliverable end to end and check three things afterwards.

One: the card had a single owner at every stage, and the handoffs happened on the card rather than in a message. Two: the reviewer opened the attached file through the card, and their notes landed as comments on a specific version. Three: the approval state is still readable a week later — you can answer "what did the client approve, and when?" without opening your mail.

If all three hold, the second client is a copy of the board and a new Drive folder, not a redesign. If any of them failed, the fix is almost always a rule you skipped: an unassigned card, a file attached after the move, or a review that happened in a message. Correct the rule, run one more deliverable, and only then widen the scope.