How to create a product demo you can send in a DM
The 30-minute Zoom demo is dying. Buyers want to evaluate on their own time, in a tab they can close. Here's how to make a demo that fits in a Slack message and answers the question before the call.
The buyer's flow has changed. They search, they read, they look at a comparison, they bookmark a few options, and then — only then — do they consider booking a call. By the time they fill out the “book a demo” form, they've usually already half-decided.
Most sales teams still treat the 30-minute Zoom as the demo. That works for high-ACV deals where the buyer wants the relationship. It actively repels everyone else. “Schedule a 30-minute call to learn more” on a landing page is the conversion equivalent of asking for a second date before the first hello.
The async demo — a link that fits in a DM, opens instantly, answers the “what does this do” question, and ends with a clear next step — is the right shape for the top of the funnel. This post is about making one.
What an async demo is for
Two specific jobs.
Job 1: get past “is this even relevant?” The buyer's first question is whether your product solves their actual problem. They don't want a 30-minute pitch; they want 90 seconds of evidence. The async demo answers that.
Job 2: arm the champion. When your prospect is going to walk into their team meeting and advocate for your tool, they need ammunition. They can't replay your Zoom for the room. They can paste a link.
These are different from the live demo's job, which is to handle objections in real time and read the room. Live demos still matter — once the buyer is qualified. The async demo gets them to qualified.
What it's not
Three things people confuse the async demo with.
It's not a marketing video. A 90-second hero animation set to inspirational music is a different artifact. It's great on a landing page; it doesn't answer specific buyer questions.
It's not a Loom. A 4-minute talking-head walkthrough of your product works for one specific person, once. The next prospect needs the walkthrough, not the talking head. Looms also can't be skimmed.
It's not the help center. Help articles assume the reader has bought. Demos assume they haven't. The framing is different even if some of the screenshots overlap.
The shape that fits in a DM
Five constraints, in order of importance.
It opens instantly. No login wall, no email gate, no “watch this 30-second intro” pre-roll. The buyer should see the first meaningful screen in under 3 seconds.
It's skimmable. The buyer can scroll through the whole thing in 60 seconds and get the gist. If they want detail, they slow down at the relevant step.
It shows real screens. Not mockups, not stock photos, not a product tour with arrows pointing at illustrations. Actual screenshots of the actual product, doing actual work.
It has a specific outcome. The demo shows one workflow start to finish, not a tour of all features. “Here's how to set up a custom alert” beats “here's our dashboard.”
It ends with a CTA. Not “learn more” — a specific next step. “Set up your first alert” (with a free trial link) or “Book a 15-minute walkthrough with [name]” (with a calendar link).
The structure
A four-section async demo for a SaaS product:
Section 1: the buyer's pain in one screenshot
Open with a screenshot of the problem. Not your product — the world before your product. A messy spreadsheet, a Slack channel full of duplicate questions, a wiki page with broken links.
One sentence under it: “If your team is tracking customer health like this, the next sections are for you.”
This is the qualification step. Buyers who recognise the screenshot keep reading. Buyers who don't close the tab, which is fine — they weren't in the market.
Section 2: the workflow, walkthrough form
5–10 steps showing the buyer exactly how the workflow goes in your product. Real screenshots, real URLs, one-line descriptions. The thing that makes this an async demo and not a help article is the framing: each step describes the buyer's gain, not the product's feature.
Bad: “Click the New Alert button to open the alert configuration modal.”
Good: “You set up the alert in about 30 seconds — pick a metric, pick a threshold, pick who gets notified. No SQL, no scripting.”
Section 3: the proof step
Show the moment the workflow pays off. The notification arriving. The dashboard updating. The auto-generated report. Whatever the “value-realised” signal is in your product.
One short paragraph: how often this saves the customer time, and how much. Specific numbers help.“Your team gets the alert in Slack within 30 seconds, instead of finding out at the next standup.”
Section 4: the next step
One CTA. The right one depends on your funnel.
- Self-serve product: “Try it free” with a trial link. The buyer converts in the moment or doesn't.
- Sales-led product: “Book a 15-minute walkthrough” with a calendar link. Specific time commitment, lower friction than the 30-minute call.
- Enterprise: “Reply to this email with your stack and I'll send a tailored demo” — high touch but matches the deal size.
Don't add a second CTA. Two CTAs is one CTA the buyer ignores.
Production: 30 minutes per demo
The traditional async demo workflow — Snagit, annotate, paste into a doc, write descriptions, host somewhere — takes a half-day per demo. The walkthrough workflow takes 30 minutes.
Minute 0–10. Decide the workflow. Pick a single buyer pain and a single workflow that addresses it. Write the four-section frame above as headers in a doc.
Minute 10–25. Hit record. Do the workflow on a clean account with realistic data (or your own account, with redactions ready). Each click captures a screenshot, the URL, and the clicked element.
Minute 25–30. Edit. Drop the detour steps. Rewrite each step description from “click the button” to “you do X.” Drag redaction boxes over anything sensitive. Add the opening pain screenshot and the closing CTA.
Publish. The link is go.uihike.com/published/{UUID}. Public, no login, comments enabled (so the buyer can ask a question without leaving the page).
Personalising at scale
The next-level move: a base demo plus per-account variants. Same workflow, different data. The prospect from Acme sees the demo with “Acme” sprinkled across the screenshots; the prospect from Globex sees “Globex.”
Done by hand, this is a 30-minute job per account, which doesn't scale. Done by re-recording with the prospect's data loaded, it's 5 minutes — record once, swap the variable bits, re-export.
Don't personalise everything. The personalisation that matters most is in the opening (their pain, in their language) and in the closing (a CTA that sounds like a human wrote it). The middle steps can be the same for everyone.
Distribution: how to actually get the link in front of buyers
Three patterns that work.
The cold email. Two paragraphs, one link. “Here's a 90-second walkthrough of how [thing they do] works in our product. If it's not for you, no follow-up.” Reply rates 2–4× the generic cold pitch, in our experience.
The website hero CTA. Replace “Book a demo” with “See it in action” (link to the async demo) and keep the “Talk to sales” CTA below it. Buyers who click the async demo and stay in it are warmer leads than buyers who skip it.
The reply to inbound. When a prospect emails “tell me about your product,” reply with the link, plus a one-sentence pitch and a calendar link below it. The prospect either watches and replies, or books, or doesn't — and now you know which cohort they're in.
Measuring an async demo
Track three numbers.
Open rate. What fraction of recipients clicked the link. Tells you if your opening (subject line, preview screenshot, context message) is working.
Completion rate. What fraction of openers reached the final step. Tells you if the demo's middle is holding attention.
CTA click rate. What fraction of completers clicked the closing CTA. Tells you if the demo's end is doing its job.
The most common failure mode is high open rate, low completion rate. That means the opening promised something the middle didn't deliver. Rewrite the middle, not the opening.
What you give up vs a Zoom demo
Two honest gaps.
The async demo can't handle objections in real time. If the buyer's concern is “but does it integrate with our weird ERP,” the demo can't pivot. The CTA needs to send them to a human who can.
The async demo doesn't build rapport. For high-ACV deals where the buyer is buying the relationship as much as the product, you'll still want the live call. Treat the async demo as the warm-up, not the replacement.
Start with one
The fastest experiment: pick the question your sales team gets asked most often on first calls. “How does it work with...?” “Can it do X?” “What's the setup like?” Build an async demo that answers that question, end to end. Send it next time the question comes up.
Try UIHike on the demo your sales team has been meaning to record. The link you produce this week is the call you don't have to take next week.
— The UIHike team