Product Demo Script Template with Three Examples

Choose a product demo script template that pairs each spoken line with an action the viewer can see and a result they can check. Start with one audience task, demonstrate the path through it, and finish with a next step that fits that task. This guide is for creators scripting software walkthroughs, physical product demonstrations, and feature updates rather than a general brand video.

The products, controls, people, and workspaces below are fictional. Every sample script is original and can be adapted, but none describes a tested real product or claims a measured customer outcome. Download the plain-text product demo script pack for the blank worksheet and three complete example narrations.

Start with the reusable product demo script template

Copy the worksheet before writing full sentences. Fill the audience task and final visible result first, then work backward to the few actions needed to connect them. If an action does not support that result, remove it from this demo or make a separate tutorial. This keeps a product overview from becoming a catalogue of every feature.

[AUDIENCE TASK: one job and starting situation.] [DEMO SCOPE: the workflow or product behavior you will show.] [ACTION ONE: exact control, physical movement, or input.] [ACTION TWO: next necessary action.] [VISIBLE RESULT: what the viewer can now inspect.] [BOUNDARY: relevant scope or condition.] [NEXT STEP: one suitable action.]

Blank product demo narration template

Keep narration and production directions in different columns. “Zoom in on Share” tells the editor what to do; “Choose Share” tells the viewer what happens. Both may belong in the worksheet, but only the second normally belongs in the spoken copy. The text download includes fields for the build or product version and the reviewer so the script can be checked against the right artifact.

Three complete scripts for different demo purposes

Prospect demo: complete a software handoff

You have a lesson ready for review, but the next person needs the script, the audio, and a clear note about what changed. In this Mossline Tasks demo, we'll put that handoff in one review card. Open the Review board and choose New card. Name the card Lesson three, pronunciation update. Attach the script and the audio file shown in this sample workspace. In the note, write: the speaker name has been corrected in the second paragraph. Choose Assign and select the reviewer. Now open the card preview. The reviewer can see the two sample files and the change note together. This demonstration covers preparing the card. It does not show the reviewer approving the lesson or prove that every upload format is supported. If this is the handoff you need, open the example workspace and make a card with your own non-private sample files.

Original fictional product demo narration

The job is a complete handoff, not a tour of every menu. Show the two files, the note, the assigned reviewer, and the final card in the same capture. The limit sentence prevents the audience from mistaking a prepared card for a completed review. A real demo needs the labels and behavior of the actual build; the fictional controls are a writing example.

Physical product demo: open, adjust, and pack a stand

This is the Foldwell travel stand in this product demonstration. We'll show how this sample opens, how the screen position changes, and how it packs away. Place the stand on the table. Hold the base, lift the support, and seat it in the marked position. Here is the support from the side so you can see where it rests. Set the sample laptop on the stand. The next shot shows the screen position before and after the adjustment. We are demonstrating this sample combination, not claiming compatibility with every laptop. Remove the laptop before changing the stand position. Fold the support back into the base. The final shot shows the closed stand beside the same bag used at the beginning. Before choosing a stand for your own setup, check the actual product dimensions, device compatibility, and instructions.

Original fictional product demo narration

The physical example needs a sequence the camera can prove: open, seat, show, remove, fold. Do not hide a difficult assembly step behind a cut. The narration deliberately avoids an invented weight rating or ergonomic benefit. For a real product, follow its manufacturer instructions and state only supported compatibility. The viewer should see the mechanism clearly rather than hear a generic claim about portability.

Existing-user feature demo: see what changed

If you've used Mossline Tasks to send a review card before, this update changes where you check who can open the link. The card content stays in the same place. Open the card and choose Share. The Share settings panel now shows the selected audience above the link. In this sample workspace, it is set to Invited reviewers. Choose Preview access. The preview names the people selected for this card. Read that list before copying the link. Then return to Share and choose Copy link. The preview shown here covers this sample card. It is not an audit of every card in the workspace, and it does not establish your organization's sharing policy. For your next handoff, check the audience for the actual card you are sending. If you do not recognize a reviewer, resolve that choice before sending the link.

Original fictional product demo narration

The purpose is adoption by existing users, so it starts with what changed rather than explaining the product from scratch. Screen labels carry the sequence, and the narration states the scope of the preview. In a real access-control demo, verify the behavior with the actual account types before making a claim. Do not turn a small UI preview into a promise of security or compliance.

Script length estimates for planning

The table counts whitespace-separated spoken words in the original examples, excluding leading speaker labels. The duration column is calculated at an assumed 150 words per minute: words divided by 150, multiplied by 60. These are planning estimates, not measured performances. Pauses, music, effects, turn changes, and time needed to show an action are not included. Time the finished audio or video before using it.

Match each line to something the viewer can verify

Read the software handoff script alongside the captured workflow. When the voice says that two sample files are visible, the shot needs to show both. When it says a reviewer has been assigned, the captured state needs to identify the selection. Do not move to a decorative screen while the voice describes an important result. A narration promise without visible support is still just a promise.

The same rule changes shape for physical products. A closing shot of the packed stand can show that the sample fits beside the bag; it cannot prove every bag is suitable. An edited setup can explain the steps, but cutting away during the locking action may hide the step the viewer most needs. Note required close-ups in the visual column before recording.

Loom's own product-demo example presents a prior interface problem before demonstrating the changed behavior. That is a useful example of context followed by action, not evidence that one universal script formula improves sales. Use a before-and-after structure when the change matters to the audience, and show the actual difference.

1. Circle verbs such as creates, sends, exports, saves, supports, or prevents. Check each against the capture and product behavior.
2. Mark any number, comparison, compatibility statement, guarantee, or outcome. Keep it only with support for that exact claim.
3. Replace vague references such as this button with the control name.
4. Check the final state is visible long enough to inspect during the actual performance.
5. Record any step intentionally excluded from the scope so reviewers know what the demo does not establish.

Write narration that also explains the visual context

A screen recording can be difficult to follow if the narration repeatedly says “here” while the cursor points somewhere. W3C's guidance on incorporating visual descriptions into narration recommends naming meaningful screen text, controls, and actions. Use “Open the Share settings panel” rather than “click this,” and describe the result that appears. Position or color can add context, but the label remains useful.

Prepare captions from the final audio rather than assuming the writing draft is an exact transcript. If the demo needs a text alternative that explains visual information, add the relevant actions and results as well. W3C distinguishes basic transcripts from descriptive transcripts that also include meaningful visuals. A script can be a starting point, but it needs updating to represent the finished recording.

Do not turn that editing practice into an unsupported claim that the complete video is accessible or compliant. The script, player, captions, descriptions, visual design, and actual user experience may all matter. For this worksheet, the practical task is narrower: make the narration understandable and preserve the visual information needed to follow the demonstration.

Rehearse the path before recording the full demo

Walk through the real workflow with the script and clean sample data. A demo account may have a different plan, permission level, or product version from the audience. If a required control is missing, fix the scope or environment before capturing a polished take. Do not narrate an action you cannot perform or present a mock-up as the shipped behavior.

Use the speech time calculator to estimate the spoken draft, then replace the estimate with the actual narration and capture timing. A product demo also needs time for reading, movement, transitions, and processing states. If the capture runs long, remove a secondary workflow before accelerating the voice beyond a clear pace.

The Mac narration workflow can help prepare reviewed speech for a capture. Keep a clean script master and note which lines belong to each shot so a revised control label can be located later. The audio export guide explains master and delivery files. Watch the final export with the sound on, then review the captions and descriptive text against that same version.

If the product needs an audio-only commercial rather than a walkthrough, the radio ad script examples use a different brief: a listener must understand the message without seeing a control, mechanism, or end state. Choose the structure that matches the deliverable before writing the voiceover.

Frequently asked questions