The Preditor workflow: operationalizing producer-editors

Company

Ovation TV

Role

Digital Content Manager

When

2017 to 2019

Scope

Internal SOP for producer-editors

Overview

Ovation called its producer-editors "Preditors." They sat at the intersection of two roles that are usually separate: they produced the content and they cut it. The output flowed to the social team, to the OTT side (including the Journy AVOD launch), to the archive, and to whoever else needed clips. The team was small and the schedule was busy.

I built the standard operating procedure that made the Preditors' output predictable: how they named files, how they structured project folders, how they handed work off to the social drop. The SOP looked small. The downstream consequences were not.

The problem

Creative teams left to their own conventions invent their own conventions. That works when there's one person on a project. It stops working the moment a second team has to pick up the output, and it falls over completely when a third team is searching the archive a year later.

The symptoms were familiar:

• Files with whatever name made sense to the editor at the time
• Project folders with whatever structure the editor remembered
• Social team asking the editor what a file was because the name didn't tell them
• Archive searches that returned things that looked right but weren't
• OTT scheduling pulling the wrong cut because the convention was "version 2" except when it was "version 2 final" except when it was "v2_use_this"

None of this is dramatic. All of it costs time, and all of it compounds.

Context

• Preditors needed a workflow that didn't slow them down and gave them clear handoffs.
• The social team needed to be able to grab a clip and post it without asking what the file was.
• The OTT side needed to schedule the right cut for Journy and the FAST partners.
• The DAM team needed metadata they could trust at ingest.
• The archive needed file names that meant something a year later.

My role

I designed and rolled out the SOP, and I owned the relationships with the teams who would consume the Preditors' work:

• Defined the naming convention so a file name carried the metadata that downstream teams actually needed
• Defined the project folder structure so anyone opening a project knew where to find footage, music, outputs, and stills
• Defined the handoff to the social master drop, with approval and delivery steps
• Documented the SOP in a form the team would actually read
• Walked the team through it, gathered feedback, and iterated on the parts that didn't fit how the work actually got done

The naming convention

The convention encoded the things downstream teams kept asking about. A file name carried: department, type, year, sequence, category, destination, and title. Real example structure looked something like:

DS-NV18038CUL_FB_Top Facsinators/Hats
│  │ │ │ │  │  └─ Title
│  │ │ │ │  └──── Destination (Facebook)
│  │ │ │ └─────── Category (Culture)
│  │ │ └────────── Sequence (38)
│  │ └──────────── Year (2018)
│  └────────────── Type (NV)
└───────────────── Department (DS)

Once a file was named, every downstream team could parse it without asking. The social team knew where it was supposed to go. The DAM knew what category to file it under. The archive knew what to keep.

The folder structure

Every project used the same skeleton:

• FOOTAGE — raw source media
• MUSIC — score, tracks, licensed audio
• OUTPUTS — finished cuts, ready for handoff
• PROJECTS — the actual editor project files
• STILLS — graphics, screen captures, freezeframes

Anyone opening a project (the Preditor returning after a week, a colleague picking up a sick day, the DAM team archiving a closed project) knew exactly where to look for what.

The handoff

The last step in a Preditor's workflow was an approval check and a delivery to the social master drop folder. The act of "moving a finished cut to the master drop" was the trigger for the social team to act. Before the SOP, the trigger was a Slack message, which sometimes got missed and sometimes got sent twice. After the SOP, the file's existence in the drop was the trigger.

Product decisions and trade-offs

• Metadata by convention, not by tagging. Tagging requires a tool, a moment of focus, and a habit. Convention encodes the metadata in the name itself, which the Preditors had to type anyway.
• One folder skeleton, no exceptions. The temptation was to let each project type have its own structure. The simpler answer was one skeleton with empty folders that just stayed empty when not needed.
• The drop folder as a contract. Moving a file into the drop folder is an action with a meaning. Treating it that way removed an entire category of "wait, was that ready" exchanges.
• Write the SOP like a person, not like a spec. The SOP read like an explanation, not a checklist. That's the version Preditors actually used.

Outcomes

Less time spent answering "what is this file" questions. Cleaner archive. Cleaner social workflow. The OTT and DAM teams had consistent metadata to work with at intake, which made the larger digital workflow chart less fragile.

The SOP also outlasted me at the company. Conventions that get adopted because they make the day-to-day easier tend to stick.

What I learned

The smallest part of the operation is usually the most leveraged. A file name is a one-second decision. The downstream consequences of a wrong one compound across every team that touches the file.

Write SOPs in a voice people will read. A document that sits on a wiki and never gets opened is a document that doesn't exist.

Trigger actions, not messages. Replacing "ping me when it's ready" with "drop it here when it's ready" took a category of human error out of the workflow.

---

Back to all work