Start with the problem you can describe
A review works best when it answers a question you can put into a sentence. Before you contact anyone, write down what is actually going wrong or what you are about to change. It might be intermittent dropouts on one camera feed, a control room that struggles when a second presenter is added, or a planned move to a larger set. Vague unease about the studio rarely produces a useful report, because the reviewer has to guess where to look first.
Try to record examples rather than impressions. A note such as picture freezes on the programme monitor about twice a week, usually during a graphics change, is far more helpful than the system is unreliable. If you keep a fault log, even an informal one, gather the last few months of it. If you do not, start one now; the pattern in it often points to the part of the chain worth examining.
- One sentence describing the problem or the planned change
- Two or three dated examples of faults or delays
- Any recent equipment or software changes before the issues began
Know what the review will and will not cover
A workflow review looks at how signals and people move through the studio, from sources through routing, mixing, monitoring and playout, and writes up what could be improved. It is an assessment, not an installation. Decide in advance whether you want findings only, or findings with a ranked list of changes you could carry out yourselves or hand to a contractor.
It also helps to say what sits outside the question. Perhaps the building's power supply is the landlord's concern, or a separate team manages the network. Naming those boundaries early avoids a report full of observations you cannot act on, and lets the reviewer spend the time on the parts of the chain you control.
- Findings only, or findings plus a ranked list of actions
- Areas that belong to another team or a landlord
- Whether live and recorded workflows are both in scope
Gather the paperwork before anyone visits
The quickest way to waste a site visit is to spend the first hour hunting for drawings. Collect whatever documentation exists: signal flow diagrams, patch lists, rack layouts, equipment inventories with model names and firmware versions, and any notes on how the studio is normally operated. Out-of-date drawings are still useful, provided you flag what has changed since they were made.
If the documentation is thin, say so plainly. Sketching the main path on a single sheet, camera to switcher to monitoring to output, takes an engineer an afternoon and gives the reviewer something to correct rather than build from nothing. It also tends to surface surprises inside your own team, such as a workaround that only one operator knows about.
- Signal flow diagrams and patch lists, even if dated
- Equipment inventory with firmware versions where known
- A hand-drawn main signal path if no drawings exist
Decide who needs to be involved on the day
A review that only hears from the studio manager will miss what the operators know. The person who vision-mixes every Thursday, or the sound operator who has learned to avoid a particular fader, holds knowledge no diagram contains. Agree beforehand who will be available for a short conversation, and make clear that the purpose is to understand the work, not to audit individuals.
Equally, think about who will read the written report and who must approve any resulting spending. If the budget holder never sees the findings, recommendations tend to stall. Naming a single point of contact on your side, and the person who will sign off changes, keeps the process moving and stops conflicting instructions reaching the reviewer.
- Operators from each position: vision, audio, graphics, playout
- One named contact for questions during the review
- The person who approves any follow-up spending
Choose a time that shows the studio working
Reviewing a silent, empty studio tells you about the equipment but little about the workflow. Where possible, schedule the visit around a real rehearsal or a normal production day, so the reviewer can watch handovers, cueing and the small improvisations that crews make without noticing. Mid autumn is often a sensible window, as schedules settle after the summer break and before the busiest seasonal output.
Be candid about disruption. Some observations are best made during a live show, others only when the studio is quiet and equipment can be switched off for testing. Agreeing both slots in advance, and making clear which tests are acceptable on a working system, protects your output and gives the reviewer a fair chance to examine the whole path.
- One session with the crew working normally
- One quiet session for tests and measurements
- Agreed limits on what may be switched off or changed
Be clear about what you want in the report
Reports differ widely in usefulness. Say how you intend to use the findings: to brief a contractor, to justify a budget request, to train new staff, or simply to settle an argument about where a fault lies. A report written for a technical team reads differently from one meant for a finance committee, and it is easier to write the right one than to rework the wrong one.
Ask for findings to be separated into what is urgent, what is worth doing within the year, and what can wait. Ask for the reasoning behind each point in plain language, so you can challenge it. A written review should leave you better able to decide, not merely better informed, and that comes from clear priorities rather than length.
- Intended audience for the written report
- Findings ranked by urgency
- Reasoning stated plainly for each recommendation
None of these steps needs special equipment, only a little preparation and some honesty about how the studio really runs. If you can describe the problem, hand over what documentation exists, name the right people and say what you will do with the report, the review has a good chance of paying for itself. If you would like to talk it through, our contact page is the place to start, and Thomas will help you shape the scope before anything is agreed.
Rebecca Hartley
Founder and Lead ConsultantRebecca spent years in studio engineering before founding mediqly. She leads workflow reviews and writes much of our guidance.