# Nexi Innovation Concept — Production Storyboard

**Purpose:** Show how Nexi turns traffic optimisation into a calmer, more understandable home-internet experience.  
**Format:** 16-beat product story for the Home Products all-hands.  
**Source:** `../../Material/Nexi_Innovation_Concept_Storyboard_FIXED.pptx`  
**Status:** Concept narrative. Product, technical, data, and commercial claims marked **Validate** require confirmation before commitment-level use.

> **Core promise:** The experience is not simply faster internet. It is calmer home internet—Nexi quietly protects what matters, explains limits, and keeps the customer in control.

## Story at a glance

| Chapter | Beats | Narrative job |
|---|---:|---|
| [A — Setup and trust](#chapter-a--setup-and-trust) | 01–07 | Introduce Nexi, explain what she sees, and establish reversible control |
| [B — Learned routines and transparency](#chapter-b--learned-routines-and-transparency) | 08–10 | Show useful proactivity and understandable household insight |
| [C — Capacity limit and commercial moment](#chapter-c--capacity-limit-and-commercial-moment) | 11–14 | Explain the physical boundary before offering more capacity |
| [D — Principles and validation](#chapter-d--principles-and-validation) | 15–16 | Distil the product rules and define the next research questions |

---

## Chapter A — Setup and trust

### Beat 01 — Meet Nexi

[![Meet Nexi cover frame](assets/slide-01.jpg)](assets/slide-01.jpg)

**Purpose**  
Introduce Nexi as an intelligent traffic companion that works quietly in the background.

**Story**  
The household meets Nexi in the service experience. She does not promise a faster tariff or ask the customer to become a network administrator. Her job is to keep important applications stable when the home network becomes busy.

**On-screen action**

- Calm home scene and Nexi activation screen
- Primary action: **Start setup**
- Immediate positioning around stability and prioritisation under load

**Production needs**

- Establishing shot or slow push into the phone UI
- Short Nexi identity sting; no technical explanation yet
- Optional ambient home sound before the dialogue begins

**Validate**

- Final product name and whether “Nexi” remains the customer-facing identity
- Preferred term: **Traffic Optimisation**, not a speed upgrade

---

### Beat 02 — Three moments that make Nexi useful

[![Three key Nexi moments](assets/slide-02.jpg)](assets/slide-02.jpg)

**Purpose**  
Set the full narrative arc before entering the experience.

**Three moments**

1. **First-time onboarding** — Nexi explains what she sees, optimises, and never analyses.
2. **One week later** — Nexi learns useful household rhythms and proposes a priority schedule.
3. **Capacity limit reached** — Nexi explains when optimisation is no longer enough and offers a low-risk path to more capacity.

**Product requirements**

- Explainability before automation
- Privacy without vague reassurance
- Visible, reversible customer control
- Proactivity without pressure
- A commercial recommendation only after a proven physical limit

**Production needs**

- Use as chapter map or rapid three-part montage
- Establish three distinct time states: now, one week later, network maxed out

---

### Beat 03 — Make automatic optimisation trustworthy

[![Trust-first onboarding dialogue](assets/slide-03.jpg)](assets/slide-03.jpg)

**Purpose**  
Answer the customer's first question: what exactly is Nexi watching?

**Dialogue**

> **Nexi:** Hi, I'm Nexi. When this whole house is online at once, I keep the important things smooth—no tech degree needed.
>
> **User:** Sounds helpful. What exactly are you watching?
>
> **Nexi:** Only anonymous application categories like streaming, gaming, and video calls. Not the websites you open. Not what you watch.

**On-screen action**

- Nexi introduction and privacy explanation
- Optional links to deeper privacy information
- Clear continuation into setup

**Production needs**

- Two distinct voices or readable chat bubbles
- Let the privacy answer remain on screen long enough to understand
- Avoid implying that the microphone is always active

**Validate**

- Exact telemetry categories available to the service
- Whether provider-level service recognition is possible and permitted

---

### Beat 04 — Traffic patterns, not personal content

[![Traffic-pattern explanation](assets/slide-04.jpg)](assets/slide-04.jpg)

**Purpose**  
Make the privacy model concrete without exposing network complexity.

**How Nexi works**

1. **Focus** — recognise traffic categories such as streaming, gaming, and video calls.
2. **Compare** — understand current household demand, available capacity, and latency needs.
3. **Change** — adjust priority automatically when the network becomes busy.

**Key line**

> **Nexi:** I need patterns, not secrets. I know a video call is active—not what you said in the call.

**Production needs**

- Show abstract traffic flows, not personal screens or browsing content
- Three-step visual progression: observe → compare → adjust
- Keep the explanation under one spoken sentence if used in the video

**Validate**

- Technical accuracy of traffic recognition and latency inference
- Privacy/legal wording for inferred application categories

---

### Beat 05 — A simple setup turns complexity into confidence

[![Priority-lane setup](assets/slide-05.jpg)](assets/slide-05.jpg)

**Purpose**  
Demonstrate that automation can be simple without removing control.

**Dialogue**

> **Nexi:** I'll set up dedicated lanes for the important things, so video calls, streaming, and gaming stay smooth when the network gets busy.
>
> **User:** Sounds good. But can I still change the order myself?
>
> **Nexi:** Always. You can ask me, use the settings, or switch back to automatic at any time.

**On-screen action**

- Suggested priority order appears
- Customer chooses **Sounds good** or **Set the order myself**
- Reversibility is visible before activation

**Production needs**

- Animate the three categories into position
- Keep the user-control response visible as the scene resolves

**Validate**

- “Dedicated lanes” may overstate the backend mechanism
- Confirm the actual service categories and control model

---

### Beat 06 — Control is one tap or one sentence away

[![Visible manual control](assets/slide-06.jpg)](assets/slide-06.jpg)

**Purpose**  
Show the hybrid model: Nexi leads, while direct controls remain available.

**Dialogue**

> **User:** Prioritise video calls today. I have back-to-back meetings.
>
> **Nexi:** Done. Video calls are on top. Gaming and streaming will still work; they will briefly wait behind your meetings.

**On-screen action**

- Video Calls moves to the top of the priority order
- Global Network Priority control remains visible
- Customer can inspect, override, pause, or reverse the change

**Production needs**

- Natural-language command followed by a clear list reorder
- Confirm the effect in plain language
- Do not turn the scene into a settings tutorial

**Validate**

- Replace mixed `Network Priority` terminology with the final product language
- Confirm whether a one-day rule is supported

---

### Beat 07 — A helpful expert, not a settings menu

[![Nexi conversational expert view](assets/slide-07.jpg)](assets/slide-07.jpg)

**Purpose**  
Make the new interaction principle tangible through a useful quick command.

**Dialogue**

> **Nexi:** Your home has been quiet. Everything is under control. Ask me anything.
>
> **User:** Lower gaming latency tonight.
>
> **Nexi:** Gaming is prioritised from 17:00 to 20:00. I cannot promise a better win rate.

**On-screen action**

- User invokes voice or chat from the calm home surface
- Nexi translates intent into a temporary schedule
- The response combines action, scope, and a light human tone

**Production needs**

- Best candidate for an explicit voice-demo moment
- Show listening/transcription state only after deliberate activation
- Use humour sparingly; action confirmation remains primary

**Validate**

- Exact scheduled-priority capability
- Voice activation model and permission state

---

## Chapter B — Learned routines and transparency

### Beat 08 — One week later: Nexi learns household rhythms

[![Learned household rhythm suggestion](assets/slide-08.jpg)](assets/slide-08.jpg)

**Purpose**  
Show proactivity that explains itself and asks permission.

**Story**  
After seven days, Nexi detects recurring weekday work hours and evening gaming. She describes the pattern before creating any lasting rule.

**Suggested pattern**

- Video Calls: weekdays, 09:00–17:00
- Gaming: typically 17:00–19:00

**On-screen action**

- Pattern recommendation appears as a proactive card
- Customer chooses **Not now** or **Set it up**
- No lasting automation is created without consent

**Production needs**

- Clear “One week later” time transition
- Pattern card arrives without interrupting an active task
- One accept/decline decision; no long explanation

**Validate**

- Whether the service can learn recurring routines from available data
- Minimum observation period and confidence threshold

---

### Beat 09 — Tune priorities in natural language

[![Natural-language weekly schedule](assets/slide-09.jpg)](assets/slide-09.jpg)

**Purpose**  
Demonstrate that the customer can refine Nexi's suggestion without learning network settings.

**Dialogue**

> **User:** Please add streaming priority from 20:00 to 22:00.
>
> **Nexi:** Done. Your weekday rhythm now looks like this: video calls 09:00–17:00, gaming 17:00–20:00, streaming 20:00–22:00.
>
> **User:** Send me a household usage report every Monday morning.
>
> **Nexi:** Confirmed. Monday mornings are now report mornings. Less mystery, more clarity.

**On-screen action**

- The priority schedule updates visibly
- Nexi repeats the complete result for confirmation
- A weekly report preference is added

**Production needs**

- Animate only the changed schedule block
- Keep the final weekly rhythm visible as a readable receipt
- This can be combined with Beat 08 in a single clip

**Validate**

- Natural-language rule creation and persistence
- Report scheduling and notification channel

---

### Beat 10 — Monday report: category-level transparency

[![Weekly household usage report](assets/slide-10.jpg)](assets/slide-10.jpg)

**Purpose**  
Offer useful household insight without turning optimisation into self-congratulatory “help counts.”

**Last seven days — household traffic**

| Category | Share |
|---|---:|
| Streaming | 52% |
| Gaming | 26% |
| Video Calls | 14% |
| Other Traffic | 8% |

**Streaming breakdown shown in the source**

| Service | Share |
|---|---:|
| Netflix | 34% |
| YouTube | 28% |
| Disney+ | 18% |
| Prime Video | 12% |
| Other | 8% |

**Key line**

> **Nexi:** I do not analyse opened websites or watched content. I only group traffic into application categories needed for optimisation.
>
> **User:** Good. Show me trends, not private details.
>
> **Nexi:** Exactly. Helpful, but not nosy. A rare talent in home networking.

**Production needs**

- Treat as a separate usage insight, not proof that Nexi “helped”
- Simple bar animation; no dense dashboard tour
- Optional in the short all-hands cut if timing is tight

**Validate**

- Provider-level breakdown conflicts with the category-only privacy claim
- Confirm granularity, retention, household access, and consent requirements

---

## Chapter C — Capacity limit and commercial moment

### Beat 11 — Optimisation reaches a physical boundary

[![Capacity-limit notification](assets/slide-11.jpg)](assets/slide-11.jpg)

**Purpose**  
Explain that traffic optimisation can protect priorities but cannot create physical bandwidth.

**Story**  
Recurring simultaneous streaming, gaming, and video calls fully occupy the line. Nexi has already optimised the available capacity.

**Key line**

> **Nexi:** Your network is maxed out. I optimised everything I can—there is no room left.

**On-screen action**

- Lock-screen notification introduces the issue
- Customer opens a detailed explanation
- No commercial offer appears before the limitation is understood

**Production needs**

- Strong transition from calm routine to real household pressure
- Lock-screen notification followed by the in-app detail state

**Validate**

- The source mockup says “Monday, 16 June” without a year; confirm the intended date before final export
- Detection threshold for declaring the network “maxed out”

---

### Beat 12 — Explain the trade-off before asking for a decision

[![Capacity trade-off and trial offer](assets/slide-12.jpg)](assets/slide-12.jpg)

**Purpose**  
Connect the recommendation to a specific, understandable household conflict.

**Scenario**

- Current line: **50 Mbit/s**
- Active demand: two streams plus one live video call
- Nexi can protect the call, but streaming quality may fall

**Dialogue**

> **Nexi:** I can keep your call stable, but high-quality streams may need to step down.
>
> **User:** Can we fix that without changing everything?
>
> **Nexi:** You can try more headroom for 30 days. There is no commitment, and I will keep optimising either way.

**Offer shown in the concept**

- 30 days free
- 250 Mbit/s trial connection
- No commitment
- Optimisation continues whether the offer is accepted or declined

**Production needs**

- Visualise contention and the call-protection decision before showing the offer
- Keep **No, leave it** available and visually equal enough to preserve trust
- Avoid generic sales language

**Validate**

- 50-to-250-Mbit eligibility and provisioning path
- Exact free-trial length and commercial terms
- Whether Nexi can identify this as a capacity rather than fault/Wi-Fi problem

---

### Beat 13 — A recommendation appears only with proof

[![Accepted 30-day trial recommendation](assets/slide-13.jpg)](assets/slide-13.jpg)

**Purpose**  
Show a commercial moment that feels like problem solving rather than advertising.

**Story**  
The customer accepts the temporary higher-capacity trial. Nexi confirms the change and handles the setup while retaining the same optimisation behavior.

**On-screen action**

- Customer accepts the 30-day trial
- Nexi confirms activation/provisioning
- The capacity recommendation resolves into a completed state

**Production needs**

- Short confirmation animation
- Do not imply instant provisioning unless technically supported
- The reason for the offer remains visible in the transition

**Validate**

- Provisioning latency and confirmation states
- Whether the experience belongs to SpeedSnack, tariff routing, or another commercial flow

---

### Beat 14 — The outcome is calmer home internet

[![Calmer home internet outcome](assets/slide-14.jpg)](assets/slide-14.jpg)

**Purpose**  
Close the product story on the household outcome, not on the tariff sale.

**Core line**

> The experience is not faster internet. It is calmer home internet.

**Story**  
Nexi mediates between household needs, available network resources, and commercial options. Everyone stays online, important activity is protected, and nobody needs to blame or manage the router.

**Production needs**

- Return to the calm household scene from Beat 01
- Resolve traffic lines and notifications into a quiet background state
- End on the product promise, not the upgrade CTA

**Validate**

- Ensure the final statement remains compatible with the Traffic Optimisation proposition

---

## Chapter D — Principles and validation

### Beat 15 — Keep Nexi trustworthy as the concept evolves

[![Five Nexi design principles](assets/slide-15.jpg)](assets/slide-15.jpg)

**Purpose**  
Make the non-negotiable product principles explicit.

1. **Explain before optimising** — always show why a recommendation or automatic change is suggested.
2. **Never feel like surveillance** — use category-level patterns and say clearly what Nexi cannot see.
3. **Control remains visible** — customers can inspect, override, pause, and reverse.
4. **Proactivity earns permission** — recommendations become automation only after consent.
5. **Commercial moments need proof** — offers follow observed limits, not generic promotion.

**Production needs**

- Use as a fast recap, not a narrated policy slide
- Bring back one visual moment from each earlier chapter

---

### Beat 16 — Test the moments where trust is won or lost

[![Trust moments to validate](assets/slide-16.jpg)](assets/slide-16.jpg)

**Purpose**  
Turn the concept into a focused validation agenda.

**Research priorities**

- Does the onboarding explanation create trust without overload?
- Do customers understand the privacy boundary?
- Are schedule recommendations useful and acceptable?
- Does the weekly report provide value without feeling invasive?
- Is the capacity-limit explanation credible?
- Does the trial offer arrive at the right moment and feel optional?
- Can customers always find and understand direct controls?

**Production needs**

- End the presentation with the next learning step
- Avoid implying that the storyboard is an implementation commitment

---

## Video production handoff

### Recommended scene structure

| Clip | Beats | Target job | Approx. duration |
|---|---:|---|---:|
| 1 — Meet and trust Nexi | 01, 03–07 | Introduce the agent, privacy boundary, and reversible control | 45–75 sec |
| 2 — One week later | 08–10 | Show learned routines, permission, refinement, and optional usage insight | 35–60 sec |
| 3 — Capacity limit | 11–14 | Explain the physical boundary, trade-off, trial, and calmer-home outcome | 45–75 sec |
| Presentation framing | 02, 15–16 | Open the arc, recap principles, and close on validation | Slides / presenter |

### Required production capabilities

| Capability | Needed for |
|---|---|
| High-fidelity UI capture | Current Nexi prototype states and transitions |
| Deterministic scene playback | Repeatable timing for all-hands video clips |
| Voice generation or recording | User and Nexi dialogue |
| Transcript/listening-state animation | Explicitly activated voice commands |
| UI motion and state transitions | Reordering, proactive cards, schedules, reports, confirmation |
| Compositing | Phone UI, lock screen, home environment, chapter/time transitions |
| Audio mixing | Voice clarity, subtle UI sounds, low-key ambience |
| Captioning | Accessibility and silent playback resilience |
| Versionable scripts/data | Fast dialogue and timing revisions without rebuilding every shot |
| Reliable export | 16:9 presentation video with predictable playback |

### Inputs the production system should separate

- **Narrative:** scene order, purpose, and timing
- **Dialogue:** user/Nexi lines and voice assignments
- **UI state:** deterministic starting and ending state per shot
- **Motion:** transitions, reveals, reorders, confirmations, and time jumps
- **Visual shell:** phone, lock screen, home context, and background treatment
- **Audio:** voices, interface cues, ambience, and final mix
- **Validation flags:** claims that must stay illustrative until confirmed

### Stack-selection criteria for the next step

The later framework comparison should score options against:

1. **UI fidelity** — can it use or faithfully reproduce the current web prototype?
2. **Deterministic rendering** — can every frame and transition be reproduced reliably?
3. **Data-driven scenes** — can dialogue, timing, and UI states be changed from structured data?
4. **Voice workflow** — can ElevenLabs or recorded audio be aligned, replaced, and captioned easily?
5. **Motion quality** — can it handle interface motion, camera moves, and compositing without fragile hacks?
6. **Iteration speed** — can Chris change a line or timing value without re-editing the whole video?
7. **Export reliability** — does it produce presentation-safe 1080p video consistently?
8. **Reviewability** — can stakeholders preview scenes in the browser before final render?
9. **Asset reuse** — can existing HTML/CSS/JS and Nexi UI assets be reused?
10. **Operational simplicity** — does it avoid an unnecessarily complex production pipeline?

### Claims to resolve before final production

- Final Nexi name and voice identity
- Voice activation and microphone/listening state
- Traffic categories and provider-level usage visibility
- Automatic routine detection and rule persistence
- Meaning of “dedicated lanes” in customer language
- Capacity-limit detection and fault/Wi-Fi differentiation
- 30-day free trial, 50-to-250-Mbit path, and provisioning behavior
- Final `Traffic Optimisation` terminology across all screens