Use this template to define an interactive demo, prototype, or visual walkthrough for a real commercial decision.
Complete the brief before building. Agree whether the output will illustrate a proposed workflow or demonstrate a validated connection. The demo's scope and presentation should make that distinction clear.
Company: ____________________
Brief owner: ____________________
Date: ____________________
Opportunity or proposed partner: ____________________
Review date: ____________________
1. Who is the buyer or reviewer?
Primary audience and role: ____________________
Other stakeholders: ____________________
What they already understand: ____________________
What they still need to assess: ____________________
2. What decision should the demo support?
Choose one immediate decision, such as continuing discovery, reviewing a technical approach, agreeing a pilot, or evaluating a proposal.
The next decision:
The person who owns that decision: ____________________
Evidence they need before deciding: ____________________
The proposed follow-up action: ____________________
3. What is the use case?
Current workflow:
Customer problem or opportunity:
Proposed workflow:
Why this may matter to the buyer:
| Statement used in the story | Verified fact, assumption, or question? | Source or validation owner |
|---|---|---|
| ____________________ | ____________________ | ____________________ |
| ____________________ | ____________________ | ____________________ |
| ____________________ | ____________________ | ____________________ |
4. What should the viewer do or see?
Keep the flow focused on the decision. Identify the essential states, inputs, and outputs.
| Step | Viewer action or event | What appears | What the step explains |
|---|---|---|---|
| 1 | ____________________ | ____________________ | ____________________ |
| 2 | ____________________ | ____________________ | ____________________ |
| 3 | ____________________ | ____________________ | ____________________ |
| 4 | ____________________ | ____________________ | ____________________ |
| 5 | ____________________ | ____________________ | ____________________ |
The most important interaction: ____________________
A failure or empty state worth showing: ____________________
Features excluded from this demo: ____________________
5. What data and materials can be used?
Use fictional data unless appropriately authorized data is necessary and approved for the intended audience. Do not add real credentials, private customer records, or confidential terms to a public demo.
Data mode: Fictional / authorized sample / approved live connection
Data owner and approval: ____________________
Product or API documentation: ____________________
Approved logos, images, and brand materials: ____________________
Where the demo will be shown: ____________________
Required labels for simulated data or behavior:
6. Where does the prototype end?
| Component | Simulated or connected? | What has been validated? | What remains unverified? |
|---|---|---|---|
| ____________________ | ____________________ | ____________________ | ____________________ |
| ____________________ | ____________________ | ____________________ | ____________________ |
| ____________________ | ____________________ | ____________________ | ____________________ |
Technical reviewer: ____________________
Access and permission requirements: ____________________
Production work outside this scope: ____________________
A prototype can illustrate a proposed interaction. It does not establish provider support, integration completion, production reliability, commercial approval, or readiness to handle real transactions.
7. What business case belongs beside the demo?
The business outcome being explored: ____________________
Inputs provided by the buyer: ____________________
Assumptions that need validation: ____________________
Costs, effort, or dependencies to consider: ____________________
How uncertainty will be presented:
Use explicit assumptions for illustrative calculations. Do not present projected savings, revenue, or conversion changes as measured outcomes.
8. How will you test the demo?
| Test | Expected behavior | Reviewer | Result or follow-up |
|---|---|---|---|
| The main flow can be completed | ____________________ | ____________________ | ____________________ |
| The audience can identify the use case and next decision | ____________________ | ____________________ | ____________________ |
| Simulated and validated behavior are distinguishable | ____________________ | ____________________ | ____________________ |
| The intended device and screen size work | ____________________ | ____________________ | ____________________ |
| Claims, figures, and links have been checked | ____________________ | ____________________ | ____________________ |
An issue that must be resolved before sharing:
9. What does the handoff include?
- ☐ The agreed demo or walkthrough.
- ☐ Presentation notes and a recommended opening.
- ☐ A brief business case with sources and assumptions.
- ☐ Known limitations and open technical questions.
- ☐ Ownership and access instructions.
- ☐ A specific proposed next step.
Commercial review owner: ____________________
Technical review owner, if needed: ____________________
Approved audience and sharing date: ____________________
Person responsible for follow-up: ____________________
Discuss a custom demo
Rebar CRO develops opportunity briefs, interactive examples, and business cases for sales and partnership conversations. A focused demo can be scoped as a standalone project or included in an operating engagement.
Discuss a custom demo with Rebar CRO. Bring the product URL, intended audience, and next decision you want the demo to support.