Presentations and talks
Prepare a backup when a live demo may fail
Break the demo into steps, mark where each could fail, and decide in advance what replaces it. A recording, screenshots or a described example can all work if the audience is told what they are seeing. Write the sentence you will say when you switch.
Lesson the demo teaches: [ ] Time allowed for the demo: [ ] Time limit before I switch to a fallback: [ ] Demo step: [ ] Failure point: [ ] Approved fallback: [ ] Fallback label shown to the audience: [ ] Date your recording or example was made: [ ] Transition sentence: [ ] Backup files stored at: [ ] Tested on the presentation device? [yes or no] Steps I will cut if the demo runs long: [ ] Repeat the item block as needed.
Keep every fallback labeled
Every fallback needs a label the audience can read or hear: recorded earlier, example data or screenshot. A recording made on a different day should say so, and sample output should never be described as a live result. Check that the fallback still teaches the point of the original step. Test the backup files on the actual presentation device with the same screen and sound setup. Decide in advance how long you will troubleshoot before switching, so the fix does not eat your time slot.
Review this demo plan. Check that every recorded, screenshot or example result is labeled as such and that no transition sentence implies the demo ran live. Quote any wording that could mislead the audience and suggest an accurate replacement.
Rehearse the switch
Run the talk once with the demo failing at its riskiest step and practice the transition. Store backup files locally and keep a second copy you can reach from another device. Test that each fallback label is readable from the back of the room. Cut any demo step the point of the talk does not need.