Systems you keep when the editor leaves
When a supplier leaves, everything they knew leaves with them, unless it was written somewhere that was not their inbox.
Somebody takes a full time job, raises their rates, or simply stops replying. The next person arrives and asks you the things the last one had already learned, and you spend a month rebuilding a working relationship you thought you owned.
The files come back, if you asked for them properly. What does not come back is the knowledge: that your name has an accent on it, that you never want music under the section explaining how the memberships work, that the intro has been cut down twice and does not need cutting again, that Thursday is your review day because Wednesday is teaching.
That knowledge is an asset, it is yours, and almost nobody writes it down. Six things survive a change of supplier if you build them, and one is worth more than the other five.
What actually walks out of the door?
Not the footage. The working knowledge.
A supplier accumulates a great many small decisions about you in a year, and most were never stated as rules. Corrections you gave once, preferences they inferred from what you approved, habits built around your calendar. All of it lives in one person's head and in a message thread you cannot search.
It feels like bad luck rather than a design fault because it only shows up on the day somebody leaves. Until then the system works, because a person who remembers is holding it together.
What survives if you build it?
Six things, in rising order of value.
A file naming convention. One agreed pattern, used by everybody, forever.
A folder structure. The same shape every project, so a new person finds the audio without asking where the audio is.
A shared tracker. One row per video, showing its state and who is holding it.
A stated review flow. Who watches, in what order, by when, and who sends the notes.
An archive rule. What is kept, where, for how long, who can reach it, and what is never deleted.
A preference document. Every preference you have ever had to explain, written as a standing rule.
The first five are hygiene and can be copied from anybody. The last is genuinely yours, and it never gets built, because each entry feels too small to write down at the moment you say it out loud.
Why does a naming convention do more than it looks like it does?
Because it decides whether a folder can be read by somebody who was not there.
Date first, in a form that sorts correctly, then the series or subject, then what the file is, then the version. Everything else is preference. What matters is that it is one pattern rather than four, and that it survives the person who thinks their own system is better.
The test is not tidiness. It is that a file found on its own still says what it is. A folder of clips named after the day somebody exported them gets watched from the beginning by whoever inherits it, and you pay for those hours without ever seeing them itemised.
What goes in the preference document?
Anything you have had to say twice.
How your name and your business name are spelled and pronounced. Terms you never abbreviate. The claim you are not allowed to make and the phrasing you use instead. Music you will not have. Whether the intro returns at the end. What a thumbnail must never do. Which day of the week you can actually review things.
Each looks trivial alone. Together they are the difference between a new supplier being useful in a week and useful in a quarter, and they are the whole content of the conversation you dread having again.
How do you write it without setting aside a day?
You do not write it. You accumulate it.
Every time you give a note, ask one question first: is this about this video, or about all of my videos. If it is about all of them, it goes in the document as a rule, in the words you just used, with the date next to it. The note still gets sent. The rule outlives it.
And a rule that has stopped being true gets struck through, not kept out of loyalty to the day you wrote it. A brand loosens, a thing you once banned becomes the thing you do, and the document is meant to move with that. You are building a foundation that keeps changing, not a rulebook that freezes the version of you that existed in March, and that difference is the whole point: the first frees the next person to work, the second makes them re-enact your old taste.
Doing that for a few months produces something no consultant could have written for you, because it is made of the corrections you actually had to make. It is the cheapest insurance available against the day somebody leaves.
What does the archive rule say?
That superseded work is archived rather than deleted, that anything with a legal life attached is stored where you can reach it, and, written beside each of those, how long it is kept and who can get to it. A stated retention period stops the archive being kept forever by accident or wiped by surprise, and a named point of access stops the whole store depending on one person still working with you.
Old versions cost storage and nothing else. Deleting them feels tidy and is the reason people cannot go back when a change turns out worse. Music and stock licences are the sharper case: they belong per piece, in your own folder, with the video they were bought for and their own restrictions written next to them, what the licence covers, where it may run and for how long, so a copyright claim years from now is an afternoon of admin rather than an emergency involving a supplier you no longer work with. This studio saves them that way, into the partner's own folder.
What is the test?
What could a competent stranger pick up in a week without asking you anything.
Hand them the folder, the tracker and the preference document, and watch which questions still come back. Those questions are the holes, and they are a better audit than any checklist, because they come from the real gap between what you know and what you have written down.
That is also the line between buying deliverables and buying a system. Deliverables arrive, get published, and leave you where you started. A system means the next supplier starts where the last one finished, and it is the only part of this that appreciates. When that system is built with this studio, its brand half, the preference document written around your brand, is yours: it leaves with you at the end of a partnership whether or not you ask.
So the decision worth making this week is small with a long tail: open a document, write the last three notes you gave as rules rather than requests, and put today's date next to them.
Keep reading
This is a service, and the method is written down.
Everything above came out of doing the work rather than writing about it. If you want the method instead of the story, it runs in order on one page.
Start with a free audit
Tell us where your content is now. We will come back with what we would change and what result to expect.
A person reads the channel and writes the audit by hand: a considered read typically takes three working days. That is the usual shape, not a promised turnaround. We use these details only to reply to you: no lists, no lurking.
What you will get
A fit snapshot: where your channel stands, and whether we are a match.
Two to three opportunities: specific, prioritised, yours to keep.
A recommended next step, even if that step is not us.
The audit is free and commits you to nothing: nobody follows up with a call you did not ask for.