What I built at Quad Lock

Media Assets & AI Automation Coordinator · October 2024 to June 2026 · iconik · three days a week

Iconik Bot, and why adoption stopped being a problem

A system nobody opens is a system that failed. So the library stopped being a destination and became something you could ask a question of, in the place people already worked.

The system existed because people used it

The position description, against what I have done

Video Asset Management and Governance

• Audit before design. Volume, duplication, orphaned assets and rights-field coverage, reported as numbers. At Quad Lock the manual pass is what produced the schema, so I would not set a taxonomy before seeing the library
• A folder structure and asset hierarchy that carries ingest and permissions, and faceted metadata that carries discovery. A clip can belong to a destination, a trip, a range, a year and a campaign at once, so the hierarchy should stop being the way people find things
• Governance written as the upload rule, not a separate policy document. Adoption is the benchmark, so the standard has to sit where the work happens
• Put the first metadata where the asset is made. At Quad Lock editors set keywords in Lightroom before export, and the AI tagger fell back to those whenever its own confidence was low. Metadata captured at source is cheaper than metadata recovered later

Business Requirements and Stakeholder Partnership

• Watch people search rather than survey them. The gap between the documented process and the actual behaviour is where the requirement is
• Document each requirement and confirm it back with a named owner before building against it
• A fixed reporting cadence carrying options and trade-offs, not status alone
• Pilot narrow, then open up. Iconik Bot ran with the production team alone for the first weeks, and only went to the whole content team after a month of refinement

Video Workflow Optimisation

• Standardise the handover as intake: one brief format, required fields, one review link, versioned feedback, a locked approval
• Separate review proxies from edit proxies. Review proxies serve search and approval; edit proxies must relink to camera originals by clip name and timecode
• Hold the handover in the project management system as a template with required fields, so the process is the tool rather than an email thread
• Put editors and the people briefing them on the same artefact. Most friction between an edit team and its stakeholders is two groups looking at different versions. One review link with versioned comments removes that argument rather than managing it

Improvement and Innovation

• Inventory every tool, seat and subscription against owner, cost, renewal date and actual usage
• Dormant seats first. Per-user pricing makes inactive accounts the cleanest saving available and the least disruptive to propose
• Check what the platform already covers natively before adding anything, then assess overlap across review, transfer, transcription and publishing
• Automate only where accuracy can be measured. At Quad Lock no field wrote back unattended until it cleared a confidence threshold, and hallucination was monitored continuously rather than assumed away
• Look at how seats are actually consumed. If most people only ever request an asset, a shared request path can serve them without a full seat each

Documentation and Backup

• SOPs held in Linear, so each one carried its own change history: what was added, removed or improved, and why. Version control is what stops documentation quietly going out of date
• Screen-recorded walkthroughs for every tool, because short video is what people actually watch, and runbooks a non-developer maintained

• Split it four ways rather than writing “documentation”. Tutorials, how-to guides, reference and explanation are four different jobs, and mixing them is the usual reason documentation goes unread. Canonical, Cloudflare and Gatsby all organise this way
• Reference is the part most teams never build: a metadata data dictionary giving every field a definition, a controlled vocabulary, whether it is mandatory, who sets it and at which pipeline stage. Alongside it, the taxonomy register, the naming convention standard, a rights and usage matrix, and a retention and archive schedule
• How-to is the Quick Start Guides you asked for. One page per task, written by role rather than by feature, plus a workflow chart for every handover, because a diagram settles a process argument faster than a paragraph
• Build the FAQ and knowledge base from the support log rather than from what we imagine people will ask. The repeat questions are already being asked somewhere, and that list is the table of contents
• Tutorials are onboarding: day one, week one, month one, plus the screen recordings. Explanation is the governance charter, a RACI, and a decision log so the next person does not relitigate settled choices
• Then treat it as a living system: a fixed quarterly review, a change-control route for adding a taxonomy term, and a channel for people to report friction

Any AI I introduce sits inside your own policy

Your Responsible Marketing & PR Policy, published July 2026, added dedicated sections on AI and digital integrity, truthful communications and climate honesty.

The first ninety days, in order

The roadmap is already defined. This is how I would get to its first decision with evidence rather than assumptions.

Twelve months means every decision is designed for handover: a named owner, a written standard, and a review date.

The measure I would hold myself to is that it still works six months after the contract ends. I have handed a system over once already. That is the part most implementations get wrong, and it is the part I would plan for from week one.