A production partner in China proposes an interactive demo for your next product launch. Viewers can pick a use case, explore a feature and choose a tutorial. Before approving the concept, ask for two inventories: the distinct answers that need production, and the routes a viewer can take through them.
ONCE recommends treating these as separate purchasing quantities. A small content library can support many viewing journeys; fewer clips do not automatically mean less integration or acceptance work. The decision is whether different buyers need different answers, and whether your team can keep those answers correct.
Available technology does not settle the business case
H5P’s Branching Scenario page, submitted on February 25, 2019, describes choices determining subsequent content and support for video. Branching is an established capability, not a new launch signal. That documentation does not establish a sales lift or compatibility with your particular deployment.
A narrower operational example comes from Vimeo’s Classic Interactive documentation: some mobile devices switch to their native player in fullscreen, removing interactive features. This is a product-specific warning, not a verdict on every player or phone. It illustrates why an editor preview cannot replace acceptance on the intended embedded page.
The ONCE two-inventory model
Consider a deliberately simplified script: one shared introduction followed by three binary decisions. Exclude a common ending. This is an illustrative design model, not a customer project or an industry benchmark.
| Design | Distinct content segments | Complete choice combinations | Assumption |
|---|---|---|---|
| Every downstream answer depends on the full earlier history | 1 + 2 + 4 + 8 = 15 | 2³ = 8 | Every resulting segment is unique |
| Each stage reconnects before the next decision | 1 + 2 + 2 + 2 = 7 | 2³ = 8 | Later answers are independent of earlier choices |
A segment is a logical content unit, not necessarily a separate media file. An implementation might use time ranges within one file. Moving from fifteen segments to seven therefore does not establish a proportional saving in the full project price.
Reconnect when the answer stays the same
Imagine a portable device demo. A viewer first chooses an indoor or outdoor example, then chooses basic operation or maintenance. If both tutorials apply regardless of the scene previously viewed, reconnect before that second question. The producer can reuse the same approved answers.
That shortcut fails if the first choice selects a different model with different operating requirements. Have the product owner approve applicability, preserve necessary selection state and require a demonstration on the proposed platform. A diagram alone does not prove the implementation supports your logic.
Request four separate scopes
- Content production: the question each segment answers, applicable products, required footage or animation, and language versions. Identify shared segments explicitly.
- Interaction: decisions, permitted transitions, defaults, back navigation and exits. A button count does not define this work.
- Acceptance: agreed route coverage, embedding pages, devices and playback states, with named responsibility for evidence and fixes.
- Maintenance: source assets, captions, node rules and dependencies showing what a specification change affects.
Compare quotes as production plus integration plus agreed acceptance plus ongoing platform and update costs. This is a scope model, not a market price formula. Use actual supplier quotes and verify actual platform terms. Runtime alone is a weak comparison when vendors have included different obligations.
Approve segments, transitions and complete journeys
Review individual segments for product accuracy. Check that each permitted transition reaches the right answer and that repeated clicks, back navigation and inactivity behave as specified. Then follow consecutive choices to catch contradictions, missing explanations and broken final actions.
For the eight combinations above, the team can agree to traverse each and retain results. Larger projects need an inventory of valid combinations and exclusion rules before agreeing risk-based coverage. Do not confuse a route count with exhaustive coverage of every technical state. Model changes and claims that affect purchasing decisions deserve explicit ownership.
Acceptance should use the actual embedded page, including agreed mobile inline and fullscreen conditions. If interaction fails, an approved linear explanation or text alternative should remain available; an enquiry link outside the player can preserve access. These are proposed checks, not device tests performed for this article.
Start with one purchasing question
If the only difference is decorative footage, a clear linear demo may be easier to scope. If customers need substantively different explanations, ask your China production partner for a small branching sample before commissioning the full experience.
Provide one buyer question, two genuinely different answers, a justified reconnection point and a final action. Request both inventories and the acceptance environment with the quote. Use ONCE’s video production articles to define production deliverables, and its video marketing analysis to clarify why each audience choice matters.
For long-term reuse, retain the answer modules and their applicability and update dependencies. A click records a selection; it does not by itself prove purchase intent or incremental sales. Evaluate business outcomes separately from successful navigation.
Sources and boundaries
Checked November 1, 2026: H5P, Branching Scenario, submitted February 25, 2019; Vimeo Help Center, Classic interactive features not showing on mobile when in fullscreen mode, publication date not shown. The two inventories, illustrative arithmetic and procurement recommendations are ONCE’s analysis, not vendor commitments or measured results.
