How to build a product demo that converts

A product demo converts when the right person sees the right slice of your product and knows what to do next. Most of the work of building a product demo goes into the screens, and almost none into who is watching them. This guide covers what to show, in what order, for whom, how to keep it current after you ship, and what changes when an AI agent asks the visitor who they are before the demo starts.

What should a product demo do?

A product demo has one job: get a specific viewer to believe one specific thing, then take one next step. Everything else on the screen is decoration.

PostHog's guide to giving demos makes the same point from the speaker's side. Pick a single takeaway, build the demo as a pitch rather than a tour of the product, and end on something concrete the audience can do straight away.

That leaves three decisions before you open any tool: the belief, the viewer, and the next step. The rest of this post follows from them.

Which product demo format should you build?

Pick the format based on how often your product changes and how many kinds of buyer you have. Polish matters less than both.

• Live demo. You, the product, and a prospect on a call. No setup, room to improvise, and the best fit for a late-stage deal with several stakeholders. It does not scale: every one costs a person's hour, and it only happens after the visitor has agreed to book.
• Recorded demo. A screen capture or GIF. Fast to make and free to host. It shows the same thing to everyone and goes stale the day the UI changes.
• Interactive click-through. Your screens turned into a clickable walkthrough, built from screenshots or captured HTML. Visitors get to click, but they follow the path you scripted. When someone wants something you did not script, there is usually nothing behind the click.
• AI demo agent. An agent that sits on your site, asks the visitor who they are, walks them through the product, and answers questions as they come up. It has the most upside when your site gets visitors who are not ready to book a call, and it needs accurate source material to work from.

If you are weighing specific tools, the comparison hub lays out how the categories differ.

Who is the demo for, and what do they need to believe?

Choose the viewer before you choose the screens, because different roles come to the same product with different doubts.

A founder evaluating your tool wants to know it will work without a long implementation. A head of growth wants to know what it does to conversion and what it needs from the team. A technical evaluator wants to know it will not become maintenance debt. An ops manager wants to know whether it fits the workflow already running. Same product, four starting beliefs. A demo that tries to settle all four settles none.

Then find the objection that blocks the deal. Sequoia's write-up of the Templeton Compression framework makes this point: identify the few objections that kill deals and build the demo to answer those, instead of answering every concern. For a first-time visitor the blocker is usually credibility: does this do what it says? For someone halfway in, it is fit: does it work for my case? Open on the answer to that one.

What order should the screens go in?

Use four beats: setup, payoff, evidence, and a next step. Give every screen one of those jobs before you build it.

• Setup. Establishes the problem or the starting state the viewer recognizes.
• Payoff. Shows the feature solving it.
• Evidence. Shows the result: a saved state, a completed action, a number from your sample data.
• Next step. The call to action, tied to what just happened on screen.

If a screen exists only because the feature exists, cut it. A tight flow of a handful of screens usually works better than a tour of the whole product, and it is less to maintain.

Vercel's virtual product tour is a good public example of restraint. It uses tooltips over its real UI so each step carries one idea, and it keeps a contact-sales option within reach throughout, so a ready viewer never has to hunt for the next step.

How do you write narration, labels and the call to action?

Narration explains why the screen matters, in one sentence per screen. "Click here to open the dashboard" is a caption. "This is where your team sees every active deal without opening a CRM tab" answers the question the viewer already has. If you need two sentences, the screen is doing too much.

Labels translate product mechanics into buyer language. "Auto-synced" means little until the buyer knows what syncs and why. "Updates when the deal stage changes in HubSpot" means something. The test is whether someone can follow the screen with the sound off.

The call to action should be the real next step: book a call, start a trial, request access. A generic "Get started" wastes the moment the demo just created. Match it to the audience too. "See it live" on a landing page is a different ask from "Continue where we left off" in a sales follow-up.

What data and app state should the demo show?

Use fictional company names, masked emails and plausible numbers, and make the state match the story. "Acme Corp, 47 active users, $12,400 MRR" reads as real without exposing anyone.

If the story is "your team just hit a milestone," the dashboard has to show a milestone. A demo that says the pipeline is healthy while three overdue tasks sit on screen loses the viewer immediately, however good the visuals are.

How do you keep a product demo current after the UI changes?

Treat the demo as a copy of your product, because it is one, and a copy drifts the moment you ship. No format avoids that. They differ only in how much work each drift costs.

Take a hypothetical: you rename "Projects" to "Workspaces" in the nav. In a screenshot-based demo, every screen where the nav is visible needs recapturing, which is most of the flow. A recording has the same problem plus the narration to redo.

Four habits keep the cost down whichever format you pick.

• Keep the flow short. Fewer screens means fewer places to drift.
• Put the demo on the release checklist. If a release touches a screen in the demo, someone checks it that day.
• Name one owner. A demo that belongs to the whole team gets updated by nobody.
• Date every review. Anyone should be able to answer when the demo was last walked against production.

An agent does not remove this work. It still shows your product, so the material it works from has to stay accurate. What it removes is the need to rebuild a separate tour for each audience, which is the next question.

Should you build one demo for everyone, or one per audience?

One demo for everyone shows each visitor the average of all your buyers, and one demo per audience multiplies the build and the upkeep.

The arithmetic gets bad quickly. Four roles and three use cases is twelve tours, each with its own screens to keep current, its own narration to rewrite and its own call to action to check. A common outcome is one tour aimed at the biggest segment, with everyone else sitting through screens that do not apply to them.

The third option is to qualify the visitor first and shape the path afterward. That is the idea behind an AI demo agent. It asks the visitor's role and goal, decides what to show based on the answers, walks them through the product live, and answers questions in context. You stop building a tour per audience. You build the material the agent works from: the product experience, your approved messaging, and the objections and proof for each kind of buyer.

This does not remove the thinking in the earlier sections. The agent still needs a belief to build toward, an objection to answer and a next step to offer. If you have not decided those, it will give visitors a more articulate version of an unfocused demo. It also needs accurate source material, which is why Inkly starts from your existing product materials, key workflows, existing demos and approved messaging, then runs a guided validation before anything goes live.

What do you build for an agent that qualifies, guides and converts?

Three things, one for each stage.

• Qualify. Decide the two or three things you need to know about a visitor before the demo starts: their role, what they are trying to get done, and what they are evaluating. These become the questions the agent opens with.
• Guide. For each answer, name the workflows that should come first and the proof that goes with them. This is the setup, payoff and evidence work from earlier, done once per kind of buyer instead of once per demo. Write down the questions visitors ask most, too, so the agent can answer them in context.
• Convert. Decide what counts as ready and what happens then: a meeting offered at the right moment, a trial link, a handoff. What the visitor asked, clicked and lingered on goes to sales as buyer intelligence, so the first call starts from what they already know.

The how it works page walks through the three stages in order.

Where should the demo live on your site?

Put it where intent is highest, not where it is easiest to embed. For a product-led motion that is usually the pricing page or a feature page, where the visitor is already asking whether this does what they need. For a sales-led motion it is the homepage and the outreach you send.

The same demo can then do double duty as a link in a follow-up email, something you send after a call, or a personalized link in outbound. How that works for outbound has the details.

When is a screen recording still the right demo?

When the product will not change and the audience is one. A launch video, a conference walkthrough or a static feature explainer is cheapest as a recording, and it costs nothing to host. It turns expensive when the product changes and the recording keeps showing the old UI. If you ship monthly or slower, a recording can cost less over time than anything interactive. If you ship weekly, the re-record cost adds up quickly.

Where does Inkly fit?

Inkly is the AI demo agent that turns website visitors into buyers. It qualifies the visitor, guides them through the product live, answers questions in context, and hands buyer intelligence to sales.

Every plan includes the voice and chat demo agent, and plans are priced by active visitors, where one person counts once a month. Free is $0 for 30 visitors. Pro starts at $150 a month ($120 a month billed yearly) for 150 visitors and adds visitor details, a demo tailored to each prospect, and lead qualification. Enterprise is custom and adds the clickable product clone, live product streaming and the CLI. The pricing page has the full table.

An agent suits a site that gets visitors who are not ready to book a call. If nearly all your deals start in outbound and a founder-led call closes them, a good live demo and a recording may be all you need.

FAQ

How do you make a demo look professional without a production team?

Structure, labels and call-to-action copy do most of the work. Give each screen a job, write labels in buyer language, and make the call to action match the next real step.

How do you use one demo for both sales and marketing?

Keep the core narrative shared: problem, payoff, evidence. Change only the opening hook, the order of the proof and the call to action per channel.

How is an AI demo agent different from an interactive demo?

An interactive demo shows every visitor the path you scripted. An AI demo agent asks who the visitor is, adapts what it shows, and answers questions as they come up.

What should you do this week?

Build one flow for one buyer. Write down the belief, the objection and the next step first, map four or five screens to the four beats, and put it live. Then ship a small UI change and see whether the demo survives it. After a month, look at which roles visited and count how many were not the buyer the flow was built for. That number tells you whether one tour is enough or whether it is time to qualify first.

Curious how the agent qualifies and guides a visitor? See how Inkly works.