Your rep sends a prospect the workflow they discussed on a call. The prospect opens it on their phone between meetings. The video plays, but the assignment rule is unreadable, the cursor disappears into a sidebar, and the result flashes past. The link arrived. The explanation didn't.
A useful mobile product demo answers a specific buyer question with readable product evidence and an appropriate next step. Build the framing, interactions and content depth for a phone, rather than shrinking a desktop presentation. Use vertical video to explain the workflow and a focused product tour when clicking through adds understanding.
I wouldn't ask that prospect to evaluate an entire platform on a phone. I'd help them settle the question that prompted the click.
Definition: A mobile product demo is a self-serve product experience designed for phone viewing, including its visuals, navigation and calls to action. A responsive container doesn't make an unreadable screen recording useful.
What should a mobile product demo actually show?
Show the smallest complete workflow that answers the buyer's question. Complete matters: a button click without its result isn't much evidence.
Take an illustrative sales operations demo. The buyer asks, “How do we stop inbound leads sitting unassigned?” Show an incoming lead, the rule that selects an owner, and the assigned record. Keep enough context to explain why that rep received it. Leave the reporting dashboard for another question.
This is where I see teams overcorrect. They cut a long demo into short feature clips, but remove the connections that made the workflow intelligible. Short isn't the goal. Understood is.
Write the question and the visible proof before choosing screens. “Automated assignment” is a feature label. “This lead now belongs to the rep covering its territory” is something a buyer can verify.
In Dale, the demo automation platform, Pages organize content around topics or pain points and can be reused across demos. Build a Page around the assignment problem, not around everything accessible from the routing settings tab.
If you're demonstrating desktop software, say so where necessary. A phone-friendly explanation of a desktop workflow doesn't mean the application supports that workflow on mobile.
How do you make demo video readable on a phone?
Reframe the action for a narrow screen, then check that both the action and its consequence remain visible. Cropping a desktop recording into portrait format is an editing step, not a mobile strategy.
Pages default to horizontal 16:9 video. Enable mobile video and upload a vertical 9:16 version, and the platform detects the device and plays the vertical version on phones. You supply those assets; there is no built-in screen recording. The mobile demo options also include separate mobile Walkthroughs.
For our assignment example, the rule and the lead record may need separate shots. Trying to keep both panels visible can make neither readable.
- State the question. Tell viewers what they're about to find out before the interface starts moving.
- Establish location. Show enough of the application to orient them, then focus on the relevant control.
- Show the decision. Make the territory condition and resulting owner legible, rather than asking viewers to follow a wandering cursor.
- Hold the result. Give people time to read the assigned record. Don't cut away as soon as it changes.
- Explain the consequence. Connect the result to the work: the lead has an owner without someone manually distributing it.
Watch your edit with the sound off. If the essential explanation disappears, add captions or labels to the video asset before uploading it. Keep those labels away from the evidence. A caption covering the owner field defeats the point of the shot.
Also check whether the edit hides a material step. Removing a loading pause is different from omitting the configuration needed to produce the result.
Should you use vertical video or a mobile walkthrough?
Use video when the buyer needs explanation; use a walkthrough when the sequence of interactions helps answer their question. Combine them only if the second format contributes something the first didn't.
Walkthroughs use screenshots, tooltips and highlighted areas, with viewers clicking Next to move through the sequence. They are mobile-optimized, and you can add a separate mobile version. They're guided representations of the product, not a live application sandbox.
| Buyer needs to understand | Start with | Watch out for |
|---|---|---|
| Why the workflow matters | Vertical video showing the problem and result | Clicks without explanation |
| How a task progresses | A focused Walkthrough | Unreadable desktop screenshots |
| Which topics deserve attention | A Linear Demo | Vague topic labels |
| Whether the story fits their role | A Branched Demo | Choices that don't change the content |
A common mistake is putting the entire video lesson into tooltips and asking the buyer to complete it again. Instead, let the video explain why the assignment rule exists, then use the walkthrough to clarify how an exception is handled.
Don't make the walkthrough longer just to collect more clicks. Every step should reveal evidence, explain a decision or orient the viewer.
How much personalization does a mobile demo need?
Enough to remove irrelevant material, but not so much that choosing becomes the main task. A visitor arriving from a specific feature page may already have told you what they want.
For that visitor, a Basic Demo (Single Experience Demo) can be the right choice: one focused Page with optional walkthrough, attachments and calls to action. There's no prize for adding a questionnaire to a question you've already understood.
When buyers have different priorities within the same product story, a Linear Demo with topic ratings gives them control over depth. Viewers rate topics Important / Somewhat Important / Not Important. Important topics play first using the detailed video; Somewhat Important topics use the shorter video; Not Important topics are omitted. One video can serve both viewing levels.
Write those topics in the buyer's language. “How do I stop leads going unassigned?” is easier to assess than “Advanced Distribution Engine.” On a phone, a label shouldn't need an accompanying paragraph to make sense.
A Branched Demo routes viewers through preset choices, such as role, industry or use case, to a matching Linear Demo or Basic Demo. It doesn't support free-text answers. Use branching when the stories genuinely differ, not just because you can ask who someone is.
For example, a sales leader might need to see ownership and follow-up visibility, while an administrator needs to inspect rule configuration. That's a useful distinction. Asking both their role and industry before showing identical content isn't.
Where should a mobile demo open, and when should you ask for details?
Open it wherever the content has enough usable space, and place the details prompt where you've given the viewer a reason to respond. Test the launch format and the prompt separately so you can tell which change helped.
An inline embed preserves the page's context. A linked experience gives the demo its own browsing space. A popup can work, but its close control and scrolling behavior need scrutiny on a phone. None wins by default.
Test from the actual entry point, including email or social apps where relevant. A demo that works in your preferred browser can still be awkward inside another app's browser. Check that viewers can start, navigate and leave without guessing.
Public-link viewers are identified only if they fill in the prompt. You can request details before the demo, mid-demo after a set time, or at the end. Make the request proportionate to what you're offering. “Get the implementation checklist” creates a clearer exchange than an unexplained form.
Known contacts need a different treatment. Unique invite links identify their viewing activity without asking them to enter details again. And personalized demo links include custom topic links: a rep selects the demo, branch and topics, and the prospect goes directly to that content without the intro or topic selection.
After a conversation about assignment exceptions, send the exception workflow. Don't make the prospect find it again.
Which mobile demo metrics indicate buying intent?
Look for engagement with relevant evidence and progression toward a useful next step. A view, completion or replay alone doesn't establish buying intent.
The available Buying Intent Signals include topic ratings, video viewing and rewatches, walkthrough activity, link clicks, document downloads and sharing. Device information adds context, but it doesn't explain why someone behaved a certain way.
A replay of the assignment rule could mean “We need this.” It could also mean “I can't read that field.” Inspect the content before congratulating yourself on engagement.
I would review a mobile demo with these questions:
- Did they find relevant content? Look at selected and deprioritized topics, not just total starts.
- Where might the experience be unclear? Use walkthrough heatmaps and replay activity to identify places worth checking on a phone.
- What happened next? A relevant document download or meeting-link click provides more context than duration alone.
- Does it fit the conversation? Compare activity with the contact's role, stated problem and evaluation stage.
Keep comparisons fair. A mobile visitor arriving from a broad social post and a desktop prospect opening a post-discovery link have different reasons to watch. If their completion rates differ, screen size isn't necessarily the explanation.
Use the signals to improve your next question, too. “Would it help to look at exception handling?” is more useful than following up with a generic request for feedback.
How do you test a mobile product demo before publishing?
Give someone unfamiliar with the script a specific buyer question and ask them to find the answer on an actual phone. Don't coach them through the experience.
Watch where they hesitate, what they try to tap and what they think the product does afterward. Reaching the final screen isn't success if they misunderstood the workflow.
Pre-publish checklist:
- The launch label names what the viewer will see.
- Essential interface details are readable without zooming.
- Video shows both the action and its result.
- Captions and tooltips don't obscure the evidence.
- Navigation, dismissal and prompts work on tested phones.
- The demo doesn't imply unsupported mobile functionality in the product.
- The next step relates to the question just answered.
Before committing to interactive demo software, check which plan includes the formats, sharing methods and analytics your design requires. Dale pricing lists the current coverage; don't design an elaborate branching and follow-up process around an assumed feature bundle.
Open the Dale interactive demo on your phone and inspect the experience as a buyer. Then choose one workflow from your own product, write the question it must answer, and test a mobile version with someone who hasn't seen your script.