glamforyu
What Does a Live Production Workflow Review Actually Involve?
Journal Workflow

What Does a Live Production Workflow Review Actually Involve?

Clients ask us this more than anything else. Daniel Pryce answers it plainly: what we read, what we watch, what we write down and what you receive at the end of a review.

Daniel Pryce 6 minutes to read

The question we hear most often

Almost every first conversation with a new client reaches the same point. A production manager says they know their programme has weak spots, but they cannot say where, and they ask what exactly happens when they commission a workflow review from us. It is a fair question, because the word review can mean anything from a quick chat to a formal audit.

Here is the short version. A review is a written document about how your live programme runs from the first line of the running order to the last fade. It describes what is in place, where a live broadcast could stumble, and what to change first. It is not a rebuild of your studio, and it does not replace your editorial judgement about the show.

I write these alongside Helen Marsh, who leads the planning side, and I read each one as a studio engineer would: with an eye on what the equipment and the people in the room can realistically do under pressure.

What we read before we visit

Before anyone travels to Dorchester or to your building, we ask for the paperwork you already use. That usually means a recent running order, the script or rundown format, any cue sheets, the contact list for the crew and a note of what has gone wrong in the past. Messy documents are welcome; we would rather see what the team really works from than a tidied version.

Reading these first lets us arrive with specific questions instead of general ones. A running order that places two live links back to back with no buffer tells us something. So does a cue sheet that only one person can interpret. We note these quietly and bring them up on the day rather than guessing at the reasons.

If a document does not exist, such as a written fallback plan, that is a finding too, and we record it as plainly as anything else.

  • A recent running order or rundown
  • Cue sheets and any talkback notes
  • The crew list and who covers each role
  • A short account of past live problems

What we watch on the day

The visit itself is mostly observation. We sit in the gallery during a rehearsal or, where you agree, a live transmission, and we follow how instructions travel: who calls the shots, how cues reach the floor, how graphics and playout are triggered, and what is said when something is late. We keep a timeline of moments where the team had to improvise.

We try not to interrupt. Crews behave differently when someone is hovering, so we stay at the back with headsets on and a notebook. Afterwards we talk to each role separately, because the vision mixer, the floor manager and the producer often describe the same minute of a programme in three different ways.

Those differences are rarely a sign of poor work. More often they show a handover that was never written down, and that is exactly the sort of gap a review exists to find.

Fallbacks: the part most teams have not written down

Ask a gallery what happens if a remote guest drops out and nearly everyone can answer aloud. Ask to see it on paper and the page is often blank. Experienced crews carry a great deal of fallback knowledge in their heads, which works until the one person who holds it is off sick.

In the review we go through the likely failures one by one: a lost guest feed, a playout clip that will not roll, a camera fault, a late presenter, a talkback line that goes quiet. For each, we ask what the team does in the first ten seconds and who decides.

We then write those answers into a short procedure, in plain sentences, ordered the way a stressed person would need to read them. The aim is a card that can sit on the desk, not a manual that nobody opens during transmission.

  • Guest or remote feed failure
  • Playout clip not rolling
  • Camera or vision fault
  • Presenter late or unavailable
  • Loss of talkback

What you receive at the end

The deliverable is a written report, usually a few pages long. It opens with a summary of what works well, because there is always something, and then moves to findings in order of priority. Each finding says what we saw, why it matters on air, and what we suggest. Suggestions are small and practical wherever possible: reword a cue, move a buffer item, assign a named backup.

If a finding points to equipment, lighting, camera positions or room sound, we say so and say which of our specialists would be the right person to look at it, but we do not add work you have not asked for. The report is yours to act on with your own team.

We are happy to talk it through on a call afterwards, and the price and scope for a review are set out on the Prices page, with the written quotation following your enquiry through the contact page.

What a review will not do

It is worth being clear about limits. A review will not promise that nothing will ever go wrong on air; live television does not work that way, and anyone who says otherwise is selling comfort. What it can do is reduce the number of surprises and shorten the time your team takes to recover from the ones that remain.

It also does not judge editorial choices, such as which stories lead or which guests you book. Our concern is whether the machinery around those choices behaves dependably. Nor is it a staffing assessment: we describe how roles connect, not whether individuals are good enough.

Finally, a review is a snapshot. If your studio, crew or format changes substantially, the findings may no longer fit, and it is sensible to revisit the document rather than trust it indefinitely.

So, to answer the question directly: a workflow review is a careful reading, a day of quiet observation and a short written report that tells you where your live programme is fragile and what to do about it first. If your running order and fallbacks have never been looked at by someone outside the gallery, it is a sensible place to begin. Write to us through the contact page and we will start with a conversation.

About the author

Daniel Pryce

Studio Systems Engineer

Daniel designs and tests equipment integrations, from cabling to intercom, and documents every build clearly.

Send us a message