A presenter says, “You can see the difference here,” while the online audience sees a wide picture of the stage. The demonstration happened, but its evidence did not reach the viewer. A product-demo commission needs more than a named presenter and a running time: it needs an explicit account of what viewers must see to understand each step.
Decide which actions require a close view, which depend on a screen, and which need the presenter to explain a result. Leave equipment selection to the assessed production plan. The buyer's contribution is a clear demonstration logic that the supplier can evaluate.
Write the demonstration as observable steps
For each promised demonstration, name the starting condition, action and visible result. “Show the software” is too broad. “Show a sample request being assigned, then show where its status changes” identifies two observable moments and a relationship between them.
For a physical object, distinguish what can be seen from what can only be described. A texture, sound or resistance may not translate directly through video. Decide whether an approved explanation or supporting visual is needed rather than implying that an audience can verify a sensory quality through the stream.
Avoid turning a sales demonstration into an unsupported performance test. The product owner should approve claims, conditions and limitations. The production brief should preserve those conditions, not make the demonstration look more conclusive through selective framing or editing.
Choose the evidence view for each step
A presenter view establishes who is explaining. A demonstration view shows the action. A software view can show the interface. Each may be necessary at a different moment, and a continuous split layout may make the important detail too small.
Ask the supplier how the proposed treatment makes the decisive information understandable at the intended viewing size. Give it a representative interface or sample object to assess. Do not use confidential production data merely because it looks more convincing than a prepared example.
Where sound is part of the demonstration, list it separately. Microsoft's Teams audio guidance treats sharing computer sound as a specific function. Showing a screen should therefore not be taken as evidence that the relevant product sound has been included in the plan.
Use a demonstration-evidence map
| Step | Starting condition | Visible action | Result to show | Explanation or limitation |
|---|---|---|---|---|
| Setup | Approved sample state | Presenter identifies the relevant item | Viewer understands what is being tested | State simulated or prepared data where material |
| Change | Condition before the action | One defined operation | Relevant difference becomes visible | Avoid implying unrelated causes |
| Comparison | Comparable approved examples | Presenter identifies comparison basis | Difference the audience can inspect | Explain boundaries of the comparison |
| Recovery | Agreed alternative if demonstration cannot proceed | Presenter acknowledges the change | Supplied example clearly identified | Do not pass a substitute off as the live result |
Replace the generic rows with the actual product steps. Add a content owner who can confirm whether a changed demonstration still supports the intended message.
Define a truthful alternative
A demonstration may not be repeatable on demand, or a connected service may behave differently on the day. Ask the product owner what the presenter should say if the planned result does not occur. An approved prerecorded example can explain intended behaviour, but should be identified appropriately rather than disguised as the result of the current attempt.
Separate the requirement to document what happened from a request to create a polished explanatory asset afterwards. A later corrected demonstration may be useful, but it is a new account with a different context. The original event recording should not silently acquire a result that the audience never saw.
Fictional example: an unreadable status change
An invented business-software launch includes a demonstration of moving a work request between teams. The stage picture clearly shows the presenter, but the status label is too small to understand in the proposed composite layout.
The buyer marks the assignment and status confirmation as the decisive moments. The supplier is asked to propose an appropriate screen treatment for those passages, while the presenter explains which sample request is being used. The commission is assessed against the visibility of the change, not against a particular camera count or software feature.
Questions before commissioning
Can a first-time viewer identify the before and after states? Which details need explanation because video alone cannot communicate them? Who approves sample data and visible notifications? What substitute is permitted if the live attempt changes? Which outputs must preserve the original outcome rather than a later corrected version?
At acceptance, ask someone unfamiliar with the product to describe the demonstrated sequence without coaching. Use misunderstandings to identify missing context, not to claim a formal usability study. The deliverable should make the agreed demonstration intelligible without adding proof the event did not provide.
Service-fit enquiry
If approaching Live Images, ask whether this event requirement fits its work before requesting a scope. Its current services focus on construction project films; this guide does not establish an event-production offer.
Sources and draft note
- https://support.microsoft.com/en-us/teams/meetings/manage-audio-settings-in-microsoft-teams-meetings — Computer sound sharing is an explicit platform function.
Prepared with AI assistance for Live Images. Unpublished draft; fictional examples are not client projects.