Handover, Last-Minute Changes and Show Incidents.

No show goes exactly to plan: someone changes their arrival time, an artist asks for another programme change, a console restarts halfway through a section or a screen loses its signal for thirty seconds. The difference between a controlled night and an improvised one is having written down what to do as soon as problems appear, rather than whether problems arise.

This guide covers the five mechanisms that support a show when the plan moves: Artist handover, Last-minute changes, Incident logging, Incident reports and Show-file backups. They connect operation with closing, and are most quickly forgotten when the night ends well.

When the plan changes halfway through the night

First comes judgement. For a change, distinguish what affects safety, timing or the system, and what is a preference. Safety and system matters are resolved with the technical authority; timing with production; preferences with whoever requests them, if there is room. Sorting things this way shortens the discussion.

Second comes the channel. The message goes out over the area’s intercom or radio, reaches production and returns confirmed; nobody implements a change they only overheard in a corridor. If the channel fails, use the agreed backup plan: an emergency radio and a mobile contact for each area.

Third comes the record. Every change, however small, leaves a trace in the show schedule with the actual time and responsible person. Maintaining that habit throughout the night lets you reconstruct what happened without relying on anyone’s memory.

Artist handover: handing over a ready stage

Artist handover is an orderly transfer between the outgoing and incoming artist or team: stage condition, configurations retained, unresolved issues and anything the next team needs to know. It may take two minutes, but it must happen.

A proper handover follows a short list: a clean surface, equipment in place, active power supplies, an available patch, screens switched on and outstanding issues announced. If something was broken or replaced, say so here; if something depends on the next team—their own mixer or laptop—mention that too.

Handover avoids the opposite situation: the next team discovers the problem only once they are in front of the audience. Between different companies, a brief handover record also avoids later arguments about the condition in which equipment was returned.

At events with several artists, handover links the whole night together: the first hands over a clean setup, each documents their part and the last closes with an inventory. If anyone skips a handover, the rest of the chain works from incomplete information and the error appears when there is no time left to correct it.

Last-minute changes: absorbing a change

Last-minute changes arrive as a delayed artist, a running-order change, new content, an extra guest or a song to add to the programme. The rule is to validate before implementing: who approves it, what time it takes and what it means for everyone else.

Next comes communication down the chain. Production informs the areas; the areas inform their people; the stage manager informs the stage. If the lighting operator hears from the artist instead of production, the chain has broken.

Finally, the change is rescheduled: if it takes four minutes, someone decides where those minutes come from. Changes that are not paid for with time are paid for with cuts, and that currency can be spent only once per night before someone objects.

Incident logging: recording as it happens

Incident logging is a live record of departures from the plan: time, location, people involved, what happened, what was done and how it ended. Write it down as it happens, in the simplest possible format; finer detail comes later.

The log has two uses. During the night, it reveals patterns: a channel’s third failure in the same position is a connection problem, rather than bad luck. After the show, it supports the report and conversations with suppliers or insurers.

A good log is neutral. It seeks facts, rather than blame: what was observed, the time and the decision taken. That tone allows it to be used later without turning the review into a trial.

The incident report after the show

The incident report consolidates the log: a chronological summary, actual show impact, actions taken, responsible people and recommendations. Write it while the information is fresh, ideally that night or the following morning.

A good report distinguishes an incident from an inconvenience. The former affected the show or audience; the latter only affected the team. It also separates avoidable issues from unexpected ones and proposes a specific action: change a cable, check a connector, update the frequency plan or reinforce the load-in briefing.

Across several events, reports form a fault database. It reveals the recurring failures described in faults by equipment type: diagnosis and repair and the preventive measures in preventive maintenance and control cleaning.

Show-file backup: back up before leaving

Show-file backup protects the configurations used: consoles, controllers, video content, cues, saved patches and network settings. Do it before leaving the venue, rather than the following weekend.

The practical rule is two sources, two destinations: one copy on the medium travelling with the team, and another on a different medium—the cloud or production’s disk. If both travel in the same backpack, there is no real backup.

Set the backup time within the schedule, rather than leaving it to whoever remembers last. It is usual to copy after soundcheck and again at the end, because content often changes between those times: new tracks, corrected cues or settings that exist only on that console.

Respecting the folder structure matters as much as copying. A backup without a readable name or date is of little use when something needs restoring at three in the morning. Naming by event, date and version makes a confusing folder recoverable in minutes.

From incident to improvement

The loop closes when the record becomes a process change. If the same phase runs late for the same reason three nights in a row, the solution is to modify the load-in plan, rather than arrive earlier next time. If a channel always fails, its patch design needs redesigning.

For that loop to work, keep the review brief and specific: what happened, what caused it, what we change and who implements it. Ten minutes with the team still together is worth more than a perfect document written a week later without context.

Once incidents are closed and files backed up, all that remains is packing up, counting and settling.

Next step

Close the operation calmly with post-show: load-out, inventory and technical settlement, which details dismantling, checking equipment, declaring damage and closing the technical accounts.