# How We'd Turn a Screen Recording Into a SaaS Demo Ad

> Make a software demo ad from real screen footage. Work through a recording plan, a readable vertical edit, and a brief that keeps the product steps accurate.

Published: 2026-10-30
Author: Cospark Team
Canonical: https://www.cospark.so/blog/saas-demo-video-ad

If you've recorded your app and the result feels like a slow product tour, we'd choose one useful
task and build the ad around that. Show the real action, let someone see what changed, and give
them a sensible next step. You can add narration, captions, or an AI presenter once that sequence
makes sense on its own.

The tricky part is making a desktop interface readable in a short ad. Cropping can hide the button
that explains the result. Cutting a loading pause can make a multi-step process look automatic.
And a polished generated dashboard can quietly promise a feature your app doesn't have.

So let's work through an expense-app example, from the recording plan to the exported ad. The app
and script are fictional; this is an editing exercise you can adapt, not a demo we filmed or a
campaign we measured. We'll keep the real recording as the evidence and use the rest of the video
to help someone follow it.

Choose the task before you record the tour [#choose-the-task-before-you-record-the-tour]

Imagine our fictional expense app lets a team member upload a receipt, choose a category, and send
it for review. The reviewer then sees it in a pending queue. For this example, those are the
approved features. We haven't established automatic categorization, automatic reimbursement, or
a processing-time claim.

We'd make the ad answer: **“How do I send a receipt to the person reviewing expenses?”** That's
small enough to show clearly. A tour of dashboards, budgets, integrations, and reporting would
give the viewer more features to remember before they'd understood the first task.

Write the answer in ordinary language before opening the recorder: “Upload the receipt, choose
its category, and send it for review.” Then check that a new user can actually do those things
with the account and plan you're advertising. If a feature needs a particular role or paid tier,
keep that qualification with the explanation and destination.

If you're still deciding whether the ad should be a demo, tutorial, or customer story, our
[UGC format guide](https://www.cospark.so/blog/ugc-ad-examples) can help with that earlier choice.
Here, we're assuming the viewer needs to see the software work.

Set up a demo account you can safely show [#set-up-a-demo-account-you-can-safely-show]

We'd use an account prepared for recording, with fictional names, a sample receipt, and no real
customer records. Make the sample realistic enough to understand, but don't use a real person's
expense report just because it's already populated. Close unrelated tabs and notifications, and
check the address bar, account menu, and filenames before recording.

For the expense example, we'd label the workspace “Demo workspace” and use a receipt created for
the demonstration. A short “Demo data” label in the video can make that context clear. We wouldn't
make the dashboard look like proof of customer adoption or savings.

Start from a state you can explain. If the uploader is already signed in and the reviewer is
already assigned, that's fine for a feature demonstration. Don't then describe the clip as the
complete setup process. If assigning a reviewer is part of the task you're promising to teach,
you need to show or explain it.

You don't need a new paid recorder to begin. On a Mac, Apple's
[screen-recording instructions](https://support.apple.com/en-us/102618), checked October 30, 2026,
explain how to open Screenshot with Shift-Command-5 and record a selected portion of the screen.
Whichever recorder you use, make a short sample and inspect the saved file before capturing the
whole workflow. Confirm that the text is readable and the menus you need are inside the recording.

Record the action and the result together [#record-the-action-and-the-result-together]

For our expense app, we'd keep an uncut source recording of the whole task. That gives the editor
something to check against when making a shorter version. Capture the starting state, the actual
interaction, and enough of the result to read it.

Here's the source plan we'd prepare. These are proposed filenames and capture instructions for
the fictional example, not existing recordings.

| Source to capture    | What the viewer needs to understand                             | What we'd preserve in the edit                             |
| -------------------- | --------------------------------------------------------------- | ---------------------------------------------------------- |
| `receipt-upload`     | The team member chooses a file and the receipt appears          | The real upload action and the resulting receipt           |
| `category-selection` | The team member chooses the category manually                   | The category menu, selection, and selected value           |
| `send-for-review`    | The submission goes into review rather than straight to payment | The actual send action and pending status                  |
| `reviewer-queue`     | A different role receives the submitted receipt                 | A clear handoff to the reviewer view and the matching item |

Leave a little stillness around the important result. If you immediately move to the next menu,
the viewer may spend the whole clip following the pointer without reading what happened. You can
trim that hold later once you know how the narration fits.

And keep the roles straight. A cut from the submitter's screen to the reviewer's queue should say
something like “Now in the reviewer's view.” Otherwise it can look as though the person uploading
the receipt can approve their own expense, even if your app doesn't allow that.

We'd also capture a fresh result when the input changes. Splicing one receipt upload onto a queue
showing a different receipt gives the editor an avoidable continuity problem. Match the amount,
filename, category, and status across the shots before recording another take.

Make the vertical edit readable without changing the workflow [#make-the-vertical-edit-readable-without-changing-the-workflow]

A desktop recording squeezed into a vertical canvas can leave every label too small. We'd begin
with the part of the interface the viewer needs at that moment, then check whether the action and
its result still fit together.

For the category step, that means seeing the menu open, the chosen category, and the resulting
field value. If those don't fit in one close view, use a wider shot for the action and a closer
view for the result. A brief hold is easier to understand than a camera move chasing every cursor
movement.

| Editing problem                                | What we'd try                                                            | What would make us revise it                                        |
| ---------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------- |
| The whole window is too small                  | Crop around the relevant panel; establish the wider view first if needed | The viewer can no longer tell where the action happens              |
| The menu opens outside the crop                | Widen or reposition the shot for that step                               | The selection is hidden while narration says the user chooses it    |
| A caption covers the status                    | Move the caption or give the interface more space                        | “Pending review” becomes unreadable                                 |
| A pause slows the sequence                     | Trim idle time and make a meaningful time jump clear                     | The edit implies a speed or automation claim we haven't established |
| A role change feels like one continuous action | Label the reviewer view and use a clear cut                              | It appears the submitter has permissions they don't have            |

If the only way to make a step readable is to give it more time, we'd give it more time. There
isn't a universal ad length that makes an illegible demo useful. You can shorten the introduction
or show fewer features before rushing the proof.

Don't redraw a missing button or generate a replacement screen to rescue the crop. Go back to
the source recording, widen the view, or record that step again. A mockup can illustrate a future
idea, but we'd label it as a concept and keep it separate from a demonstration of today's product.

Write the narration against the footage you actually have [#write-the-narration-against-the-footage-you-actually-have]

Now we can build a short explanation. We'd avoid “Watch it handle expenses automatically,” because
our example needs a person to choose the category and another person to review the receipt.
Here's a script that stays with the approved actions:

```text
Here's how a receipt gets to your reviewer.
Upload the receipt and choose its category.
Send it for review. The status changes to pending.
Now in the reviewer's view, that receipt is waiting in the queue.
See the receipt workflow on our product page.
```

Place each sentence beside its matching shot. “Choose its category” belongs over the visible
manual selection; “pending” belongs where that status can be read. If the words arrive before the
picture, adjust the timing instead of expecting the viewer to remember the line until the result
appears.

Describing the important change also helps people who can't see the screen clearly. The
[W3C guide to visual descriptions](https://www.w3.org/WAI/media/av/description/), checked October 30,
2026, explains how essential visual information can be woven into the main narration. In our
example, “The status changes to pending” says more than “And there you go.” This is a useful
writing practice, not a claim that the finished ad meets every accessibility requirement.

Then check captions against the actual audio. The [W3C caption guidance](https://www.w3.org/WAI/media/av/captions/),
also checked October 30, describes captions as speech and relevant non-speech audio information
and explains why automatic captions need review. Extra labels such as “Reviewer view” have a
different job: they orient the viewer in the interface. Keep them readable alongside the captions.

For a difficult product name or rushed read, our [AI voiceover guide](https://www.cospark.so/blog/ai-voiceover-for-ads)
works through a spoken-copy and caption correction. Here, we'd keep the focus on whether the
narration explains the action we can actually see.

Give the editor the recording and a specific brief [#give-the-editor-the-recording-and-a-specific-brief]

We build Cospark, so the product recommendation here comes from its own team. You can use this
brief with another editor too. [Cospark's product page](https://www.cospark.so/), checked October 30,
2026, describes working from your footage, adding narration and captions, and revising through
chat or the timeline. [Script to Video](https://www.cospark.so/apps/script-to-video) is a starting
point when you already have the script.

For this project, we'd supply the real screen clips rather than ask for generated interface
scenes. We haven't tested a paid generation for this guide, and we're not promising automatic
screen capture, privacy redaction, or a crop that follows every menu correctly. Those are things
to inspect in the workflow and output you choose.

Here's the brief we'd adapt after recording:

```text
Make a software demo ad from the attached real screen recordings.
Audience: team members who need to send a receipt for review.
Question: how does the receipt reach the reviewer?

Use the supplied script and screen footage. Keep the actual interface,
manual category selection, send action, and pending status accurate.
Label the switch to the reviewer account. Show the same receipt throughout.
The account uses fictional demo data; keep that context visible.

Create a readable vertical edit. Keep the menu, selected category, and
pending status visible when the narration explains them. Leave room for captions.
You may trim idle pauses; flag time jumps that could change the apparent workflow.
Do not imply automatic categorization, payment, or a measured completion time.
Do not generate replacement product screens or invent customer results.

Show the scene plan and proposed cuts before adding optional generated media.
End with the product-page destination for this receipt workflow.
```

That last request is a project instruction, not a guarantee of an enforced approval step. Review
the proposed edit and then the output. If the tool can't preserve the screen footage as needed,
keep the demo in an editor where you can control those cuts.

Say the draft crops out the category selection and the narrator now says “It sorts your receipt.”
We'd give a focused correction:

```text
Restore the real category-selection step from category-selection.
Widen that shot so the menu and selected value are readable.
Replace "It sorts your receipt" with "Choose its category."
Keep the receipt upload, pending status, reviewer-view label, and ending.
Do not regenerate any interface footage. Show the revised sequence with
its surrounding shots, narration, and captions so we can review it together.
```

Compare the correction with the previous version. Even a specific request can disturb a caption
or timing elsewhere, so we'd check the whole short ad again before approving it.

Watch the exported file as someone who's never used the app [#watch-the-exported-file-as-someone-whos-never-used-the-app]

First, watch without stopping. Can you follow what the user does and why the result matters?
Then pause on the menu, status, and role change. Finally, watch at phone size with sound off and
listen once without relying on the picture. Those passes reveal different gaps; none replaces
the others.

Open the exported file, because that's the one you're handing over. Check it in the intended
placement preview as well: platform controls and the final crop can cover a status that looked
fine in the editor. If the narration promises a free trial, an integration, or a plan-specific
feature, verify that wording against the current destination before launch.

We'd keep a small handoff note so the next edit starts from the right source:

```text
Feature and product version shown:
Recording date and source filenames:
Demo data and permissions checked:
Required steps: upload, manual category choice, send, pending, reviewer queue
Role change label:
Any cut waiting time or omitted prerequisites to explain:
Approved script and caption version:
Landing page and plan qualification:
Exact exported file reviewed:
Reviewer and review date:
```

If the product changes, use that note to find the affected screen rather than quietly leaving an
old interface in the ad. And if the first version is clear, you can try a different opening while
keeping the accepted demonstration intact. Our [AI ad creative guide](https://www.cospark.so/blog/ai-ad-creative)
explains how we'd separate that variation from a new message.

For your first cut, we'd make the smallest complete explanation you can support: one real task,
a readable result, and a next step that matches what someone just saw. Once that's working, you'll
have something concrete to improve instead of a polished tour that never quite shows the product.