Services
Your automation was built for a different era. Your newsroom has moved on.
When you move to a story-centric NRCS, your gallery automation code doesn't come with you. It was built around outputs — specific shows, specific galleries, specific scenarios. A story-centric world needs automation built around content. We audit, redesign and rebuild your automation so it works the way your newsroom needs to work tomorrow.
$23.5M in annual savings.
178 roles freed up.
One engagement.
What is StoryCentric Automation
From thousands of special cases to a universal system
StoryCentric Automation Conversion is the process of taking an existing gallery automation codebase — built over years around specific outputs, shows and galleries — and redesigning it from the ground up around content.
The goal is simple to state and difficult to execute: any story, in any rundown, should be able to trigger the correct automation behaviour without requiring show-specific code. A name strap should work the same way whether it appears in the morning bulletin, the primetime news, a breaking news flash, or a digital-first output. A package should play out correctly regardless of which gallery it runs in. A graphics element should render properly whether it was built by the evening team or the breakfast team.
This requires moving from an output-centric philosophy — where the code is organised around "what show is this for?" — to a story-centric philosophy — where the code is organised around "what type of content is this?"
The difference is transformative. Instead of thousands of templates, each hardcoded to a specific context, you end up with a much smaller set of universal elements that adapt to their output context automatically. Instead of gallery directors maintaining parallel codebases for every show, you have a single system that serves all outputs. Instead of adding complexity every time a new show launches, you have an architecture that scales without growing.
In one project, we reduced a codebase of 4,500 automation templates to just 450 universal elements — a 90% reduction in complexity — while increasing the number of outputs the system could serve.
4,500 templates became 450 elements. More outputs. Less complexity. That's what story-centric automation looks like.
Our Approach
Journalists first. Then technology. Then the gallery.
Most automation work is done by the automation vendor or the system integrator. They know their product. They don't know your newsroom. They'll configure the system to technical spec — but they won't ask the journalist why they need a specific lower third to behave differently in a breaking news context, or why the sports desk needs graphics templates that the general news team doesn't.
We start where nobody else does: with the journalists.
We sit with your editorial teams first.
Before we look at a single line of automation code, we study the editorial workflows. What types of stories do you produce? How do they flow between outputs? What graphics elements do journalists need inside their rundowns? Where do they hit friction with the current automation? What editorial decisions are being constrained by automation limitations they may not even be aware of?
Then we work with your technology teams.
We study the existing automation codebase in detail — every template, every custom control, every macro, every workaround. We map what each element does, which shows depend on it, and where the technical debt has accumulated. We assess the automation platform itself: Ross Overdrive, Viz Mosart, or whatever system you're running — and we evaluate its capabilities and limitations in the context of your story-centric objectives.
Then we sit with your gallery directors and technical directors.
These are the people who live inside the automation every single day. They know which workarounds are load-bearing, which templates are never used, and which customisations would break the show if they were removed. Their operational knowledge is irreplaceable — and it's frequently ignored by technology-first conversion projects.
Only after understanding all three perspectives — editorial need, technical reality, and operational experience — do we design the new automation architecture.
The Process
How it works
Phase 1
Automation Audit
We perform a complete audit of your existing automation codebase. Every template, every custom control, every MOS command, every gallery-specific override. We document what each element does, which outputs depend on it, how frequently it's used, and where redundancy and technical debt exist. The result is the first complete picture of your automation landscape — often the first time anyone has seen it mapped in its entirety.
Phase 2
Editorial Requirements
We work with journalists, producers and editorial leadership to understand what the automation needs to deliver in a story-centric world. What types of content need to flow between outputs? What graphics elements need to be journalist-accessible inside the rundown? Where does the current automation create friction or prevent editorial flexibility? This phase defines the editorial objectives that the new automation must serve.
Phase 3
Architecture Design
We design the new automation architecture: a universal element system built around content types rather than output types. We define how each element adapts to its output context, how graphics are triggered from the rundown, how multi-gallery and multi-output setups are handled natively rather than through workarounds. We present this design to editorial, technology and gallery teams for review before any code is written.
Phase 4
Build & Test
We build the new automation elements and configure them within your automation platform. We test extensively in a non-live environment — first in isolation, then integrated with your NRCS, graphics systems and playout chain. Gallery directors and technical directors are involved in testing from the start, not presented with a finished product they haven't shaped.
Phase 5
Rehearsal & Transition
We rehearse the new automation with your gallery teams in realistic production conditions. We run parallel systems where possible — old and new side by side — so the transition can be validated before go-live. We support the first live shows under the new automation and stay until your teams are confident and stable.
4,500 → 450
Automation templates reduced by 90% through StoryCentric conversion — while increasing the number of outputs served
3 Perspectives
Journalists first, then technology teams, then gallery directors — every conversion starts with editorial need, not technical spec
Zero Downtime
Parallel testing and phased transition means your on-air output is never at risk during conversion
Standalone or Integrated
Available as an independent service or as part of a full newsroom transformation
Common Problems We Solve
If any of this sounds familiar, we should talk
Years of incremental additions — new shows, format changes, workarounds for multi-gallery setups — create codebases that only one or two people can maintain. A StoryCentric conversion replaces that complexity with a smaller, universal element set that any qualified automation engineer can understand and maintain.
When automation is built around specific outputs, content can't flow between shows without being rebuilt. StoryCentric automation is designed around content types, so a story works correctly in any output context — morning bulletin, primetime, digital, breaking news — without show-specific code.
That resistance is usually rational — they know the current system's fragility better than anyone. We involve gallery directors from day one, treating their operational knowledge as essential rather than optional. They shape the new system alongside us, which means they trust it when it goes live.
Output-centric automation often needs hacks to work across multiple galleries — duplicate codes, parallel command sets, gallery-specific overrides.
StoryCentric automation handles multi-gallery and multi-output natively, eliminating the workarounds that create fragility and maintenance overhead.In an output-centric system, every new show needs its own templates, its own custom controls, its own configuration. In a StoryCentric system, a new show reuses existing universal elements — dramatically reducing launch time and ongoing maintenance.
When GFX templates aren't accessible inside the NRCS and NLE, journalists depend on graphics designers for elements they should be able to create themselves — name straps, bullet points, social media quotes, simple lower thirds. We redesign the GFX template system alongside the automation to empower journalist self-service, freeing your graphics team for high-value creative work.
Standalone StoryCentric Conversion
You're migrating to a new NRCS or moving to a story-centric production philosophy and you need your automation rebuilt to match. We handle it as an independent engagement — from audit through design through build and go-live — without requiring a broader transformation programmer.
Part of a Full Transformation
StoryCentric Automation Conversion is one component of our end-to-end change management methodology. When we're redesigning your entire workflow — from system architecture through metadata design through organisational restructure and training — the automation conversion is integrated into the deployment phase alongside GFX template design, system configuration, and archive migration.
Standalone or Part of a Transformation
One service, two ways to use it
$23.5M in annual savings.
178 roles freed up.
One engagement.
GFX Template Design — A Natural Companion
Automation and graphics: two sides of the same coin
StoryCentric Automation Conversion almost always goes hand in hand with a GFX template redesign. The reason is simple: automation and graphics are deeply intertwined. The automation triggers the graphics. The graphics depend on the automation for timing, placement and data. If you redesign one without the other, you create new incompatibilities.
We audit your existing graphics operation — studying what your designers build, how frequently templates are requested versus custom graphics, and where journalists are bottlenecked waiting for graphics elements they should be able to create themselves.
In every newsroom we've studied, a significant proportion of daily graphics requests are for recurring types: name straps, bullet points, social media quotes, simple lower thirds, video wall images. These should be templates that journalists drag into their rundown or timeline, fill with text, and publish — without a graphics designer in the loop. That's faster for the journalist, better for brand consistency, and it frees your graphics team to focus on the complex, editorial-driven creative work where they actually add value.
We design the template system, build the templates, and integrate them with both the automation and the NLE — so that graphics work seamlessly whether they're triggered from a rundown line or placed directly in a video editing timeline.
Brief case study preview
StoryCentric Automation Conversion
90% complexity reduction
A gallery automation codebase that had grown to 4,500 templates over years of incremental additions — each one a special case for a specific show or output. We audited every element, redesigned the architecture around content types, and rebuilt the system as 450 universal elements. More outputs, less code, faster show launches.
A major UK broadcaster
Preparing automation for a story-centric future
Heavy use of Ross Overdrive Custom Controls had given the automation an output-centric flavour that conflicted with the organisation's story-centric transformation goals. Multi-gallery workarounds — duplicate command sets in every rundown line — were creating fragility. We audited the code, assessed platform capabilities against future objectives, and designed a conversion pathway.
Related Service
Specialist services
These capabilities are part of every full transformation engagement — but they're also available as standalone services for organizations with specific needs.
Let's get started
Ready to make your automation work for your stories?
Whether you're planning a full NRCS migration, moving to story-centric production, or simply trying to tame a codebase that's grown beyond control — we can help. Every engagement starts with a conversation about where you are, what's not working, and where you need to be.
The Problem
Output-centric automation in a story-centric world
Gallery automation is one of the most technically complex and least understood layers of a modern newsroom. It sits at the intersection of editorial decisions, graphics systems, camera control, and playout — and when it works, nobody thinks about it. When it breaks, the show stops.
The problem is that most existing automation codebases were built in an output-centric world. Every template, every macro, every custom control was designed for a specific show, a specific gallery, a specific output format. The morning bulletin has its own automation. The evening news has its own. The breaking news format has its own. Over years of incremental additions — a new show here, a format change there, a workaround for a multi gallery setup — the codebase grows into something that only a handful of people truly understand, and that resists any change to how the newsroom operates.
This is manageable — until you move to a story-centric architecture.
In a story-centric world, the fundamental unit is the story, not the show. Content needs to flow between outputs. A package built for the evening bulletin should be reusable in the morning show, on digital, on social — without being rebuilt from scratch. Different teams and shows need to be able to share and reuse rundown lines freely. The automation needs to support content adaptability: the ability for any piece of content to appear in any output context.
But automation code that was built around specific outputs can't do this. Custom controls that are bound to a particular show or gallery create rigidity exactly where you need flexibility. Templates that hardcode show specific behaviour prevent the kind of cross-output reuse that makes story-centric production work. And when the codebase has grown to thousands of templates — each one a special case, each one someone's workaround — the whole system becomes a bottleneck that slows down every editorial decision.
We've seen this pattern in newsrooms around the world. The technology team knows the automation needs to change but can't touch it without risking on-air stability. The gallery directors have learned to work within the constraints and resist modifications. The journalists don't understand why they can't just drag a story from one show to another. And the transformation stalls — not because of the NRCS, not because of the MAM, but because the automation layer hasn't caught up.
